On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com> wrote:
> So do we. > > And I wonder what the actual problem is? If the DFDSS dump dataset has > such a special (internal) format, that FTP cannot always handle it > correctly, why can AMATERSE do this without problems? > A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on DASD, with no imbedded (in the data) of where the record ends. This is a artifact of the ECKD format that only the IBM z (as far as I know) uses. AMATERSE encodes the length of each physical block actually read into its data stream. And it produces FB output. So when you send it somewhere, the LRECL is always known. AMATERSE uses the encoded data in the FB to restore the data onto disk in the same PHYSICAL format that it was unloaded, making it usable once again by DFDSS. IMO, DFDSS should just have used VB or VBS format. > > If it FTP only, what is the special problem for FTP? What other dataset > formats are a problem for FTP? > Not FTP only. > > Questions, Fear, Uncertainty and Doubt... > > Kees. > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
