My suggestion is to do this:

* Create (or add to) pmdf_table:site_name_content.dat and add this line:
o *.csv text application/ base64
* Then execute:
o $ pmdf cHbuild
o $ install replace pmdf_charset_data ! have to do this on all
relevant cluster members
* Then use "pmdf send" to mail the file:
o $ pmdf send/subject=whatever nl:,foofoo.csv/file

Hope this helps!

- ken

Ed Withers wrote:

> 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
> (919)-941-9477

- Ken
================================================== ===============
Ken Connelly Systems and Operations Manager, ITS Network Services
University of Northern Iowa Cedar Falls, IA 50614-0121
phone: (319) 273-5850 fax: (319) 273-7373

It's much more important to know what you don't know than what you do know!