I was wondering (though I might be wrong) if the use of INCLUDE statements might not help.
Inside the PROC itself you could have //IGYCW PROC //COMPILE EXEC PGM=xxxxx // INCLUDE MEMBER=DEVEL1 Developers Copylib Dataset // INCLUDE MEMBER=APPL1 Specific Application Copylib Dataset // INCLUDE MEMBER=SYSLIB1 System specific Copylib Dataset Then in your PROCLIB dataset you would have coded for each member Member DEVEL1 //SYSLIB DD DISP=SHR,DSN=DEVELP.COPYLIB a data set always used. Member APPL1 //* Member SYSLIB1 // dd disp=shr,dsn=sys1.igycopy1 // dd disp=shr,dsn=sys1.copylib The expansion should look like //COMPILE EXEC PGM=xxxxx //SYSLIB DD DISP=SHR,DSN=DEVELP.COPYLIB //* // DD DISP=SHR,DSN=SYS1.IGYCOPY1 // DD DISP=SHR,DSN=SYS1.COPYLIB This way you would not need to know how many or where to put your over rides. You can update the Include members with what you want to use. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Gilmartin > Sent: Monday, November 10, 2008 7:32 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: procs and concatenations > > On Mon, 10 Nov 2008 15:35:26 -0800, Raymond Noal wrote: > > > >If you want a private PDS/Copybook to precede your production COBOL > copy book PDS and have it unique to each user, how about this - > > > >//syslib dd dsn=&sysuid..pvtcobol.copylib > >// dd dsn=appl.prod.copylib > > > Then each user must allocate "&sysuid..pvtcobol.copylib" > lest he get a JCL error: "DATA SET NOT FOUND". > > >-----Original Message----- > >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Frank Swarbrick > >Sent: Monday, November 10, 2008 3:19 PM > > > >I have a question that is going to keep bugging me until I ask it, > even though > >I'm fairly certain I will not be happy with the answer... > > > Alas and amen. > > >//COBOL.SYSLIB DD DISP=SHR,DSN=FJS.PDSE.COBOL > >// DD DISP=SHR,DSN=APPL.PROD.COPYLIB > > > >Specifically, I am compiling Cobol source found in > FJS.PDSE.COBOL(OBJ1) and > >including copybooks that are found in either FJS.PDSE.COBOL or > >APPL.PROD.COPYLIB. > > > >The way we've gotten around it so far is to have something like this > in the > >proc: > > > >//SYSLIB DD DSN=&CLIB1,DISP=SHR > >// DD DSN=&CLIB2,DISP=SHR > >// DD DSN=&CLIB3,DISP=SHR > >// DD DSN=&CLIB4,DISP=SHR > >// DD DSN=&CLIB5,DISP=SHR > >// DD DSN=&CLIB6,DISP=SHR > > > >and have the PROC step changed like this: > >//IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200, > >// CLIB1='APPL.PROD.COPYLIB', > >// CLIB2='APPL.PROD.COPYLIB', > >// CLIB3='APPL.PROD.COPYLIB', > >// CLIB4='APPL.PROD.COPYLIB', > >// CLIB5='APPL.PROD.COPYLIB' > > > >And the JCL to execute the proc would be this: > >//COMPILE EXEC PROC=IGYWC,LNGPRFX=IGY, > >// CLIB1='FJS.PDSE.COBOL' > > > Or, the user could supply overrides. > > >This works, but: > >- It requires you know ahead of time (when building the PROC) the > maximum > >number of copylibs that will ever be used. > > Three ought to be enough -- ISPF only allows three and > ISPF is never wrong. > > Notwithstanding Bill Waite tried to teach me, "There are > only three nice numbers: zero, one, and as many as you like!" > > >- It seems silly to have to include the same library over and over. > > > The overhead is it's allocated and opened over and over. > A successful BLDL will never search directories over and > over more than necessary. An unsuccessful BLDL ... but > why fret over performance of the error case? > > In Rexx I do this by attempting to allocate each catenand > and catenating only those for which the allocation succeeds. > > I hate JCL! > > -- gil > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
