Sending attachments using Send_sff and mime

[GNJ]

HI
I was facing a problem in sending attachments in vms and i achieved it using
mime and sene_sff command.
But I am facing a issue in the received attachments. The sent file is a csv file with
several lines in it and it is received as (when opened in excel) all the lines in a single row.I will mention the commands used for sending the file
$mime
mime>new/noedit a.txt
mime>add/bin test.csv
mime>save
mime>exit

then a.txt is edited and headers with correct mail addresses are added.
then
$smtp_sff a.txt

I am attaching the original file and the
received file.
Can you please give your suggestions to rectify this. Please give examples so that
I can understand with ease...
Original file attached with this mail.
the received attach ment will be sent using another..


Thanks and regards

[GNJ]

Attaching the received file

Regards
Jayakrishnan G Naik

[Steven Schweda]

What were the original file attributes?
("DIRE /FULL", look for "Record format" and
its friends.) I know nothing, but MIME may
do better with Stream_LF than other formats.

Without seeing the MIME output itself, it's
hard to say where things went wrong.

[Hoff]

Sequential files are not inherently transportable; there tend to be low-level differences in the record structures across systems, and transfer tools may or may not contend with these correctly.

Accordingly, I might suggest use of the text-mode transfer (and not binary), and I would encourage converting the file into stream LF format before processing it.

There are various ways to convert what is likely a VFC sequential file (containing the CSV bits) into Stream LF sequential file, the easiest approach involving creating a runt file and issuing a SET FILE/ATT=RFM=STMLF on it, then editing and including the VFC file, and saving the result. In a production environment, an FDL is created and the CONVERT/FDL command is used.

I would also suggest avoiding CSV whenever that is feasible. CSV gets ugly as you end up escaping stuff or when you need make changes, cases which tend to arise with regularity -- it's been my experience that CSV inevitably turns into a hairy, ugly mess.

XML would be the recommended solution here. It's quite not as simple, but is extensible, flexible, transportable and, well, it just works better.

I might also suggest other datagram transports, including using http, https, or such. Quite possibly an XML-based web page or web-served XML document. The client can then pull over the required information as needed and when needed, rather than receiving and processing MAIL messages. (This gets MAIL and SFF entirely out of the mix.)

As for what was attached, attachments that are text files are locally preferred. Further, if this is a formatting issue, I'd be quite surprised if the file survived unscathed. To protect the attributes, I'd suggest a Zip the original file and the SFF message created by the MIME tool (zip with "-V"), and a second zip of the resulting file as received on Microsoft Windows.

[Joseph Huber_1]

I would try to send the file as quoted-printable and see if it is well received.
Put the line
csv, text/plain, Quoted-Printable
in SYS$MANAGER:MIME$FILETYPES.DAT ,
then simply use ADD, not ADD/BIN in MIME.

And how is "smtp_sff" sending the file ?
It is not a command known on my VMs.

[Steven Schweda · Accepted solution]

Or ADD /TEXT. Why did you choose /BINARY for
a text file?

[Hoff]

The SMTP_SFF mechanism referenced is a part of TCP/IP Services; Send From File. SMTP_SFF is a means to inject a message directly into the SMTP processing, without allowing MAIL and its own message formatting to interfere.

Start here:

http://h71000.www7.hp.com/wizard/wiz_4492.html

[Joseph Huber_1]

Yes I know TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE,
but one can't pass MIME output directly to it,
it needs the SMTP-server statements (MAIL FROM, RCPT TO,DATA) inserted before the MIME header.
So the posted sequence of MIME followed by SMTP_SFF cannot be MIME followed by TCPIP$SMTP_SFF alone, SMTP_SFF must be some procedure equated to the the symbol.

Anyhow, there is no need to use SFF at all (unless with quite old TCPIP, before V5.3 presumably).
A simple "MAIL file destination" will do it.
All newer TCPIP SMTP versions do not insert the notorious empty line before the MIME header, as long as the file starts with "Mime-version:".

[Hoff]

Ok; I misinterpreted your query. My bad. You do raise some good points. FWIW, the SMTP_SFF symbol is lifted right out of the doc, and it does appears the MIME-encoded message is arriving at the box running Excel, so the message has been addressed and delivered (somehow). Whether SFF is needed now or there are better ways (as you cite) SFF should still work. And it would appear the "fun" here is with the CSV file structure or contents, and not so much with the SFF giblets.

[GNJ]

HI
Thanks to Steven Schweda
as his suggestion worked for me....


Thanks A lot for all who given suggestions as all of them given a better idea of what
I should do

Thanks & Regards
Jayakrishnan G Naik

[GNJ]

I am closing the threas


Once more Thanks to all

Regards
Jayakrishnan G Naik