On 2014-01-30 14:04, Jousma, David wrote: > We had some enterprising programmers that coded jobs something like: > > //SORTIN DD DSN=a.data.set.name,disp=shr > // dd &dd1,disp=shr > // dd &DD2,disp=shr > // dd dsn=another.data.set.name,disp=shr > > And in the proc defaulted &DD1, and &DD2 to DUMMY so that they could > dynamically change the input datasets. Problem was when they didn’t use > them or only one of them, DFSORT stops reading input and the real datasets > beyond the dummy ones never got read, and the JOB finished with RC(0), so it > was obvious there was missing data. With the exit we abend the job. > Much as I detest that behavior (I'd much prefer that DUMMY behaved as "DD SPACE=0"), it's documented in JCL Ref. or Using Data Sets or somewhere, so WAD. Implementing DWIM, as you appear to be trying to do is an endless and mostly thankless task. And a sophisticated programmer who knowingly codes DUMMY (perhaps to disable some catenands for a test) has much reason to complain when experiencing behavior not only unexpected but also contrary to OS documentation.
Have you tried (or suggested) using "DD SPACE=0" in place of DUMMY? Even worse (also documented) Allocation substitutes DUMMY for "PATH='/dev/null'" or "PATH='//dev/null'", which I deem a colossal misapplication of DWIM by the OS designers. There was *no* reason to do that. They might as well, and with similar rationale substitute DUMMY for SPACE=0. Fortunately, Allocation is sufficiently dumb that it fails to recognize and override the otherwise equivalent "PATH='/dev//null'". Do you ABEND only if DUMMY is followed by a non-dummy data set? There should be no problem if DUMMY (or several) is/are the last catenand(s). -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
