On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) <[EMAIL PROTECTED]> wrote: >Try this: > >//IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200 >//COBOL EXEC PGM=IGYCRCTL,REGION=2048K >//STEPLIB DD DSNAME=&LNGPRFX..SIGYCOMP, >// DISP=SHR >//* >//SYSLIB DD DDNAME=OWNSYSLB >// DD DISP=SHR,DSN=APPL.PROD.COPYLIB >//* >//OWNSYSLB DD DISP=(NEW,KEEP),DSN=&&OWNSYSLB, >// SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760 >//* >... >... > > >If you don't need any personal SYSLIB library, code: > >//S1 EXEC IGYWC.... >//* >//COBOL.SYSIN DD * > your cobol code goes here.... >/* > >and the compiler will only see APPL.PROD.COPYLIB > >If you need one private library ahead of the APPL-lib, >code: > >//S1 EXEC IGYWC.... >//* >//OWNSYSLB DD DISP=SHR,DSN=your.own.private.copy.lib1 >//* >//COBOL.SYSIN DD * > your cobol code goes here.... >/* > >and the compiler will see your private library ahead of >the APPL.PROD.COPYLIB library. > >If you need more than one private library, three in this >example, code: > >//S1 EXEC IGYWC.... >//* >//OWNSYSLB DD DISP=SHR,DSN=your.own.private.copy.lib1 >// DD DISP=SHR,DSN=your.own.private.copy.lib2 >// DD DISP=SHR,DSN=your.own.private.copy.lib3 >//* >//COBOL.SYSIN DD * > your cobol code goes here.... >/* > >and the compiler will see all the three private libraries >ahead of the APPL.PROD.COPYLIB library.
This seems to be a great idea. Such a great idea that I had already tried it. But it does not work as you might expect! "Location of DD Statements for Concatenated Data Sets: To concatenate data sets to a data set defined with a DDNAME parameter, the unnamed DD statements must follow the DD statement that contains the DDNAME parameter, not the referenced DD statement that defines the data set." "References to Concatenated Data Sets: If you make a forward reference to a concatenation, the forward reference resolves to the first data set in the concatenation. If there are no DD statements between the forward reference and the concatenation, the rest of the data sets in the concatenation are appended to the first data set in the concatenation." Basically, this appears to say that only the named DD in the override is used to replace the the DD where the DDNAME is specified. Take the following example: (proc) //COBOL PROC COBOPT= //COB EXEC PGM=IGYCRCTL,REGION=4096K,PARM='&COBOPT' //SYSIN DD DISP=SHR,DSN=FJS.PDSE.COBOL(&MEMBER) //SYSPRINT DD SYSOUT=* // INCLUDE MEMBER=COBWORK //SYSLIN DD DSN=&&OBJECT,DISP=(NEW,PASS,DELETE), // SPACE=(400,(100,50)) //DUMBDD DD //SYSLIB DD DDNAME=SYSLIBC // DD DISP=SHR,DSN=APPL.PROD.COPYLIB //SYSLIBC DD DISP=SHR,DSN=FJS.DUMMY.COBOL // PEND (job) //COBOBJ JOB CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID,COND=(4,LT) // SET MEMBER=OBJ1 //STEP01 EXEC COBOL //SYSLIBC DD DISP=SHR,DSN=FJS.PDSE.COBOL // DD DISP=SHR,DSN=FJS.TEST.COBOL This actually *almost* works. But it is only coincidence, and even then it still doesn't do what I require. Take a look at this from JESYSMSG: IGD106I SYS08317.T170101.RA000.COBOBJ.OBJECT.H01 PASSED, DDNAME=SYSLIN IGD104I FJS.PDSE.COBOL RETAINED, DDNAME=SYSLIB IGD104I APPL.PROD.COPYLIB RETAINED, DDNAME= IGD104I FJS.TEST.COBOL RETAINED, DDNAME= What happened here is that FJS.PDSE.COBOL, which is the DSN in the DD override named SYSLIBC replaces the one in the proc (FJS.DUMMY.COBOL). The unnamed one (FJS.TEST.COBOL) is not inserted between this one and the unnamed one in the proc (APPL.PROD.COPYLIB). Rather, it is appended to the end. And the only reason *that* even happens is because SYSLIB is the last DD that is not a DD specified in DDNAME. Or something like that. Specifically, look what happens when I insert "//DUMBDD DD" between SYSLIB and SYSLIBC in the proc: IGD106I SYS08317.T170324.RA000.COBOBJ.OBJECT.H01 PASSED, DDNAME=SYSLIN IGD104I FJS.PDSE.COBOL RETAINED, DDNAME=SYSLIB IGD104I APPL.PROD.COPYLIB RETAINED, DDNAME= IGD105I SYS08317.T170324.RA000.COBOBJ.R0100136 DELETED, DDNAME=DUMBDD IGD104I FJS.TEST.COBOL RETAINED, DDNAME= This shows you that the unnamed DD in the job gets concatenated to, in this case, DUMBDD. Honestly I have a hard time imagining anyone actually wanting this to work this way. I can see wanting both concatenating to the end or concatenating to the front of specific DD's, but to just do it to the end of one just because it's the last one; Yikes! Had I not both read and tested this I never would have believed it! It does, by the way, give you a warning that this occured: "25 IEF694I DDNAME REFERENCE TO DD CONCATENATION REFERS ONLY TO FIRST DD". Frank ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
