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
