Gil, This exit has been around on our systems for many years. It abends the job if Dummy is anywhere in SORTIN or SYSUT1(ICEGENER). I didn’t show the message text, but it indicates that the user needs to replace DUMMY with a real dataset - SYS2.DUMMY that is allocated as RECFM=U, LRECL=0, BLKSIZE=0, and occupies 1 track.
This behavior is also documented in the SORT manual too. I get what you say about a sophisticated programmer doing it on purpose, but the problem outweighs the benefits if use was unintentional. I had questioned DFSORT development group a couple years ago trying to argue my point that DFSORT shouldn’t end with RC0, maybe a RC4 or RC8 with a warning message. Or maybe a configurable option on desired SORT behavior. It's an exit that I am afraid will be on my systems long after I retire. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, January 30, 2014 7:02 PM To: [email protected] Subject: Re: Dummy dataset 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
