On Tue, 16 Sep 2014 11:40:58 -0700, Richard Pinion wrote: > >To prevent transferring data from an empty file, FTP checks whether the first >file in a concatenation series is empty and allocates an empty data set. No >data is transferred. > Morons. Obsessive-compulsive morons. The test is otiose. If any catenand is empty, EODAD will immediately be entered for that catenand and no data will be transferred. But that shouldn't prevent transferring the remaining catenands. There is no more reason for FTP to treat "empty" as a special case than for access methods to do so in general.
BTW, what happens if the first is non-empty, but the second is empty? Are third and subsequent catenands transferred. This strikes me as comparable to the JCL behavior that "PATH='/dev/null'" is replaced by "DUMMY". Probably an ancient MVS hand with tunnel vision found a statement in a Users Guide that "/dev/null is like DUMMY" and opened an SR that catenands after /dev/null were nonetheless processed. Support agreed with his ignorance and made the change. And once such conceptual blunders are codified in the documentation they become part of the design, which can never be ameliorated. Morons. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
