DCL Query - Removing Linefeed Character

[Rob Buxton]

Hi All,
It's been a while since I've been over on the VMS side of things!
I'm trying to script some DCL to replicate what is currently being done via a Kermit File transfer but extracting from VMS mail instead.

The existing files comes across as Stream_LF.
I have been able to extract the message, for some reason it seems to have a "=" at the end of each record and is set to 72 characters.
I have to do a bit of dodging around to extract the e-mail but I do obtain a file. I then try and write this file to a suitable output file. The trouble is the file I'm writing out using DCL seems to contain a after the Write of each Record.
I create the empty file using an FDL based on the original and Open /Read / Write to preserve the file. But I cannot replicate the original file that does not have the Characters in the file.

OpenVMS 7.2 (or 7.2-2 on Alpha)

Any hints as to how you write a file out in DCL but not have a at the end of each record?
I've tried the /Symbol qualifier but that made no difference.

TIA

Rob.

[Martin P.J. Zinser]

Hello Rob,

once it is in Mail it is not Stream_LF on the
VMS side of things. If file attributes are important wrap the file into something that preserves file attributes (like a zip archive with "-V"), pack that up (e.g. with uuencode or mpack) and transfer the packed format.

Greetings, Martin

[Rob Buxton]

Martin,
To be a bit clearer, this is a file that is arriving from an external source by e-mail.
I need to extract the file and prepare it for use in an existing utility, hence the need to replicate the existing format.

I might need to get the sending side to alter how it is sent. But I was hoping to avoid that.

[John Gillings]

Hi Rob,

This might be easier to handle as a service case. Please email me your access number and I'll log one for you.

[Jan van den Ende]

Rob,

one thing you might try before doing any re-workings is to tell VMS that this IS a stream_LF file:
$ set /attrib=rfm:stmlf

If it is a true stream_lf file, you're home!
Any program using RMS will handle it correctly.

But, if you DO have to manipulate the records in DCL:

$ open/read ifi
$ open/write ofi $ lf[0,8]=10
$loop:
$ read ifi rec/end=done
$ rec = rec - lf - lf ! twice (or more) if not sure of only one lf
$ write ofi rec
$ goto loop
$done:
$ close ifi
$ close ofi


hth

Cheers.

Have one on me.

Jan

[Uwe Zessin]

The reason for the line breaks at column 72 and the "=" at the end is called 'Quoted-Printable'.

See:
http://rfc.sunsite.dk/rfc/rfc2045.html
Section: 6.7. Quoted-Printable Content-Transfer-Encoding

[Martin Vorlaender]

Rob,

just an aside:

>>>
I have been able to extract the message, for some reason it seems to have a "=" at the end of each record and is set to 72 characters.
<<<

This looks suspiciously like the contents of a quoted-printable encoded MIME mail.

There, unprintable characters get encoded by "=" and lines longer than 72 characters get broken up with "=" as the separator.

HTH,
Martin

[Volker Halle · Accepted solution]

Rob,

welcome back to OpenVMS ;-) If you've not been there for a while, you may not be aware of the MIME utility, which is able to read (and extract attachments from) MIME formatted mails.

You sure remember HELP, so just try $ HELP MIME

If the file you're interested in, would come as an attached MIME-encoded document, you could easily extract it from VMSmail:

$ MAIL
MAIL> EXTRACT/NOHEADER x.x
MAIL> EXIT
$ MIME x.x
MIME> LIST
MIME> EXTRACT/ATTACH=1
MIME> EXIT

Volker.

[Hein van den Heuvel]

>> Any hints as to how you write a file out in DCL but not have a at the end of each record?


Instead of $OPEN/WRITE file name.ext

use:

$CREA name.ext
or
$CREA/FDL=some.fdl name.ext

then

$OPEN/APPEN file name.ext.


If the mime / rfc advice does not sort you out, and you end up with a file that needs post processing, when we can help. But to help us help you please attach a sample output and input in a text or .doc file.

fwiw,
Hein.

[Bojan Nemec]

Rob,

It seams that you receive a mail in the so called "quoted-printable" content transfer encoding. This seams because of the 72 characters long records (RFC says less than 76) and the so called soft line break (an "=" at the end of line). Please see th RFC for more informations:
http://www.faqs.org/rfcs/rfc2045.html

Now, to properly convert this file you must write (or search) a program which will do the work. It is possible to write it in DCL.

Abbout the ending , you shold check the file using dir/full and dump. Maybe it will be easier to write a normal VMS sequential file and then convert it to stream_LF (if the file will not be used on VMS).

Bojan