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