There were at least two implementations of TAR for CMS prior to OpenVM and other than John's LISTDIR magic. They were not widely used. While I would first recommend a self-extracting EXEC which uses VMFPLC, I gotta confess that I like the idea of TAR.
TAR is a crude and simplistic format, but it is ubiquitous. Since you mention 'pax', it naturally leads one to think of 'tar'. The majority of "packages" on the internet are something.tar.gz or something.tar.bz2. (And GZIP has been built for CMS since ... a long time ago.) And tarballs are consistently "envelopes". Then again, if you are on a current VM system (anything newer than 1995), you do have access to OpenVM and could probably get clean and reliable package transfer using 'pax' or 'tar' from that subsystem along with 'uudecode' also from that space. A/E would still be a req: 'tar' will not translate (last time I read the docs) and 'pax' wants to translate. I would prefer to handle translation. Source files and text files should be ISO8859-1 to "CP37v2" (where CP1047 is the close approximation you mentioned, but not poifect.) So ... VMFPLC is great, and TAR is interoperable with non-CMS. Both are envelope thingies. Both can be neatly wrapped into plumbing. -- R; <>< On Fri, Feb 26, 2010 at 06:47, Paul Gilmartin <[email protected]> wrote: > On Feb 26, 2010, at 02:38, Rob van der Heij wrote: > >> On Thu, Feb 25, 2010 at 8:44 PM, Paul Gilmartin <[email protected]> wrote: >> >>> o VMARC self-extracting archive: >>> - Is there any legal liability if it damages the customer's >>> system? >> >> I feel very bad about that idea! We don't want to teach VM sysprogs >> to accept gifts from strangers like that.... >> >> I use VMFPLC a lot. At least I can scan the file before loading it to >> disk. But what I normally would want is the full FST info to see >> whether it would fit on disk and whether it is different from what I >> am going to replace. I wrote a pipeline stage that displays the >> contents of a VMARC file in LISTFILE style. I probably should do the >> same for VMFPLC. >> >> Another option is netdata format. It's known to be F 80 so record >> boundaries can be restored as well. >> Back in the old days, the Piper and myself exchanged files as netdata >> | encode64 inside mail. The mail agent (on CMS) would pick the files >> and stuff them in my reader so normal CMS commands could be used to >> handle the files again. One of my co-workers wondered where the >> "Received from JOHN at CPHVM1" in his NETLOG came from :-) >> > The key word here is "collection". VMFPLC, like VMARC will handle > envelopes containing multiple files with different attributes. > I don't believe netdata will do this. > > I've done a lot of shuffling files between UNIX, CMS, and z/OS. > Netdata has the drawback that it's not safe in SYSIN because it > can allow "//" in cols. 1-2. And there's no standard 64DECODE > on z/OS, so for z/OS SYSIN I use pax | uuencode. > > Most of my CMS experience antedates SFS. Is there a CMS utility > that will package an entire SFS directory hierarchy, akin to > pax(1) on z/OS?: > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZA5A0/SHCMDDES.PAX.2 > > Thanks, > gil >
