On Tue, 16 Sep 2014 13:29:57 -0700, Charles Mills wrote: >Yup. Over-engineering. Over-validation. Like examining a filename to see if it >is syntactically valid rather than just passing it to the OS's open function >and seeing if it works for the OS. > There's a partial and mostly unsatisfactory conjectural explanation for the rule in what I see in the OUTPUT from the FTP step: EZA1736I put //DD:SYSUT1 TEMP.FTPCAT EZA1701I >>> SITE VARrecfm LRECL=80 RECFM=V BLKSIZE=84 500 'SITE VARRECFM LRECL=80 RECFM=V BLKSIZE=84': command not understood.
Apparently FTP attempts to inform the receiving system of the attributes of the file by the content of the SITE command. It tries to get these attributes from the first catenand, making a couple bad assumptions: o Attributes of that data set are valid iff it has been initialized. o It has been initialized only iff non-empty. o JES guarantees good attributes for an instream data set. Also, there seems to be some evidence that FTP falters without reporting qny error on a catenation of data sets with unlike attributes. Is this a documented restriction. I hate MVS! (z/OS? OS/360? Whatever?) There's an aphorism to the effect that MVS is notorious for solving (poorly, often, IMO) problems that would never arise on any other OS. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
