Re: procs and concatenations
Paul Gilmartin wrote: Hmmm. A colleague eschews DSN=NULLFILE because he believes that the initiator issues an ENQ for NULLFILE. Is that also in the statement used to be true category? I ran some tests, and on the earliest system I could get my hands on, MVS 3.8, DSN=NULLFILE is sufficient to define a dummy file, and it does not cause an ENQ. I do not recall having any enqueue hangs on the name, so I'm not even sure it was true in MVT. Gerhard Postpischil Bradford, VT -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 19:17:08 +, john gilmore wrote: //LIB1 DD DSN=A.B.C,DISP=SHR //DD DSN=A.B.C,DISP=SHR is licit. One may, that is, concatenate a library with itself; and the only penalty incurred by doing so is a small amount of sometimes gratuitous overhead. That said, why do this? The answer is that if the first DSN= value is parameterized and given a default value equal to the value of the second, the default value of the first can be overridden if a second library is needed and ignored if not. This scheme also generalizes readily to situations in which more than one placeholder is needed. About the differences between DSN=NULLFILE and DUMMY I have nothing new to say. The mob was wrong on that earlier occasion, and it is wrong again now. It may be, however, that this placeholder example will suggest one of the crucial differences between DUMMY and DSN=NULLFILE to an 'alert reader'. Perhaps I am not sufficiently alert. AFAIK, there is no value for either DUMMY or NULLFILE in the above placeholder example. Perhaps you could enlighten us if you know any. Certainly, it would not be useful to override the dsname in the example to NULLFILE, as that would cause a S013-64 abend. As to your previous posts on this subject, On Tue, 31 May 2005 15:16:36 +, john gilmore wrote: Once written within a procedure neither of the DD statements //ddname DD DUMMY or //ddname DD DUMMY, . . . can be altered into one that in fact is functional, permits non-null outputs to be written or non-null inputs to be read. On the other hand //SYSPRINT DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA can be altered readily by simply supplying a different licit value of DSN=. This difference was the basis for my statement that DSN=NULLFILE was superior to DUMMY when used inside procedures. This assertion is inconsistent with the documented behavior. It is also just plain wrong, as can easily be confirmed. A DD DUMMY... can be overridden by supplying an overriding DD statement containing a DSNAME other than NULLFILE. The DUMMY parameter can also be overridden by a path other than /dev/null, SYSOUT, *, DATA or SUBSYS. Furthermore, any other parameters that were specified on the DD DUMMY will be used. I tested this and invite others to do likewise. Finally, On Fri, 27 May 2005 22:35:28 +, john gilmore wrote: Let me, however, rehearse what I said originally at greater length. Coding DUMMY has the effect that everything following it is ignored, no DCB information is retained. I'm sorry, but you are mistaken on this. It is not true on z/OS 1.9, the release that I tested with. Indeed, DCB subparameters may be required to complete the DCB in order to avoid abends. Coding DSN=NULLFILE,DCB=... permits NULLFILE to be overridden and the retained DCB info to be used. As does coding DD DUMMY... DCB and other parameters coded with DUMMY are used when DUMMY is overridden. About citations of the obvious I grow less and less patient as I age. There are days when I am still prepared to summon up arguments for the oblate sphericity of the earth to confute some flat-earther, but there are other days when I am not. We are not flat-earthers. We are reasonably intelligent people who are willing to learn. Do you have anything to contribute or does it please you to insult us? You have asserted that DUMMY and NULLFILE are different. Thus far, your assertions are unfounded. The JCL manual snippet quoted by Paul Gilmartin, The system ignores all parameters other than DUMMY or DSNAME=NULLFILE and DCB. The DCB parameter must be coded if you would code it for normal I/O operations. ... specifies just exactly the behavior I describe above. Moreover, it does so in language that seems to me to be quite clear enough. In standard English the boolean operator AND takes precedence over the boolean operator OR: 'A or B and C' means '(A) or (B and C)'. Expanded, this snippet thus means o If you code DUMMY all else is ignored o If you code DCB=NULLFILE, DCB information will be retained. Assuming that you are correct about the precedence of AND over OR in standard English, what you have stated does indeed seem obvious. I am not aware of this precedence, though. However, it is inconsistent with other statements in the JCL manuals. Specifically,in the JCL Reference, section 12.24 DUMMY Parameter, it reads, Code the DCB parameter, if needed. If the program does not supply all the data control block information, make sure that the DCB parameter supplies the missing information. -- Tom Marchant -- 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
Re: procs and concatenations
Tom Marchant has made another of his characteristic contributions---They are comprised of much rhetoric sprinkled with elements of correct but irrelevant information---to this thread. My post addressed the problem of providing a placeholder for a sometimes but not always required DD statement within a (cataloged or in-line) JCL procedure. It provided such a mechanism (one that generalizes to provide not just one but n such placeholders) for doing this parametrically; and Mr. Marchant does not dispute that this scheme does just that (or even address its substance). I then added en passant, because another poster to this same thread had said that everyone but John Gilmore had judged that DSN=NULLFILE and DD DUMMY were equivalent, that they were not in fact equivalent, suggesting that my placeholder scheme illustrated one of the ways in which they are different. Now this scheme uses parametric replacement of a default DSN= value by another, non-default one; and one of the merits of the DSN=NULLFILE construction is that it can be used to make such parametric substitutions possible, albeit not as a placeholder.In addressing this not very tendentious observation, if that in fact is what he was doing, Mr. Marchant reminded me that an entire DD DUMMY statement can also be overridden. This is true, and I am also prepared to concede that the earth is an oblate spheroid. John Gilmore Ashland, MA 01721-1817 USA _ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/ -- 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
Re: procs and concatenations
On Wed, 12 Nov 2008 20:06:42 +, john gilmore wrote: Tom Marchant has made another of his characteristic contributions... Thank you. And Mr. Gilmore has once again failed to shed any light. Mr. Marchant reminded me that an entire DD DUMMY statement can also be overridden. This is true, and I am also prepared to concede that the earth is an oblate spheroid. Huh? It is indeed true that an entire DD DUMMY statement can be overridden. That was not, however, the point of my post, nor did I mention it. What I said was: ... A DD DUMMY... can be overridden by supplying an overriding DD statement containing a DSNAME other than NULLFILE Furthermore, any other parameters that were specified on the DD DUMMY will be used. This was not a reference to overriding an entire DD statement. Let me spell it out for you. If the following DD statement appears in PROC: //DD1 DD DUMMY,DCB=(LRECL=80,BLKSIZE=800,RECFM=FB), //UNIT=3390,VOL=SER=VOL123,SPACE=(TRK,(10,20)), //DISP=(NEW,CATLG) It can be overridden by this: //PROCNAME.DD1 DD DSN=SYS1.TEST The DSName from the overriding DD statement will override the DUMMY parameter and all other parameters from the original DD statement are used. The result is the same as if the original DD statement were coded as: //DD1 DD DSN=SYS1.TEST,DCB=(LRECL=80,BLKSIZE=800,RECFM=FB), //UNIT=3390,VOL=SER=VOL123,SPACE=(TRK,(10,20)), //DISP=(NEW,CATLG) Mr. Gilmore has repeatedly asserted that DUMMY is different from NULLFILE, as for example, On Tue, 31 May 2005 15:16:36 +, john gilmore wrote: Once written within a procedure neither of the DD statements //ddname DD DUMMY or //ddname DD DUMMY, . . . can be altered into one that in fact is functional, permits non-null outputs to be written or non-null inputs to be read. On the other hand //SYSPRINT DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA can be altered readily by simply supplying a different licit value of DSN=. DUMMY and DSN=NULLFILE can both be overridden by simply providing a new DSName. -- Tom Marchant -- 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
Re: procs and concatenations
On Mon, 10 Nov 2008 18:31:40 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: 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. Indeed! I knew that but had forgotten. -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. I'm not sure what you mean here. That is an example of a user override. 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. ! :-) Does anyone out there actually use the ISPF supplied compile screen? Before I got involved with the z/OS stuff a co-worker had already written a REXX panel for our compiles for us to use, so I haven't much looked at the ISPF supplied ones. 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? I fret over everything! :-) Actually, I'm not all that concerned about the performance. I just find it esthetically unpleasing! In Rexx I do this by attempting to allocate each catenand and catenating only those for which the allocation succeeds. I hate JCL! What gets me is that there seem to be so many good things, but most of them don't work like I think they should. One thing that we probably could do is have the REXX exec generate the entire JCL stream. No pre-built proc at all. I'm not excited about that, though, as I think it's probably easier to debug the proc. But I haven't looked at the REXX exec as it is now, so who knows. 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
Re: procs and concatenations
On Wed, Nov 12, 2008 at 6:30 PM, Frank Swarbrick [EMAIL PROTECTED] wrote: Does anyone out there actually use the ISPF supplied compile screen? Before I got involved with the z/OS stuff a co-worker had already written a REXX panel for our compiles for us to use, so I haven't much looked at the ISPF supplied ones. Not any more. We have in-house panels that prompt the user for the program name, a project name and location, and it figures out the rest using definitions stored in an ISPF table. JCL is built using ISPF skeletons. Very simple and has served us well for many years. -- 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
Re: procs and concatenations
On Wed, 12 Nov 2008 17:30:31 -0600, Frank Swarbrick wrote: 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. I'm not sure what you mean here. That is an example of a user override. I meant the user could supply overriding DD statements rather than overriding symbolic parameters. Could then supply attributes, VOL=SER, etc. Three ought to be enough -- ISPF only allows three and ISPF is never wrong. ! :-) Does anyone out there actually use the ISPF supplied compile screen? Before I got involved with the z/OS stuff a co-worker had already written a REXX panel for our compiles for us to use, so I haven't much looked at the ISPF supplied ones. I was thinking not only of compile, but of Edit, Browse, anything that provides a short data set list. I hate JCL! What gets me is that there seem to be so many good things, but most of them don't work like I think they should. It's almost OK if you don't mind counterintuitive. One thing that we probably could do is have the REXX exec generate the entire JCL stream. No pre-built proc at all. I'm not excited about that, though, as I think it's probably easier to debug the proc. But I haven't looked at the REXX exec as it is now, so who knows. I generate more JCL with Rexx than I type directly. And even more with shell scripts and awk. The drawback is that I wind up with two processes where one should suffice, and the top-level process can't easily determine completion status from the subordinate steps. for my particular concerns, it would be a boon if DYNALLOC supported keys necessary to create multi-file tapes, such as VOL=REF, RETAIN, and DEFER. Hmmm. How does SMP/E access relative files when my JCL only allocates the first data set on a tape? -- 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
Re: procs and concatenations
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 //* //SYSLIBDD DDNAME=OWNSYSLB // DD DISP=SHR,DSN=APPL.PROD.COPYLIB //* //OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;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 //SYSLINDD DSN=amp;OBJECT,DISP=(NEW,PASS,DELETE), // SPACE=(400,(100,50)) //DUMBDDDD //SYSLIBDD DDNAME=SYSLIBC // DD DISP=SHR,DSN=APPL.PROD.COPYLIB //SYSLIBC DD DISP=SHR,DSN=FJS.DUMMY.COBOL // PEND (job) //COBOBJJOB CLASS=A,MSGCLASS=X,NOTIFY=SYSUID,COND=(4,LT) // SET MEMBER=OBJ1 //STEP01EXEC 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.COPYLIBRETAINED, 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.COPYLIBRETAINED, 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
Re: procs and concatenations
Tom Marchant wrote: Mr. Gilmore has repeatedly asserted that DUMMY is different from NULLFILE, as for example, That statement used to be true, though not for the reasons Mr. Gilmore cited. For OS/MVT (and possibly MFT), a DSN=NULLFILE would fail unless it also carried a UNIT and VOL specification. I don't recall when the extra check for NULLFILE was added to the interpreter. Gerhard Postpischil Bradford, VT -- 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
Re: procs and concatenations
On Wed, 12 Nov 2008 20:03:03 -0500, Gerhard Postpischil wrote: Tom Marchant wrote: Mr. Gilmore has repeatedly asserted that DUMMY is different from NULLFILE, as for example, That statement used to be true, though not for the reasons Mr. Gilmore cited. For OS/MVT (and possibly MFT), a DSN=NULLFILE would fail unless it also carried a UNIT and VOL specification. I don't recall when the extra check for NULLFILE was added to the interpreter. Hmmm. A colleague eschews DSN=NULLFILE because he believes that the initiator issues an ENQ for NULLFILE. Is that also in the statement used to be true category? -- 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
Re: procs and concatenations
At 16:41 +0100 on 11/11/2008, Hunkeler Peter (KIUK 3) wrote about Re: procs and concatenations: For exactly the same reason you mention I did not want to write DELETE (or let it default), but the usual PASS escaped me when writing the post. I'm not exempt from getting older, it seems. Coding KEEP will cause the temp file to be deleted at Job Term (just like PASS) if I remember correctly. -- 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
Re: procs and concatenations
//OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB, // SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760 //* I don't know about KEEP on a temporary DSN; I'd be more comfortable with PASS. But I'm very uncomfortable with DELETE in a PROC. It has bad effects when I override with a catalogued data set and forget to override DISP. For exactly the same reason you mention I did not want to write DELETE (or let it default), but the usual PASS escaped me when writing the post. I'm not exempt from getting older, it seems. -- Peter Hunkeler -- 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
Re: procs and concatenations
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) wrote: Try this: //SYSLIBDD DDNAME=OWNSYSLB // DD DISP=SHR,DSN=APPL.PROD.COPYLIB //* //OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB, // SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760 //* I don't know about KEEP on a temporary DSN; I'd be more comfortable with PASS. But I'm very uncomfortable with DELETE in a PROC. It has bad effects when I override with a catalogued data set and forget to override DISP. If you need more than one private library, three in this example, code: //* //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 I didn't know that worked with an entire catenation. I had thought the substitution was one-for-one. How useful! Think override rather than substitution. Occasionally there is use for a null override as well. For example, suppose your PROC had the three libraries as listed above: //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 and you wanted to add a fourth library, but make it second in the concatenation and move the current second library to the fourth position. Your invocation JCL need contain only: //OWNSYSLB DD // DD DISP=SHR,DSN=your.own.private.copy.lib4 // DD // DD DISP=SHR,DSN=your.own.private.copy.lib2 -jc- -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 09:27:09 -0600, Staller, Allan wrote: It is, but it fools the converter/interperter into thinking there really is a dataset there and allows the concatenation to proceed, as opposed to DD DUMMY which truncates the concatenation. I remain open to persuasion, although John G. failed to persuade me. What do you mean by truncates the concatenation, not at execution time. I might imagine that you mean that catenands after DUMMY are not processed by the convertor/interpreter (except for a syntactic scan, necessarily). So no TIOT entry would be built for catenands after DUMMY. However: //STEP1EXEC PGM=IEFBR14 //SYSUT1DD DUMMY // DD DISP=SHR,DSN=NO.SUCH.DATASET results in: IEF212I DUMMYCAT STEP1 SYSUT1 +001 - DATA SET NOT FOUND IEF272I DUMMYCAT STEP1 - STEP WAS NOT EXECUTED. It appears to me that the concatenation was not truncated. It's frustratingly ironic that the job fails if the data set can not be allocated, but does not process it when it can be allocated. I'm still interested in seeing a pair of examples where the behavior of DUMMY differs from that of DSN=NULLFILE. Agreed, the effect at execution time is the same. As a programmer, I care much about the effect at execution time, and hardly at all about subtle, almost unobservable, behavior internal to the C/I. -- 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
Re: procs and concatenations
Historically the linking of PL/I programs was slightly complicated because there were two versions of certain library routines, one for COBOL-like single-task applications and another for multitasking ones. These routines, located in two different libraries, had the same names. The scheme used to parameterize this situation was a simple one. It exploited the fact that //LIB1 DD DSN=A.B.C,DISP=SHR //DD DSN=A.B.C,DISP=SHR is licit. One may, that is, concatenate a library with itself; and the only penalty incurred by doing so is a small amount of sometimes gratuitous overhead. That said, why do this? The answer is that if the first DSN= value is parameterized and given a default value equal to the value of the second, the default value of the first can be overridden if a second library is needed and ignored if not. This scheme also generalizes readily to situations in which more than one placeholder is needed. About the differences between DSN=NULLFILE and DUMMY I have nothing new to say. The mob was wrong on that earlier occasion, and it is wrong again now. It may be, however, that this placeholder example will suggest one of the crucial differences between DUMMY and DSN=NULLFILE to an 'alert reader'.John Gilmore Ashland, MA 01721-1817 USA _ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) wrote: Try this: //SYSLIBDD DDNAME=OWNSYSLB // DD DISP=SHR,DSN=APPL.PROD.COPYLIB //* //OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB, // SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760 I sure wish DUMMY didn't truncate the concatenation, but were treated as an empty directory (DSORG=PO), or data set (DSORG=PS), allowing subsequent catenands to be searched or read. Or that there were an alternative keword (DD EMPTY) with that behavior. Or even that there were a standard SYS1.EMPTY.PO and SYS1.EMPTY.PS. (For PS one can use PATH=/./dev/null. But it's ugly.) -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 07:56:53 -0600, Staller, Allan wrote: Try DSN=NULLFILE. See the JCL manuals... We had this discussion about a year ago. At that time everyone except John Gilmore agreed that both according to the JCL manuals and empirically DSN=NULLFILE is quite indistinguishable from DUMMY. I sure wish DUMMY didn't truncate the concatenation, but -- 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
Re: procs and concatenations
It is, but it fools the converter/interperter into thinking there really is a dataset there and allows the concatenation to proceed, as opposed to DD DUMMY which truncates the concatenation. Agreed, the effect at execution time is the same. snipTry DSN=NULLFILE. See the JCL manuals... We had this discussion about a year ago. At that time everyone except John Gilmore agreed that both according to the JCL manuals and empirically DSN=NULLFILE is quite indistinguishable from DUMMY. I sure wish DUMMY didn't truncate the concatenation, but /snip -- 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
Re: procs and concatenations
In most every shop I've worked in, we created some form of SYSx.NULLFILE and/or SYSx.NULLPDS. So I agree, it would be nice if z/OS supplied them. For over 30 years I thought that a DD DUMMY in a PDS concatenation should act as a empty PDS and not a EOF, but IBM did not ask me. I have never seen a practical use where the current EOF behavior was desirable (of course, I've not seen everything). I would tend to support changing the behavior. It would take an organization like SHARE to get IBM to change it, but I expect most people want IBM to work on more important features. -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 07:56:53 -0600, Staller, Allan wrote: Try DSN=NULLFILE. See the JCL manuals... //TEST EXEC PGM=IEFBR14 //STEPLIB DD DSN=NULLFILE // DD DISP=SHR,DSN=SYS1.LINKLIB results in IEC141I 013-64,IFG0196J,PMITCM0L,TEST,STEPLIB,,,NULLFILE An OPEN macro instruction was issued for a dummy data set using an access method other than QSAM or BSAM. Correct the DD statement to specify a real data set, or access the data set using BSAM or QSAM. -- Tom Marchant -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 11:08:32 -0600, Tom Marchant wrote: On Tue, 11 Nov 2008 07:56:53 -0600, Staller, Allan wrote: Try DSN=NULLFILE. See the JCL manuals... //TEST EXEC PGM=IEFBR14 //STEPLIB DD DSN=NULLFILE // DD DISP=SHR,DSN=SYS1.LINKLIB results in IEC141I 013-64,IFG0196J,PMITCM0L,TEST,STEPLIB,,,NULLFILE OK. I stand corrected, somewhat. I had misremembered that DUMMY (or NULLFILE) in a library concatenation merely caused following catenands to be ignored. The fact remains that NULLFILE can not be used as a placeholder for overrides or to nullify an interior catenand while leaving those before and after unaffected. -- 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
Re: procs and concatenations
Try DSN=NULLFILE. See the JCL manuals... snip I sure wish DUMMY didn't truncate the concatenation, but were treated as an empty directory (DSORG=PO), or data set (DSORG=PS), allowing subsequent catenands to be searched or read. Or that there were an alternative keword (DD EMPTY) with that behavior. Or even that there were a standard SYS1.EMPTY.PO and SYS1.EMPTY.PS. (For PS one can use PATH=/./dev/null. But it's ugly.) /snip -- 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
Re: procs and concatenations
On Tue, 11 Nov 2008 08:22:40 +0100, Hunkeler Peter (KIUK 3) wrote: Try this: //SYSLIBDD DDNAME=OWNSYSLB // DD DISP=SHR,DSN=APPL.PROD.COPYLIB //* //OWNSYSLB DD DISP=(NEW,KEEP),DSN=amp;OWNSYSLB, // SPACE=(TRK,(1,,1)),RECFM=U,LRECL=32760 //* I don't know about KEEP on a temporary DSN; I'd be more comfortable with PASS. But I'm very uncomfortable with DELETE in a PROC. It has bad effects when I override with a catalogued data set and forget to override DISP. If you need more than one private library, three in this example, code: //* //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 I didn't know that worked with an entire catenation. I had thought the substitution was one-for-one. How useful! -- 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
Re: procs and concatenations
This is my idea, for whatever it may be worth. I would create a proc with something like: //SYSLIB DD DISP=SHR,DSN=some.empty.pds // INCLUDE MEMBER=prelibs // DD DISP=SHR,DSN=first.standard.library // DD DISP=SHR,DSN=second.standard.library //* OTHER STANDARD LIBRARIES, IN ORDER // INCLUDE MEMBER=postlibs //* END OF SYSLIB CONCATENATION. In the standard PROCLIB, have a member called prelibs (replace with something specific) which again allocates some.empty.pds. Also, have a member called postlibs (again, rename as desired) which also has just some.empty.pds allocated. Now, if somebody wants to replace prelibs or postlibs, they simply have either or both of those members in their own PROCLIB. They then tell JES to use their proclib by putting it first in the ORDER=(...) concatenation of the JCLLIB statement. Another possibility is an extention of that. Instead of hardcoding the name prelibs or postlibs, use SET variables to specify the name of the member to be INCLUDE'd. Like: //PROCLIB JCLLIB ORDER=(...) // SET PRELIBS=member1 // SET POSTLIBS=member2 //STEP1 EXEC PROC=proc //* OTHER JCL. The proc would be similar to the above, but slightly altered: //SYSLIB DD DISP=SHR,DSN=some.empty.pds // INCLUDE MEMBER=PRELIBS // DD DISP=SHR,DSN=first.standard.library // DD DISP=SHR,DSN=second.standard.library //* OTHER STANDARD LIBRARIES, IN ORDER // INCLUDE MEMBER=POSTLIBS //* END OF SYSLIB CONCATENATION. Hope this makes sense. -- John -- 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
Re: procs and concatenations
Argh, I forgot to describe something else I tried that did not work: In the proc: //SYSLIBDD DISP=SHR,DSN=APPL.PROD.COPYLIB // DD DDNAME=COPYLIB2 // DD DDNAME=COPYLIB3 In the JCL //STEP01EXEC IGYWG ... //COBOL.COPYLIB2 DD DSN=FJS.PDSE.COBOL,DISP=SHR This works if I always include a COPYLIB2 and COPYLIB3 DD override in the JCL, but if I don't I get IEF450I COBOBJ COB STEP01 - ABEND=S013 U REASON=0064 292 IEC141I 013-64,IFG0194A,COMPILE,COBOL,SYSLIB-0003,047E,PRD001,NULLFILE IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=013 REASON CODE=0064 TIME=16.26.37 SEQ=00316 CPU= ASID=002C The reason code of 64 means: An OPEN macro instruction was issued for a dummy data set using an access method other than QSAM or BSAM. Correct the DD statement to specify a real data set, or access the data set using BSAM or QSAM. It seems to not like a NULLFILE for a PDS. Looking at it again I'm not sure if this, even if it worked, but be all that much better. You still have to know what the maximum number of concatenations will be. It does seem a bit cleaner, IMO, but... 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
Re: procs and concatenations
Frank, 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 HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Frank Swarbrick Sent: Monday, November 10, 2008 3:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: procs and concatenations 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... The following is the system supplied Cobol compile procedure, IGYWC: //IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200 //COBOL EXEC PGM=IGYCRCTL,REGION=2048K //STEPLIB DD DSNAME=LNGPRFX..SIGYCOMP, // DISP=SHR //SYSPRINT DD SYSOUT=* //SYSLIN DD DSNAME=amp;LOADSET,UNIT=SYSALLDA, // DISP=(MOD,PASS),SPACE=(TRK,(3,3)), // DCB=(BLKSIZE=SYSLBLK) //SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT2 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT3 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT4 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT5 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT6 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) //SYSUT7 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1)) This can be executed with something like the following: //FJS1 JOB CLASS=A,MSGCLASS=X,NOTIFY=SYSUID // JCLLIB ORDER=(IGY.SIGYPROC) //*--- //COMPILE EXEC PROC=IGYWC,LNGPRFX=IGY //COBOL.SYSIN DD DISP=SHR,DSN=FJS.PDSE.COBOL(OBJ1) //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. In this case APPL.PROD.COPYLIB is the production copylib and FJS.PDSE.COBOL contains my private source code (including copybooks). If I wanted to compile without my private library I obviously would just have //COBOL.SYSLIB DD DISP=SHR,DSN=APPL.PROD.COPYLIB in place of the two PDS's specified in the first example. What I would like, but cannot seem to figure out how to accomplish, is to have a DD for APPL.PROD.COPYLIB in the actual proc, and allow a developer to, if desired, add just their own private library statements in their JCL. There appears to be no way to do this. If the JCL just has //COBOL.SYSLIB DD DISP=SHR,DSN=FJS.PDSE.COBOL then APPL.PROD.COPYLIB is no longer included in the concatenation. Obviously I could have APPL.PROD.COPYLIB in the proc and just have the calling JCL concatenate both libraries explicitly. But this seems to me to defeat the reason for having the SYSLIB specified in the proc; since you have to override it when including another library. 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' This works, but: - It requires you know ahead of time (when building the PROC) the maximum number of copylibs that will ever be used. - It seems silly to have to include the same library over and over. I have a similar issue with the link (bind) step. I always want to concatenate the SCEELKED library and our PROD load library. And optionally one or more developer libraries. Or possibly an IMS library and/or a CICS library. Thanks for any thoughts, Frank -- Frank Swarbrick Senior Systems Analyst - Mainframe Applications FirstBank Data Corporation Lakewood, CO USA -- 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
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
Re: procs and concatenations
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=x // INCLUDE MEMBER=DEVEL1 Developers Copylib Dataset // INCLUDE MEMBER=APPL1Specific 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.COPYLIBa 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=x //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
Re: procs and concatenations
Nice idea. Though it doesn't address: 1) Wanting to include from someone else's private library as well as or instead of your own. 2) Not wanting to include from anyone's private library (sometimes I have the new copybook in my private library but want a compile to pick up only the production version. Thanks for the thoughts, Frank On Mon, 10 Nov 2008 15:35:26 -0800, Raymond Noal [EMAIL PROTECTED] wrote: Frank, 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 -- 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
Re: procs and concatenations
That seems like it may work. I'm heading home now, but I will try it on Wednesday (holiday tomorrow!). Probably I would have an empty library as the first one, so I could always include it but not have to have the main production library as the first concatentation. Thanks for the idea!! Frank On Mon, 10 Nov 2008 20:14:15 -0500, Lizette Koehler [EMAIL PROTECTED] wrote: 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=x // INCLUDE MEMBER=DEVEL1 Developers Copylib Dataset // INCLUDE MEMBER=APPL1Specific 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.COPYLIBa 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=x //SYSLIB DD DISP=SHR,DSN=DEVELP.COPYLIB //* //DD DISP=SHR,DSN=SYS1.IGYCOPY1 //DD DISP=SHR,DSN=SYS1.COPYLIB -- 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
Re: procs and concatenations
Try this: //IGYWC PROC LNGPRFX='IGY.V3R3M0',SYSLBLK=3200 //COBOL EXEC PGM=IGYCRCTL,REGION=2048K //STEPLIB DD DSNAME=LNGPRFX..SIGYCOMP, // DISP=SHR //* //SYSLIBDD 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. -- Peter Hunkeler CREDIT SUISSE -- 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
