On Thu, Apr 26, 2018 at 11:50 AM, Paul Gilmartin < [email protected]> wrote:
> On Thu, 26 Apr 2018 07:33:39 +0200, Peter Hunkeler wrote: > > > >>IMHO it is problem with IBM. Are you deaf? > >Sometimes it is; sometimes they are. However, not this time. > > > >>People really NEED the functionality to simply make single dataset > archive, transmit it to PC *with no tricks and black magic* and then upload > it to a z/OS and unpack. > > > >Know your job. What is difficult about running two programs one after the > other to get the desired result? > > > IBM could make it easier, rather than assuming the burden of providing > full employment for customers' systems programmers. Ideally: > > All archiving facilities such as ADRDSSU, TERSE, TSO TRANSMIT, pax, > IEBCOPY, > ... should treat their archives as featureless streams which can be wrtteh > to CKD DASD, tape, directed to UNIX files (which could be piped to network > or transmitted via FTP BINARY), ... Extraction should ignore record > boundaries > in those archives. > I agree. Given that XMIT only works with FB/80, I think it would be "reasonable" for it to "assume" that any UNIX data stream fed to it is implicitly FB/80 and just process incoming data in 80 byte "chunks" (aka records). > > pax does this well. Its archives can be CKD data sets (and it's > nondiscriminatory > concerning DCB attribute) or UNX files, and I can usefully: > pax -w directory | ssh some.host "pax -vr" # (Simplified.) > > Example: GIMZIP relative files are IEBCOPY PDSU which GIMZIP transforms > to UNIX > files and RECEIVE FROMNTS transforms back to Classic PDSU. Considerable > overhead > in processing and allocation of temp ds could be avoided if IEBCOPY deaht > directly > with UNIX files as PDSU. > Unfortunately, IEBCOPY already has the "cruft" of using physical size of the block written to disk as implicit data describing the schema(?). What I have wondered about is possible ability of "emulating" RECFM=U by using a UNIX file with FILEDATA=RECORD. The "metadata" which is encoded by the physical size of the block would be replaced by the explicit 4 byte "record length" inserted by the access method due to the FILEDATA=RECORD. > > ... the others shoulc take a c[l]ue. > > -- gil > > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
