On Mon, 21 Sep 1992 20:59:00 EDT Nollaig MacKenzie <GL250011@YUORION>
said:
> I just twigged to the fact that folk had been talking about
>Listserv now supporting /VMSDUMP files. Does this mean that I could,
>e.g., store a VMS WordPerfect file, or APL workspace, on a Listserv List
>filelist?
Yes and no. You can store any VMS file using one of the following
methods:
1. Store it as a "foreign file" (works on all releases). You basically
send the file to yourself in VMSDUMP format, read the VMSDUMP
formatted deck back without decoding or conversion, and store that on
LISTSERV. To LISTSERV, it looks like a file of 80 bytes records
containing binary junk. When the user gets the file with F=PUNCH, he
receives a working VMSDUMP deck which JNET will properly decode. I
wrote a PUTVMS.COM procedure to help with this.
2. For servers which support VMSDUMP (1.7d servers with development fix
17D-002D and future 1.7e servers), you can place the file in a BACKUP
saveset and store that on LISTSERV. BACKUP savesets are
"straightforward" sequential files with fixed records, ie they remove
the "weirdness" and RMS-specific attributes of the file, if any. This
will look like a binary file to LISTSERV, but one that can be mapped
to a VM file without problem. When ordering the file in VMSDUMP format
(which should be the default format for JNET sites), you will receive
a fully functional saveset from which you can then extract the file.
While this may seem a bit clumsy, it is actually the most convenient
method if you have a package with several files. This is the
equivalent of a unix tar file, except that you can package just any
VMS file this way.
In addition, you can store any sequential file on LISTSERV as a CMS file.
When ordering it back, however, some of the information may have been
lost. For instance, CMS allocates blocks for files in a different way and
does not have a concept of initial allocation/extent; this information is
lost (for the vast majority of files, it doesn't matter at all). There
are a number of other usually unimportant attributes which might be lost,
but probably the most important restriction is that STREAM_LF (unix
emulation) files will be sent back as regular variable files. Some C
programs only work with these files.
One thing which is NOT a problem, however, is binary data and ASCII to
EBCDIC conversions. The translation tables used are reversible; LISTSERV
will store the file in EBCDIC, but send it back in its original form. The
reason I am stressing that point is that recent postings seemed to
indicate that EBCDIC is considered to be a major obstacle to the use of
LISTSERV with non-EBCDIC systems; this about as much of an obstacle as
the cyrillic alphabet when learning Russian, ie a one-time investment in
learning/programming time.
Eric
|