FDL for OpenVMS files

[Niall76]

Hi,

I'm wondering if anyone knows of a way of creating an FDL that Stream LF a file on windows or Linux?

Currently we Stream LF files on VMS before transferring them. Is it possible to do this Stream LF on Windows or Linux PC instead. If we don't stream LF the file first, it contains strange characters that can't be seen when opened with a VMS editor.

Thanks.

[Hein van den Heuvel]

Hi there. The question is not entirely clear.

I'm not even sure which way the files are going!

"we Stream LF files on VMS before transferring them"

What does that mean exactly? CONVER/FDL=somefile.fdl  old new?

What is the contents of 'somefile.fdl' ? "RECORD; FORMAT STREAM_LF"

What OpenVMS version? On somewhat modern version you can pass the FDL file contents as a string:

$ convert /fdl="record; format stream_lf" old.txt new.txt

The file is tranferred from an OpenVMS system.

 --- How? NFS? FTP? Kermit? .. 

 --- Are there transfer options? Binary, Ascii, which one is used

When received there are 'odd' charaters. Which one? 

Can you used a tool like UltraEdit or a perl script to provide a sample hex dump of an example section?

I'm sure you can post-process the file on the target to interpret and/or remove the odd characters, but why not do it propoerly on the source side? Again, a tool like UltraEdit may be able to 'do the right thing' in managing new-lines and so on, better than 'Notepad' for sure.

What does the file look like (DIR/FULL) on the OpenVMS side before 'streaming it' (whatever that may mean?)

What does it ook like afterwards?

Can the application not just create a proper (stream_lf = lifefeeds or stream = carriagereturn+linefeed) file to begin with?

Good luck!

Hein

[H.Becker]

Unfortunately there is not much background information here. What do you do, why do you have to do it this way and what do you really want to accomplish?

A simple file transfer with ftp in ASCII mode does exactly what you expect it to do: if necessary the text is converted so that it is readable on the target platform as if it were created there.

A file transfer with ftp in BINARY mode keeps the VMS/RMS structure so that reading the file on the target platform requires knowledge of that structure, which usually isn't there. Without that you may see the nasty, unreadable characters.

If you convert the file on the VMS side with an FDL description to convert the VMS/RMS structure to one which is known at the target platform you can transfer the converted file in BINARY mode as well. That's probably what you do and describe as "we Stream LF files".

What you seem to ask for is a utility to do the conversion based on an FDL description on the target platform. That is, you have to create the FDL description along with the file (or only once for a known set of similar files) and transfer both to the target platform. Obviously you have to do this on VMS, as the meta information about the RMS structure is not part of the transferred file data.

I only know of a utility which expects input like the keyword/value pairs in the VMS command "set file/attribute", that is org, rfm, etc. Based on that input the file is converted. This is available for Windows 7 and probably can be made available on request for Linux. Try Google and look for the tool coprw32. But I don't know whether that is a useful solution to your problem.

There may be other more useful options to do what I think you want to do, for example using the zip utility on the VMS side and simply unzip on the target platform.

If we knew what you really want/need to do ...

[Hoff · Accepted solution]

There are some tools around which purport to convert arbitrary VMS files — see if what you want is here  — but it's just as easy to either create or convert the files on VMS to use Stream LF and then use those files locally (VMS works just fine with Stream LF files, though most tools default to creating VFC), or to convert the files before transport via FDL (I often do this in my "packaging" routines for releases and for archiving). 

Converting a VFC on Unix is trivial; the format is very simple.

Related details...

The Info-Zip folks (might) welcome the contribution of some code that converts at least the RMS VFC file formats into Stream LF files on the way into the zip archives too, akin to what the --from-crlf and --to-crlf stuff provides.  That'd be a logical spot to implement this file-format conversion, after all.

[Steven Schweda]

> The Info-Zip folks (might) welcome the contribution of some code that
> converts at least the RMS VFC file formats into Stream LF files on the
> way into the zip archives too, akin to what the --from-crlf and
> --to-crlf stuff provides.  That'd be a logical spot to implement this
> file-format conversion, after all.

   I believe that the following is true, but I'm open to enlightenment.

   As usual, everything's complicated.  The (old) decision, apparently,
was to do some work in Zip, and some work in UnZip, where necessary.

   On a VMS system, Zip without "-V" (/VMS) reads records, and archives
data with LF line termination (or whatever the -l[l] (/TRANSLATE_EOL)
option says to do).

   UnZip anywhere extracts what's in a non-V archive, but can be told to
convert to the locally natural line endings (-a[a]).

   On a VMS system, Zip with "-V" (/VMS) archives the actual bytes, and
saves the attributes in an extra field.

   UnZip on a VMS system extracts what's in a -V archive with the data
and attributes restored.

   By default, on a non-VMS system, UnZip is built with the C macro
VMS_TEXT_CONV defined (unzpriv.h).  If it's defined, then the extraction
code (fileio.c) tries to deal with the embedded byte counts in VMS
variable-length records in a -V archive.  (The VMS-specific extra field
is detected and interpreted, and the file data are extracted
accordingly.)  I haven't looked closely at that code, so I know nothing,
but I don't recall getting any complaints about it.  (Which could be
explained in many ways.)

   So, in most cases, any kind of archive created on a VMS system should
be interpreted in a reasonable way when extracted on any system type.

   If you can break it, now would be a good time to report any problems.
(Of course, any time is a good time to complain, I always say.)

[Niall76]

Thanks Hoff, once again you are living up to your legendary status. This utility appears to work great. Thanks for the quick solution.

[Niall76]

Sorry for the lack of information, I thought this was something you'd had all encountered before. The reason for not transferring in ascii or using ZIP -l was to ensure the file checksums matched when the file reached it destination. Thanks to the Hoff for the solution.

[Niall76]

Thanks Steven, the ZIP -l options works great. Its just in this case I needed a MD5SUM of the file on VMS to match that on either Linux or Windows. Once these check-sums matched the utility that Hoff suggested enables the export to a new file without non supported characters. Thanks.