I would not be unsurmountable to create an archive.  tar would probably be
the simpler.  The undocumented LISTDIR stage will get you all the
information you require.  I wrote some CMS code to receive a tape archive
almost twenty years ago, I forget whether I bothered with the other
direction.

pipe listdir . recursive

Where the dot represents the top directory you want to do; it could be lower
in the tree.

   j.

On 26 February 2010 12: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
>

Reply via email to