> Does this imply that I can't code two separate DD statements, each containing the "DDNAME=..." option in the same PROC, where they refer to separate concatenations, respectively?
Not sure that I read that into it, although it certainly is possible >User Response: If the DDNAME reference was intended to refer to the >entire concatenation, move the concatenated DDs to follow the >referencing DD rather than the referenced DD. This will ensure that the You would expect that given //REFFING DD DDNAME=REFFED that REFFED could be any valid DD statement. But it appears that what they are saying is that the following will not work: //REFFING DD DDNAME=REFFED ... //UNRELATE DD DSN=dsname.zero,... //REFFED DD DSN=dsname.one,... // DD DSN=dsname.two,... // DD etc. I think it fails the least astonishment test, particularly in that dsname.two will end up getting concatenated to //UNRELATE DD. I could see someone spending hours debugging some S0C5 or 6 from invalid input because of a totally inappropriate input file. I think they are saying that only the following will work. It's arguably less useful; it's certainly less useful than "either/or." // DD DSN=some.other.dsn or similar ... // DD etc.... ... //REFFED DD DSN=dsname.one,... I can certainly understand the design issues in doing it right, given implementation in assembler originally for a 44K region. Think about it. A "full" implementation would allow the following. This is certainly a handful! //REFFING DD DDNAME=REFFED1 // DD DDNAME=REFFED2 ... //REFFED1 DD DSN=dsname.one,... // DD DSN=dsname.two,... // DD etc. ... //REFFED2 DD DSN=dsname.three,... // DD DSN=dsname.four,... Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Wednesday, June 06, 2012 8:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JES/2 Proc SYSIN Concat Error?? On Tue, 5 Jun 2012 13:59:25 -0700, Lizette Koehler <stars...@mindspring.com> wrote: > >IEF694I DDNAME REFERENCE TO DD CONCATENATION REFERS ONLY TO FIRST DD > >Explanation: THE JCL DDNAME keyword has been used to refer to a DD >concatenation. When the object of a DDNAME reference is a concatenation >of multiple DDs, only the first DD in the concatenation is actually >referenced. > >System Action: The system issues message IEF677I and continues >processing the job. The first DD in the referenced concatenation is >associated with the referencing DD. The remaining (unlabeled) DDs in >the referenced concatenation are concatenated to the labeled DD >immediately preceding the concatenation. > >User Response: If the DDNAME reference was intended to refer to the >entire concatenation, move the concatenated DDs to follow the >referencing DD rather than the referenced DD. This will ensure that the >concatenation is correctly defined to the system. > Was this truly the intent of the design, or did it just happen to work that way, so they documented it as a feature? Does this imply that I can't code two separate DD statements, each containing the "DDNAME=..." option in the same PROC, where they refer to separate concatenations, respectively? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
