Long file email

I have a file that’s more than 500 characters long. When I opened it with NotePad I saw more than 350 records that were each 500 characters long. I emailed it to someone who only received a single record that was not as long as it should have been. I opened it with TextEdit on my Mac, and saw the same thing. So what’s the deal? Where did the records and parts of records go?

What email program are you using?
How large is your file? (~175k?)
How large is the file that your correspondent get?
How large is the file as listed on your Mac?

If they’re all the same size, I’d blame the text editors. Notepad is notoriously bad at text (ironic as that’s all it’s meant to handle), incapable of opening large files in early versions, difficulty in current ones, and an inconsistent ability to co-ordinate your current location in a file. Long lines especially can cause problems with lame editors.

If they’re different, then I’d blame some MIME encoding strangeness during mail transport. Try renaming the extension or compressing it in a .zip file or other first.

Yahoo mail.
I don’t know the size of the file on the PC. It’s at the office. (This is not a work file though.)
I don’t know the size of the received file.
It’s listed as 4kb on my Mac. From the description, it sounds like it’s the same size as the file that was received.

WAG - the file may have only CR (0DH) or LF (0AH)characters at the end of each line (or none). “Standard” text files typically have both (Carriage Return plus Line Feed) but this file may have only one or the other. Good editors detect this and compensate, but your/his editor may not be translating the single char into the 2 chars needed. So it would look like one very long line off to the right of the screen, like into the next county.

There could be other reasons. Look at the file with a hex editor if you want to verify this, but is there any way you could get the file in an alternate format from the source?

I agree there’s a problem with the eol/eof characters, but where it’s manifesting itself (email client, email server, or destination) is unclear. (Compressing it would eliminate the first two as suspects).

If you have 350 records x 500 characters, your file is going to be ~170k, so I’d be concerned if anything shows it as being only 4k.

I uploaded a .txt document to a mainframe fixed-block file. I manipulated the records to convert a ‘report format’ file (headers, each entry comprising four lines) to a ‘flat file’ (no headers, one record per entry) using Easytrieve Plus. Once I had the ‘flat file’ I downloaded it to My Documents as .txt using the FTP tool in Extra. I opened the file with NotePad as described earlier. and had a duplicate of the file on the mainframe.

The mainframe file contains ‘non-display characters’ – hex 00 – plus double quotation marks and extraneous spaces. I didn’t get rid of the extraneous characters and right/left justify the columns because this was a non-work-related ‘fun project’ and I didn’t have time to write the code. I just wanted to see if I could make a flat file from report format.

Actually, it would be nice to know if there’s a PC-based software that would change this:

Name           Address            City,State, ZIP
Account        Terms              Balance
01-30          31-60              61-90
ABC Co.        123 Fake St.       Los Angeles, CA 90036
000000001      Net 30             $410.95
$310.95        $100.00          

to this:

000000001ABCCO.   123 FAKE ST.   LOS ANGELES   CA   90036   NET30   00000411  0000311   0000000 

(I hope the code came out right. Looks good on preview.)

That’s an odd combination. If every field has double quotes around it and commas between, that would probably be a Comma Delimited, or CSV file, which is importable to most database or spreadsheet programs. Spaces might just be padding to make the fields of each record the same length. Zeros, probably ignorable.

Any database program should work. It looks like what you want is to rearrange the field order and perhaps make everything line up in columns, right? If so, what is the desired end product of this exercise? Address labels? A name & balance printout?

Sorry, I wasn’t clear. It’s not comma delimited. When I said double quotes, I meant " instead of '. The columns would line up, except for the extra spaces (which are not padding), non-display hex characters and "s.

As you can see in the sample (which bears a passing resemblance to the input file, but really I just made it up for an example) there is a multiline header. Then there are four lines of account information. What I want to do is turn the four lines into a single record – which I did. The extraneous characters are not a problem on the mainframe. All I have to do is write some more code to get rid of them and justify the fields (and zero-fill the balances so that they are numeric fields). A piece of cake. The end product will be a file that contains fixed byte records that can be used as input for mainframe-based jobs.

Why am I doing this? Writing Easytrieves is fun. If it were only a matter of converting a file there would be no question. But I want to email the file. For whatever reason, the emailed file does not look like the file on the mainframe or the .txt file on my PC. I have no use for an emailed file other than to show my results to somebody else. Your WAG suggests to me that the hex characters may be doing something during the transfer.

I’ve known someone for several years who works for a company that provides files to a credit processing company. She is often frustrated by people who send her files that are difficult for her to convert to flat files. I’m not in a position where I can write Easytrieves for her so that the files can be used. (If I were, then I’d just write an Easytrieve and be done with it.) They don’t have Easytrieve in their shop, so basically I’m just doing it for fun. I just wanted to show her that it’s a simple matter to convert report format to flat format.

So the basic question is this: How do I email her the flat file? Do I need to get rid of the extraneous characters first, assuming they’re causing the file to be ‘corrupted’ during emailing?

The other question was whether there is software to change a report format text file into a text format flat file. If there is, and if I could obtain it, then I could let her know about it. And perhaps they’d need someone to use it. :wink:

The two questions are only tangentally related.

I may be only marginally helpful at this stage. I often convert file formats into something else, but my method isn’t for everyone. Nevertheless, here’s how I would do it.

First, I’m a wiz at the dBase/Fox family of database programs, and it’s much faster and cleaner in DOS. Don’t laff. I would import the original file into a DBF file with the fields defined as first guessed (width is the critical item here). If every record (line) imported in the same manner, that is, no left-right shifting from bogus and variable characters, I would adjust the widths until everthing imported OK. Then I would write out from that work file into the sequence, type and format I wanted as the end product, specifying fields, widths, etc.

In a good database manager, this should be possible in two lines of code plus some minor overhead, after a lot of experimentation, of course! Then you could use this program on other files of the same type.

If the bogus chars caused trouble, I might have to parse each line with a little more care.

Sorry if this isn’t very helpful. :frowning:

I had some time to play with it today. I got rid of the hex and other extraneous characters, downloaded as .txt, and zipped it. I sent it to myself at three different addresses, and to the person who sent me the report format file, and it opened just fine.