This is a discussion on 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. Ok, actually, it is a comma-separated values (.csv) file with long (>1024 char) records. The problem is that the records are broken into multiple ...
I have a user that is trying to e-mail a text file with long records. Ok,
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.
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]?" )
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
characters. 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.
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.
Ed Withers, Manager, Information Technologies
Semiconductor Research Corporation