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.
DDBAD MVC SAVWTO(WTOLST1L),WTOLIST1
MVC SAVWTO+12(6),DDNAME
SR R0,R0
LA R1,SAVWTO
WTO MF=(E,(R1))
MVC SAVWTO(WTOLST2L),WTOLIST2
SR R0,R0
LA R1,SAVWTO
WTO MF=(E,(R1))
ABEND LA R0,WORKLEN LOAD LENGTH OF WORKAREA
LR R1,R11 LOAD ADDRESS OF WORKAREA
FREEMAIN R,LV=(R0),A=(R1) FREE WORKAREA
ABEND 53
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Paul Gilmartin
Sent: Thursday, January 30, 2014 3:57 PM
To: [email protected]
Subject: Re: Dummy dataset
On Thu, 30 Jan 2014 20:18:05 +0000, Jousma, David wrote:
>We have an exit for DFSORT that scans TIOT to see if someone concatenated a
>DUMMY dataset as input. Here is what I believe to be the relevant snippet of
>code:
>
Comments inline.
>*---------------------------------------------------------------------*
>* THIS ROUTINE WAS ADDED TO CIRCUMVENT A PROBLEM CREATED BY DUMMY *
>* FILES SPECIFIED FOR SORTIN. *
>*---------------------------------------------------------------------*
>
This "PROBLEM" sounds like a bug, which ought to be subject to APAR.
>DDSCAN DS 0H
> EXTRACT FW,'S',FIELDS=(TIOT),MF=(E,EXTRACTL)
> L R5,FW
> USING IEFTIOT1,R5
> MVC DDNAME,=CL8'SORTIN' SET DEFAULT DDNAME
> TM ILEXF2A,ILEXFCPY Q. COPY APPLICATION ?
> BZ DDSRCH A. NO, SEARCH FOR SORTIN
> MVC DDNAME,=CL8'SYSUT1' A. YES, SEARCH FOR SYSUT1
>DDSRCH CLC TIOEDDNM,DDNAME Q. DDNAME MATCH
> BE DDCON A. YES, CHECK IT OUT
> SR R0,R0 CLEAR REGISTER
> IC R0,TIOELNGH GET LENGTH OF THIS ENTRY
> AR R5,R0 BUMP TO NEXT ENTRY
> CLI TIOELNGH,X'00' Q. END OF TIOT ?
> BE RETURN A. YES, GET OUT
> B DDSRCH A. NO, KEEP LOOKING
>DDCON DS 0H CHECK FOR CONCATENATION
>* IF NOT CONCATENATION, THEN SKIP
> SR R0,R0 CLEAR REGISTER
> IC R0,TIOELNGH GET LENGTH OF THIS ENTRY
> AR R5,R0 BUMP TO NEXT ENTRY
> CLI TIOELNGH,X'00' Q. END OF TIOT ?
> BE RETURN A. YES, GET OUT
> CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED?
> BNE RETURN A. NO, FORGET IT
> SR R5,R0 A. YES, RESTORE DSECT POINTER
>* CHECK FOR DUMMY DD STATEMENT
>* NOTE: COULD ALSO BE DD *
>
Does this mean that "DD *" (also "DD DATA"?) is problematic, even as DUMMY?
What about "DD PATH='...'"?
>DDCHK CLC TIOEFSRT,=AL3(0) Q. REAL UCB ADDRESS ?
> BE DDBAD A. NO, BAD DD
>
Where's label "DDBAD"?
> SR R0,R0 CLEAR REGISTER
> IC R0,TIOELNGH GET LENGTH OF THIS ENTRY
> AR R5,R0 BUMP TO NEXT ENTRY
> CLI TIOELNGH,X'00' Q. END OF TIOT ?
> BE RETURN A. YES, GET OUT
> CLC TIOEDDNM,=CL8' ' Q. SORTIN CONCATENATED?
> BE DDCHK A. YES, CHECK AGAIN
> B RETURN
-- 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
