On Wed, 25 Jan 2023 20:24:59 +0000, Andrew N Wilt wrote: > ... Apparently, they are able to decipher the RDW records resulting from > uploading a RECFM=VBS as a RECFM=U. Unfortunately, at this time, GDKUTIL > doesn't have the smarts to parse the bytestream as RDW+data as it is writing > to the output data set. That is a current Request For Enhancement, though. > It's not so hard. The necessary format descriptions are in "Using Data Sets" (I believe; perhaps also elsewhere.) Long ago, I did an experiment; a PoC. IBM conveniently provided the input data in SMP/E SMPNTS which is exactly such a bytestream representation of an IEBCOPY-unloaded data set, pax-compressed. I uncompressed one with pax and allocated it as PATH(...) FILEDATA(BINARY) RECFM(VB) LRECL(1000) ... FILEDATA(BINARY) causes the BDW qnd SDW images to be read as data (with EXECIO). I was able to reorganize the 1000-byte chunks into the original blocks. In that era, EXECIO couldn't handle RECFM(U), so I tried LMPUT. First try failed -- ISPF bug, fixed with APAR. (LMPUT had been unable to deal with RECFM(U) with data above 16 MiB. The surprising repair was that LMPUT was changed to copy the data below the line.) I took the output data set, overrode RECFM(U) to RECFM=VBS and successfully reconstructed the PDS with IEBCOPY.
Tthe RFE should provide a set of utilities to convert various DSORGs to simple bytestreams and back. They should be pipe-savvy, and FTP client should be made pipe-savvy to eliminate requirements for temporary data sets. Better sftp, which is based on ssh, already pipe-savvy. (But what about restart from broken connection?) All forbidden by Conway's Law. >Sincerely, >Andrew Wilt > >DFSMSdfp Cloud Data Access Product Owner >DFSMShsm development -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
