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