On Thu, 29 Mar 2018 21:26:04 +0000, David Boyes wrote:
>
>> A PTF, of course, can be just FB 80 EBCDIC "simple sequential binary file".
>
For RECFM=FB, the record boundaries are implicit; easily reconstructed.
>Agree , although I'd argue that any fix should have accompanying metadata that
>gets incorporated into the system service inventory tool without having to
>extract the fix, so any fix would be at minimum 2 files.
>
Most recently, my employer adopted a standard format for all platforms (z was
a niche market for them). Two files: README.{txt|html(|.doc?)} and any .zip
file.
So, SMNTS.pax.zip. And the SMPNTS is many pax.Z payload files plus
metadata. Gasp!
>> A pax archive is "one simple sequential binary file". "pax -vr" is in base
>> z/OS,
>> as is SM/E RECEIVE FROMNTS; no need even to go to CBT tape and assemble
>> a utility.
>
>I think we're solving different facets of the problem now.
>
>... The "tape image" metaphor lets us leverage a common delivery format
>whether the input is a disk file or a tape or a card deck or a mind link with
>Zog Prime (that last one is a challenge) AND we can move between them freely
>with minimal or no effort.
>
pax.Z is a flat file. Any binary tranfer works. I even experimented
successfully with using "jar" to extract the pax.Z.zip, but thought it
best to leave the customers to their own devices to deal with the .zip.
(Note today's pleas here for help with new java release.)
>I agree wholeheartedly that packing fixes into pax or RECEIVE FROMNTS files
>would be a viable thing to do for individual APARs.
>
Individual APARS are fixed-80 flat files (which company standard required us to
zip).
>If it could also handle VM SES format fixes, ++good on us.
>
>... The only tool we had was VMARC format over channels that didn't support
>maintaining file attributes or record boundaries; we went with the
>community-provided tool route to avoid inventing a wheel, ...
>
We shied away from VMARC because of the "community provided" part. Perhaps
we had too much the MVS mindset -- the VM mindset is more tolerant of diversity.
Rather, we went with COPYFILE (PACK, not for the compression but for the
flattening.
We used VMFLPCD then COPYFILE (PACK for VMSES/E.
>Think about AMATERSE and how it got out, and the resulting hassles with that.
>
Must I? Too many DSORGs has impelled to too many archive formats.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
