This is a discussion on Re: Text attachments with long lines breaking incorrectly - VMS ; > Hello, > I have a user that is trying to e-mail a text file with long records. This is effectively an oxymoron in MIME. Long records constitutee binary material, not textual material. (Note that I'm really talking about encoding ...
> I have a user that is trying to e-mail a text file with long records.
This is effectively an oxymoron in MIME. Long records constitutee binary
material, not textual material. (Note that I'm really talking about encoding
here, not media types, but in practice the two tend to get conflated in all
sorts of ways.)
> actually, it is a comma-separated values (.csv) file with long (>1024 char)
> records. The problem is that the records are broken into multiple lines
> and thus break the spreadsheet.
Then it is effectively binary material and needs to be handled as such. And it
isn't safe to give it a type under the text top-level media type.
> It appears that the record is broken at 1022 characters during the
> encoding, but that depending on the tool used to read the mail, the record may
> also be truncated to 1000 characters. I'm basing this on sending a message to
> my VMS MAILbox and my Exchange mailbox. When I extract the copy with PMDF
> MAIL and edit it, the record appears to break at 1022 characters, lose a
> character, and then continue on the next line. When I extract the same
> attachment using Outlook and edit it with a text editor (Notepad, TextPad, and
> Word) the first record ends at 1000 characters, then the next line is the
> content starting at character 1024 just as seen in PMDF MAIL. This looks like
> the line was broken at 1022 characters and then truncated to 1000.
> The user is using the VMS command PMDF SEND and has tried all the
> combinations of /mode=block or /mode=record and /encoding=base64 and
> /encoding=quoted_printable. (/Mode=text fails with
> "Some input files are not accessible; send anyway [N]?" )
/mode=block works for me when I try it. However, in order for this to work in a
way that other systems can deal with, you have to make sure the file is in the
right format on VMS to begin with. Length-counted records aren't going to cut
it on other platforms; you'll need to convert the file to stream format and
hence CRLF line terminators. I normally do this with CONVERT.
> The following is the result of sending from the command line and reading
> the mail in PMDF MAIL, then extracting the file with the EXTRACT command:
> When sending with /mode=record, the resulting file runs all the records
> together (no CR or CR-LF between records) and all records are 1022
Mode=record assumes there's some out-of-band way to find the boundaries between
records. I don't believe there is a way to specify a record separator in the
command line utility; PMDF MAIL lets you specify a separator by saying
/record="separator". (CTRL/V can be used to enter carriage returns and/or line
feeds.) This also works when I try it, however, I have to override the
media type somehow to prevent bad things from happening on receipt. For
this reason I prefer to force the file into the correct format with
CONVERT and use /mode=block.
> When sending with /mode=block each new record starts on its own
> line, but those records greater than 1022 characters are broken into multiple
> lines and one character is lost at each new break. Changing the /encoding
> doesn't seem to make any difference to the behavior.
This could be due to any number of factors, including the file being in the
wrong format or the use of a text media type. Again, if you first insure the
file format is something that will make sense to other systems and then make
sure the media type isn't one that's going to be interpreted in various
exciting line-length-limited ways, you should not have any problems.
> So, what am I doing wrong? Is there a magic set of qualifiers I need to
> include to handle long records, or are we forced to zip the file before
> sending it? Any help would be greatly appreciated.