COBOL Compiler options
Darren, That WOULD sound like a good SHARE requirement if it were true, however I see no indication at: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 to support this claim. (Nor could I find it elsewhere in the current Enterprise COBOL documentation). Can you point me to something supporting this view? I went back thru some of the older bookshelves and couldn't find this restriction ever being true. "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > The integrated translator does not support DLL mode compiles at all as > it completely overrides that option. It forces certain compile options > to be set that can interfere with using some of Cobol's advanced > features. It still has a ways to go. > > Darren > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Paul D'Angelo > Sent: Wednesday, February 20, 2008 10:54 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Fw: COBOL Compiler options > > If you are running the CICS Itegrated translator You should be fine. I > ran > it in a > previous installation and had no problems. > Your Application developers may not like it since it generates different > > source code > that a CICS program compiled with the Translator. > It was my application staff that couldnt adjust to the Intergrated > translator. > > > > > Bill Klein <[EMAIL PROTECTED]> > Sent by: IBM Mainframe Discussion List > 02/20/2008 01:47 PM > Please respond to > IBM Mainframe Discussion List > > > To > IBM-MAIN@BAMA.UA.EDU > cc > > Subject > Fw: COBOL Compiler options > > > > > > > Using the coprocessor is NOT exactly the same as running the > preprocessor > and then the compiler. As far as I know, there have been NO reports of > "different run-time" results from the two, but there are things that > using > the coprocessor can do that the preprocessor can't (see the Programming > Guide for details) e.g. > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG40/3.1.2.2 > > > I would, however, check you LISTINGS to make certain that all the > "Options > in Effect" are the same with the two methods. It is possible that one > of > your compiler procs has different settings and this COULD impact > run-time > results. > > <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]> > ... > > In our shop, for CICS COBOL programs, we run the preprocessor > > DFHECP1$, then > > the compile step IGYCRCTL. > > I thought of bypassing the DFHECP1$ step by running the IGYCRCTL with > > 'CICS' in > > the parm. > > > > That was fine. > > > > Except, a co-worker pointed out to me that the generated object code > > differs, > > and, as such, is apprehensive. > > > > Does anyone know why that is? > > > > > > Thanks -- 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
COBOL Compiler options
Turns out that there is actually a restriction (currently undocumented). The following is what I got back from my "usually reliable source". Note however, that this is a case (as I suspected) that using EITHER the preprocessor or the coprocessor will fail: "Bill, Looks like uncharted territory...we certainly cannot support compiling a CICS program with the DLL option, just like we can't with DYNAM, for the same reason: it changes the calls to CICS. (By the way, this is not just coprocessor, it is separate translator as well) However, we do not document this DLL problem nor have compiler options conflicts. However, you CAN call a DLL from a CICS program, using the example in the COBOL PG Chapter 26: Example: calling DLLs from non-DLLs Will look into what we should do about this...I have a feeling the user is actually trying to use DYNAM with coprocessor. DYNAM is also not supported in CICS separate or coprocessor, we just can't catch it in the separate translator case, while we do diagnose it in integrated coprocessor case." (FYI, that last statement about "not catching" is probably the case for DLL as well. You can get a "clean compile" with NOCICS,DLL if you compile a preprocessed source code. However, run-time results are unsupported - because it will try and make the CALLs to "FD" DLL rather than "standard" calls. "Bill Klein" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > John, > I can't find anything at that page that restricts the use of DLL's with > the integrated translator. > > FYI, > *both* the COBOL "CICS" and "DLL" compiler options require the NODYNAM > compiler option, so that can't be it. > > Can you point me to the text on that page (or anywhere) that restricts the > use of DLL's with the integrated translator (for cases where it is valid if > you pre-translate the code)? > > Sorry to be "obtuse" - but I just don't see this restriction in either the > CICS or COBOL documentation. > > "Chase, John" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>.. > . > > > -Original Message- > > > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > > > > > Darren, > > > That WOULD sound like a good SHARE requirement if it were > > > true, however I see no indication at: > > > > > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 > > > > > > to support this claim. (Nor could I find it elsewhere in the > > > current Enterprise COBOL documentation). Can you point me to > > > something supporting this view? I went back thru some of the > > > older bookshelves and couldn't find this restriction ever being true. > > > > > > "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in > > > message > > > news:<[EMAIL PROTECTED] > > > te.or.us>... > > > > The integrated translator does not support DLL mode > > > compiles at all as > > > > it completely overrides that option. It forces certain compile > > > > options to be set that can interfere with using some of Cobol's > > > > advanced features. It still has a ways to go. > > > > > > > > Darren > > > > Perhaps this will clarify (from the CICS TS 3.2 CICS Application > > Programming Guide): > > > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/2.1.1.1 > > > > Note that the COBOL option NODYNAM "must be in effect" for use of the > > Integrated Translator. Perhaps that's one of the "overrides" that is > > repugnant to "DLL mode compiles"? > > -- > 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
Fw: COBOL Compiler options
Using the coprocessor is NOT exactly the same as running the preprocessor and then the compiler. As far as I know, there have been NO reports of "different run-time" results from the two, but there are things that using the coprocessor can do that the preprocessor can't (see the Programming Guide for details) e.g. http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG40/3.1.2.2 I would, however, check you LISTINGS to make certain that all the "Options in Effect" are the same with the two methods. It is possible that one of your compiler procs has different settings and this COULD impact run-time results. <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > In our shop, for CICS COBOL programs, we run the preprocessor > DFHECP1$, then > the compile step IGYCRCTL. > I thought of bypassing the DFHECP1$ step by running the IGYCRCTL with > 'CICS' in > the parm. > > That was fine. > > Except, a co-worker pointed out to me that the generated object code > differs, > and, as such, is apprehensive. > > Does anyone know why that is? > > > Thanks -- 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
Fw: COBOL Compiler options
John, I can't find anything at that page that restricts the use of DLL's with the integrated translator. FYI, *both* the COBOL "CICS" and "DLL" compiler options require the NODYNAM compiler option, so that can't be it. Can you point me to the text on that page (or anywhere) that restricts the use of DLL's with the integrated translator (for cases where it is valid if you pre-translate the code)? Sorry to be "obtuse" - but I just don't see this restriction in either the CICS or COBOL documentation. "Chase, John" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>.. . > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > > > Darren, > > That WOULD sound like a good SHARE requirement if it were > > true, however I see no indication at: > > > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 > > > > to support this claim. (Nor could I find it elsewhere in the > > current Enterprise COBOL documentation). Can you point me to > > something supporting this view? I went back thru some of the > > older bookshelves and couldn't find this restriction ever being true. > > > > "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in > > message > > news:<[EMAIL PROTECTED] > > te.or.us>... > > > The integrated translator does not support DLL mode > > compiles at all as > > > it completely overrides that option. It forces certain compile > > > options to be set that can interfere with using some of Cobol's > > > advanced features. It still has a ways to go. > > > > > > Darren > > Perhaps this will clarify (from the CICS TS 3.2 CICS Application > Programming Guide): > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/2.1.1.1 > > Note that the COBOL option NODYNAM "must be in effect" for use of the > Integrated Translator. Perhaps that's one of the "overrides" that is > repugnant to "DLL mode compiles"? -- 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: COBOL Compiler options
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > Darren, > That WOULD sound like a good SHARE requirement if it were > true, however I see no indication at: > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 > > to support this claim. (Nor could I find it elsewhere in the > current Enterprise COBOL documentation). Can you point me to > something supporting this view? I went back thru some of the > older bookshelves and couldn't find this restriction ever being true. > > "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in > message > news:<[EMAIL PROTECTED] > te.or.us>... > > The integrated translator does not support DLL mode > compiles at all as > > it completely overrides that option. It forces certain compile > > options to be set that can interfere with using some of Cobol's > > advanced features. It still has a ways to go. > > > > Darren Perhaps this will clarify (from the CICS TS 3.2 CICS Application Programming Guide): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/2.1. 1.1 Note that the COBOL option NODYNAM "must be in effect" for use of the Integrated Translator. Perhaps that's one of the "overrides" that is repugnant to "DLL mode compiles"? -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: COBOL Compiler options
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of GAVIN Darren * OPS EAS > > Here is how we build our DLL Modules > > Compile > > PROCESS TRUNC(BIN) DLL EXPORTALL PGMNAME(LONGMIXED) > > On the link > > DYNAM(DLL),RENT,CASE(MIXED) > > If you specify DYNAM(DLL) on the process statement instead of > on the linkage parms, like one should be able to do, the > integrated translator will error off. That's a "CICS problem", not a "COBOL problem". You might consider raising a Requirement with CICS Development to address it. -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: COBOL Compiler options
Here is how we build our DLL Modules Compile PROCESS TRUNC(BIN) DLL EXPORTALL PGMNAME(LONGMIXED) On the link DYNAM(DLL),RENT,CASE(MIXED) If you specify DYNAM(DLL) on the process statement instead of on the linkage parms, like one should be able to do, the integrated translator will error off. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Thursday, February 21, 2008 9:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Fw: COBOL Compiler options John, I can't find anything at that page that restricts the use of DLL's with the integrated translator. FYI, *both* the COBOL "CICS" and "DLL" compiler options require the NODYNAM compiler option, so that can't be it. Can you point me to the text on that page (or anywhere) that restricts the use of DLL's with the integrated translator (for cases where it is valid if you pre-translate the code)? Sorry to be "obtuse" - but I just don't see this restriction in either the CICS or COBOL documentation. "Chase, John" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED] m>.. . > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > > > Darren, > > That WOULD sound like a good SHARE requirement if it were > > true, however I see no indication at: > > > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 > > > > to support this claim. (Nor could I find it elsewhere in the > > current Enterprise COBOL documentation). Can you point me to > > something supporting this view? I went back thru some of the > > older bookshelves and couldn't find this restriction ever being true. > > > > "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in > > message > > news:<[EMAIL PROTECTED] > > te.or.us>... > > > The integrated translator does not support DLL mode > > compiles at all as > > > it completely overrides that option. It forces certain compile > > > options to be set that can interfere with using some of Cobol's > > > advanced features. It still has a ways to go. > > > > > > Darren > > Perhaps this will clarify (from the CICS TS 3.2 CICS Application > Programming Guide): > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/2.1. 1.1 > > Note that the COBOL option NODYNAM "must be in effect" for use of the > Integrated Translator. Perhaps that's one of the "overrides" that is > repugnant to "DLL mode compiles"? -- 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: COBOL Compiler options
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > John, > I can't find anything at that page that restricts the use > of DLL's with the integrated translator. > > FYI, > *both* the COBOL "CICS" and "DLL" compiler options require > the NODYNAM compiler option, so that can't be it. > > Can you point me to the text on that page (or anywhere) that > restricts the use of DLL's with the integrated translator > (for cases where it is valid if you pre-translate the code)? > > Sorry to be "obtuse" - but I just don't see this restriction > in either the CICS or COBOL documentation. I don't find any explicit declaration that using the Integrated Translator is "incompatible" with "DLL mode compiles", either. I've not tried any "DLL mode compiles", with or without EXEC CICS commands in the source, so I can't offer any empirical evidence one way or the other. The CICS doc doesn't mention anything about the Integrated Translator itself "forcing" any COBOL compile-time options; only that certain options "must be in effect" to use it. Perhaps the OP would provide an example? -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: COBOL Compiler options
GAVIN Darren * OPS EAS wrote: Here is how we build our DLL Modules Compile PROCESS TRUNC(BIN) DLL EXPORTALL PGMNAME(LONGMIXED) On the link DYNAM(DLL),RENT,CASE(MIXED) If you specify DYNAM(DLL) on the process statement instead of on the linkage parms, like one should be able to do, the integrated translator will error off. Darren Yeah, but, there is no DYNAM(DLL) for COBOL process statements. There is DYNAM, NODYNAM, DLL and NODLL. Valid combinations of these: NODYNAM, DLL DYNAM, NODLL since DLL forces NODYNAM. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: COBOL Compiler options
Well I do have DLL programs using the Linkage parm I mentioned before working with the Preprocessor and EXEC DLI database calls. Have had no Issues doing this. So as long as the CICS Loadlib is a PDSE, I think a DLL module should work in CICS; just like a CALL variable-name USING (where the variable has a program name) works for forcing dynamic calls in CICS. Note that I said I think..., I've been pulled off mainframe projects for a bit so I can't test this out myself, otherwise I would try it and report back. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Thursday, February 21, 2008 1:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL Compiler options Turns out that there is actually a restriction (currently undocumented). The following is what I got back from my "usually reliable source". Note however, that this is a case (as I suspected) that using EITHER the preprocessor or the coprocessor will fail: "Bill, Looks like uncharted territory...we certainly cannot support compiling a CICS program with the DLL option, just like we can't with DYNAM, for the same reason: it changes the calls to CICS. (By the way, this is not just coprocessor, it is separate translator as well) However, we do not document this DLL problem nor have compiler options conflicts. However, you CAN call a DLL from a CICS program, using the example in the COBOL PG Chapter 26: Example: calling DLLs from non-DLLs Will look into what we should do about this...I have a feeling the user is actually trying to use DYNAM with coprocessor. DYNAM is also not supported in CICS separate or coprocessor, we just can't catch it in the separate translator case, while we do diagnose it in integrated coprocessor case." (FYI, that last statement about "not catching" is probably the case for DLL as well. You can get a "clean compile" with NOCICS,DLL if you compile a preprocessed source code. However, run-time results are unsupported - because it will try and make the CALLs to "FD" DLL rather than "standard" calls. "Bill Klein" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > John, > I can't find anything at that page that restricts the use of DLL's with > the integrated translator. > > FYI, > *both* the COBOL "CICS" and "DLL" compiler options require the NODYNAM > compiler option, so that can't be it. > > Can you point me to the text on that page (or anywhere) that restricts the > use of DLL's with the integrated translator (for cases where it is valid if > you pre-translate the code)? > > Sorry to be "obtuse" - but I just don't see this restriction in either the > CICS or COBOL documentation. > > "Chase, John" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED] m>.. > . > > > -Original Message- > > > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > > > > > Darren, > > > That WOULD sound like a good SHARE requirement if it were > > > true, however I see no indication at: > > > > > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 > > > > > > to support this claim. (Nor could I find it elsewhere in the > > > current Enterprise COBOL documentation). Can you point me to > > > something supporting this view? I went back thru some of the > > > older bookshelves and couldn't find this restriction ever being true. > > > > > > "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in > > > message > > > news:<[EMAIL PROTECTED] > > > te.or.us>... > > > > The integrated translator does not support DLL mode > > > compiles at all as > > > > it completely overrides that option. It forces certain compile > > > > options to be set that can interfere with using some of Cobol's > > > > advanced features. It still has a ways to go. > > > > > > > > Darren > > > > Perhaps this will clarify (from the CICS TS 3.2 CICS Application > > Programming Guide): > > > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/2.1. 1.1 > > > > Note that the COBOL option NODYNAM "must be in effect" for use of the > > Integrated Translator. Perhaps that's one of the "overrides" that is > > repugnant to "DLL mode compiles"? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send e
Fw: COBOL Compiler options
I know that you can't check it now, but are you saying that using the separate translator step, that you can compile a COBOL program with the following compiler options: NOCICS,NODLL,NODYNAM but use the binder option DYNAM(DLL) If so, then you probably can do that also with the integrated coprocessor (but I won't swear to it). If, however, you are saying that you can use the separate translator step and use the COBOL compiler options NOCICS,DLL,NODYNAM and this works "as expected" ar tun-time, then that is something that I (and suspect IBM) would be very interested in (when you have a chance to check it out). "GAVIN Darren * OPS EAS" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Well I do have DLL programs using the Linkage parm I mentioned before > working with the Preprocessor and EXEC DLI database calls. Have had no > Issues doing this. > > So as long as the CICS Loadlib is a PDSE, I think a DLL module should > work in CICS; just like a CALL variable-name USING (where the variable > has a program name) works for forcing dynamic calls in CICS. > > Note that I said I think..., I've been pulled off mainframe projects for > a bit so I can't test this out myself, otherwise I would try it and > report back. > > Darren > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Klein > Sent: Thursday, February 21, 2008 1:01 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: COBOL Compiler options > > Turns out that there is actually a restriction (currently undocumented). > The following is what I got back from my "usually reliable source". > Note > however, that this is a case (as I suspected) that using EITHER the > preprocessor or the coprocessor will fail: > > "Bill, > > Looks like uncharted territory...we certainly cannot support compiling a > CICS program > with the DLL option, just like we can't with DYNAM, for the same reason: > it > changes the > calls to CICS. (By the way, this is not just coprocessor, it is separate > translator as well) > > However, we do not document this DLL problem nor have compiler options > conflicts. > > However, you CAN call a DLL from a CICS program, using the example in > the > COBOL PG Chapter 26: Example: calling DLLs from non-DLLs > > Will look into what we should do about this...I have a feeling the user > is > actually trying to use > DYNAM with coprocessor. DYNAM is also not supported in CICS separate or > coprocessor, > we just can't catch it in the separate translator case, while we do > diagnose > it in integrated > coprocessor case." > > (FYI, that last statement about "not catching" is probably the case for > DLL > as well. You can get a "clean compile" with > NOCICS,DLL > if you compile a preprocessed source code. However, run-time results are > unsupported - because it will try and make the CALLs to "FD" DLL > rather > than "standard" calls. > > "Bill Klein" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>... > > John, > > I can't find anything at that page that restricts the use of DLL's > with > > the integrated translator. > > > > FYI, > > *both* the COBOL "CICS" and "DLL" compiler options require the > NODYNAM > > compiler option, so that can't be it. > > > > Can you point me to the text on that page (or anywhere) that restricts > the > > use of DLL's with the integrated translator (for cases where it is > valid > if > > you pre-translate the code)? > > > > Sorry to be "obtuse" - but I just don't see this restriction in either > the > > CICS or COBOL documentation. > > > > "Chase, John" <[EMAIL PROTECTED]> wrote in message > > > news:<[EMAIL PROTECTED] > m>.. > > . > > > > -Original Message- > > > > From: IBM Mainframe Discussion List On Behalf Of Bill Klein > > > > > > > > Darren, > > > > That WOULD sound like a good SHARE requirement if it were > > > > true, however I see no indication at: > > > > > > > > > http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg40/2.4.2 > > > > > > > > to support this claim. (Nor could I find it elsewhere in the > > > > current Enterprise COBOL documentation). Can you point me to > > > > something supporting this view? I went back thru some of the > > > > older bo
Re: COBOL Compiler options
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of GAVIN Darren * OPS EAS > > Well I do have DLL programs using the Linkage parm I > mentioned before working with the Preprocessor and EXEC DLI > database calls. Have had no Issues doing this. > > So as long as the CICS Loadlib is a PDSE, I think a DLL > module should work in CICS; just like a CALL variable-name > USING (where the variable has a program name) works for > forcing dynamic calls in CICS. > > Note that I said I think..., I've been pulled off mainframe > projects for a bit so I can't test this out myself, otherwise > I would try it and report back. My reading of the "undocumented restriction" is only that the DLL itself cannot contain any EXEC CICS calls. I agree that calling a DLL from a CICS program should be equivalent to dynamically calling another program. Remember, though, that I've already "said" more than I know about DLLs.. -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: COBOL Compiler options
Bill, The Compile options I used with separate translator and EXEC DLI are: TRUNC(BIN) DLL EXPORTALL PGMNAME(LONGMIXED) And on Binder options DYNAM(DLL),RENT,CASE(MIXED) I'm going to ask my supervisor if he would like me to attempt DLL's in CICS, as it sounds like you and IBM might be interested in results of it. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Thursday, February 21, 2008 5:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Fw: COBOL Compiler options I know that you can't check it now, but are you saying that using the separate translator step, that you can compile a COBOL program with the following compiler options: NOCICS,NODLL,NODYNAM but use the binder option DYNAM(DLL) If so, then you probably can do that also with the integrated coprocessor (but I won't swear to it). If, however, you are saying that you can use the separate translator step and use the COBOL compiler options NOCICS,DLL,NODYNAM and this works "as expected" ar tun-time, then that is something that I (and suspect IBM) would be very interested in (when you have a chance to check it out). -- 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: COBOL Compiler options
On Mon, 17 Mar 2008 08:17:44 -0700 (PDT), in bit.listserv.ibm-main you wrote: >This option OPT(FULL), in the COBOL migration guide states that >unreference >data fields will be removed from the object. > >So, if I have a '05' level thingy, will it be removed? The related "01" level and all fields subordinate to it also have to be unreferenced for the space reservation to be removed from the Working Storage. Note that if the program is compiled OPTION(RENT) which is the normal option, the size of the GETMAIN for Working Storage is reduced for all removed record (01) areas. > >What are the considerations? > > >Thanks Clark Morris -- 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: Fw: COBOL Compiler options
If you are running the CICS Itegrated translator You should be fine. I ran
it in a
previous installation and had no problems.
Your Application developers may not like it since it generates different
source code
that a CICS program compiled with the Translator.
It was my application staff that couldnt adjust to the Intergrated
translator.
Bill Klein <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List
02/20/2008 01:47 PM
Please respond to
IBM Mainframe Discussion List
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Fw: COBOL Compiler options
Using the coprocessor is NOT exactly the same as running the preprocessor
and then the compiler. As far as I know, there have been NO reports of
"different run-time" results from the two, but there are things that using
the coprocessor can do that the preprocessor can't (see the Programming
Guide for details) e.g.
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG40/3.1.2.2
I would, however, check you LISTINGS to make certain that all the "Options
in Effect" are the same with the two methods. It is possible that one of
your compiler procs has different settings and this COULD impact run-time
results.
<[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> In our shop, for CICS COBOL programs, we run the preprocessor
> DFHECP1$, then
> the compile step IGYCRCTL.
> I thought of bypassing the DFHECP1$ step by running the IGYCRCTL with
> 'CICS' in
> the parm.
>
> That was fine.
>
> Except, a co-worker pointed out to me that the generated object code
> differs,
> and, as such, is apprehensive.
>
> Does anyone know why that is?
>
>
> Thanks
--
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
*** IMPORTANT
NOTE* The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
--
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: Fw: COBOL Compiler options
The integrated translator does not support DLL mode compiles at all as
it completely overrides that option. It forces certain compile options
to be set that can interfere with using some of Cobol's advanced
features. It still has a ways to go.
Darren
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul D'Angelo
Sent: Wednesday, February 20, 2008 10:54 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Fw: COBOL Compiler options
If you are running the CICS Itegrated translator You should be fine. I
ran
it in a
previous installation and had no problems.
Your Application developers may not like it since it generates different
source code
that a CICS program compiled with the Translator.
It was my application staff that couldnt adjust to the Intergrated
translator.
Bill Klein <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List
02/20/2008 01:47 PM
Please respond to
IBM Mainframe Discussion List
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Fw: COBOL Compiler options
Using the coprocessor is NOT exactly the same as running the
preprocessor
and then the compiler. As far as I know, there have been NO reports of
"different run-time" results from the two, but there are things that
using
the coprocessor can do that the preprocessor can't (see the Programming
Guide for details) e.g.
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG40/3.1.2.2
I would, however, check you LISTINGS to make certain that all the
"Options
in Effect" are the same with the two methods. It is possible that one
of
your compiler procs has different settings and this COULD impact
run-time
results.
<[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>
...
> In our shop, for CICS COBOL programs, we run the preprocessor
> DFHECP1$, then
> the compile step IGYCRCTL.
> I thought of bypassing the DFHECP1$ step by running the IGYCRCTL with
> 'CICS' in
> the parm.
>
> That was fine.
>
> Except, a co-worker pointed out to me that the generated object code
> differs,
> and, as such, is apprehensive.
>
> Does anyone know why that is?
>
>
> Thanks
--
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
*** IMPORTANT
NOTE* The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.
--
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
COBOL compiler options JCL PARM.
Hi All, Enterprise COBOL compiler v3.4. Am pretty sure someone else must have hit this. I have hit the 100 char (I think ?) limit for the opts passed to the compiler via the Parm setting in the JCL. For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' in the JCL and then putting the compiler opts in the dd named OPTIONS. Is there a way for doing this with the Enterprise COBOL Compiler ? ... I have been looking through the manuals, and have not found anything ? Many thanks in advance for any help, Peter -- 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
COBOL compiler options JCL PARM.
To the best of my knowledge, no current or (relatively recently past, i.e. OS/VS COBOL or later) compiler has created object code that "truncates" passed parameters to called subprograms. It *IS* true that the compiler itself may (as documented) only pay attention to the first 100 bytes of passed data, but that has nothing to do with object code created by it. NOTE: From VS COBOL II thru IBM COBOL for OS/390 & VM, the compiler was "single-sourced". Therefore, as the 100-byte limit is a JCL, not a VM or CMS restriction, this would surprise me BUT it may be that only 100 bytes for the compiler was the documented restriction. "Charles Mills" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > No, I don't mean that. I mean that if a calling program passes more than 100 > characters, the compiler ignores those in excess of 100. That's what the > manual says, and that's how some of the IBM COBOL compilers behave. > > My statement is not based on projecting the JCL limitation onto the > compiler. > > The quoted passage is from the part of the PG that deals specifically with > calling the compiler from an assembler program. > > My point was specifically intended to cast a shadow on Gil's > logically-reasonable suggestion that the OP write a Rexx program to defeat > the JCL limitation. > > WHY would the COBOL compiler behave this way? Perhaps to assure consistent > results whether loaded as a jobstep program or from a calling program. (I > disagree with the design decision.) > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] > Of Chris Mason > Sent: Tuesday, December 12, 2006 10:32 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: COBOL compiler options JCL PARM. > > Charles > > Reading the posts in this thread I sometimes get the impression that this > 100 character limit is being regarded as a convention rather than an > absolute limit. Maybe it's because the "PG", by which I expect you mean the > COBOL "Programmer's Guide", and other product manuals tend to give this > impression. > > I expect you know but some reading the thread may not. > > The reason "The compiler recognizes only the first 100 characters in the > list." is that this is the way the PARM operand works. See section 16.8.1, > "Syntax" under section 16.8, "PARM Parameter" in z/OS V1R7.0-V1R8.0 MVS JCL > Reference where you will find the following: -- 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
COBOL compiler options JCL PARM.
""Jan MOEYERSONS"" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > >I actually look after the change management software and am trying to > > > As an ex-change management person, I have to recommend you do not do that > and indeed that you prohibit your programmers from using the CBL > statements. (Even add a filter to the compile procedure to kick the CBL > statements out!) You, as the change manager, want to be in exclusive > control of the compile options. > For shops that want to disallow CBL cards, there is the ALLOWCBL installation option (and has been for many years). There is even a CICS option to make certain that CICS doesn't insert any. ON THE OTHER HAND, I am not a "fan" of this as CBL cards are often a GOOD way to "document" compiler options that are required for a program - but different from site defaults. -- 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: COBOL compiler options JCL PARM.
The only way I know of to pass a parm greater than 100 chars to COBOL is to do it through a DD statement that is coded in the Program. I do not remember that COBOL (any version) as having the same function as PL/I or C++ with the DD Name Option. If you are trying to pass in the LE options, then if you are at z/OS V1.7 or higher, there is a new DD statement for them. But for general parms - none that I know. Lizette -- 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: COBOL compiler options JCL PARM.
Nuttall, Peter [CCC-OT_IT] wrote: > Hi All, > > Enterprise COBOL compiler v3.4. > > Am pretty sure someone else must have hit this. I have hit the > 100 char (I think ?) limit for the opts passed to the compiler > via the Parm setting in the JCL. > > For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' > in the JCL and then putting the compiler opts in the dd named OPTIONS. Is > there a way for doing this with the Enterprise COBOL Compiler ? ... I have > been looking through the manuals, and have not found anything ? > > Many thanks in advance for any help, > Peter If it has to be JCL, I think you're out of luck. But here's some options: 1. Consider PROCESS statements embedded in your source code; you can specify most compiler options in these statements, placed at the very start of the source program 2. Make sure your compiler is installed with the values you need most often: you only need to specify parms to override defaults; if the defaults are what you want, you don't need to specify parms 3. If the reason (or one reason) for running out of PARM space is because LE options are taking up room, many of them may be specified in JCL, if you are running a recent enough version of z/OS (I think 1.5, but it might have been 1.6 where LE parms could be specified by DD statement) Hope this helps. Kind regards, -Steve Comstock The Trainer's Friend, Inc. -- 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: COBOL compiler options JCL PARM.
Hi Peter, In respect of: "Enterprise COBOL compiler v3.4. Am pretty sure someone else must have hit this. I have hit the 100 char (I think ?) limit for the opts passed to the compiler via the Parm setting in the JCL. For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' in the JCL and then putting the compiler opts in the dd named OPTIONS. Is there a way for doing this with the Enterprise COBOL Compiler ? ... I have been looking through the manuals, and have not found anything ?" Can you not use the CONTROL or CBL statement ahead of the IDENTIFICATION DIVISION as discussed in the Programmig Guide. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore Sheffield S17 3LA UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk www.kmsitltd.co.uk Reg: England & Wales 3767263 at the above address All outgoing E-mails are scanned but it remains the recipients responsibility to ensure that their system is protected from viruses, trojans, worms, and spy-ware. -- 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: COBOL compiler options JCL PARM.
-- Hi All, Enterprise COBOL compiler v3.4. Am pretty sure someone else must have hit this. I have hit the 100 char (I think ?) limit for the opts passed to the compiler via the Parm setting in the JCL. For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' in the JCL and then putting the compiler opts in the dd named OPTIONS. Is there a way for doing this with the Enterprise COBOL Compiler ? ... I have been looking through the manuals, and have not found anything ? Many thanks in advance for any help, Peter --- Why not adjust the defaults module, using the same methods as used when you installed the compiler? Or having a separate defaults module you can STEPLIB to, with your chosen values set? -- 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
Fw: COBOL compiler options JCL PARM.
There have been previous requests for COBOL to have the same type of DD that PL/I has had for years (and that LE has recently introduced) to avoid this. However, there certainly is none right now. Steve has given a couple of answers, and using a CBL (Process) card (that you can concatenate with your source code) is one way. HOWEVER, I would suggest that you also look at the programming guide for what the "smallest" abbreviation is for each compiler option. I have rarely seen sites use the minimum for each option. If you need to find them, check out: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG31/CCONTENT S "Nuttall, Peter [CCC-OT_IT]" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Hi All, > > Enterprise COBOL compiler v3.4. > > Am pretty sure someone else must have hit this. I have hit the 100 char (I think ?) limit for the opts passed to the compiler via the Parm setting in the JCL. > > For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' in the JCL and then putting the compiler opts in the dd named OPTIONS. Is there a way for doing this with the Enterprise COBOL Compiler ? ... I have been looking through the manuals, and have not found anything ? > > Many thanks in advance for any help, > Peter -- 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: COBOL compiler options JCL PARM.
Thanks to everyone who responded. I actually look after the change management software and am trying to amend the JCL skeleton for the compiler options. I do find it strange that this has not been amended, especially with regards to extra options for the DB2 and CICS coprocessors. Ahh well, I will make sure all the opts are abbreviated and recommend to our programmers that they use the CBL statement in their source for any extra options they might want to add. Thanks again and kind regards, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Rick Fochtman Sent: 12 December 2006 14:33 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. -- >Hi All, > >Enterprise COBOL compiler v3.4. > >Am pretty sure someone else must have hit this. I have hit the 100 char (I >think ?) limit for the opts passed to the compiler via the Parm setting in the >JCL. > >For the Enterprise PL1 compiler I solved this by setting PARM='+DD:OPTIONS' in >the JCL and then putting the compiler opts in the dd named OPTIONS. Is there a >way for doing this with the Enterprise COBOL Compiler ? ... I have been >looking through the manuals, and have not found anything ? > >Many thanks in advance for any help, >Peter > > --- Why not adjust the defaults module, using the same methods as used when you installed the compiler? Or having a separate defaults module you can STEPLIB to, with your chosen values set? -- 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: COBOL compiler options JCL PARM.
In a recent note, Bill Klein said: > Date: Tue, 12 Dec 2006 09:07:51 -0600 > > There have been previous requests for COBOL to have the same type of DD that > PL/I has had for years (and that LE has recently introduced) to avoid this. > However, there certainly is none right now. > There was a flurry of excitement (but not unanimous support) in this list many months ago when an IBM employee hinted that a relaxation of the 100-character limit might be possible. Is this still under consideration? can we get a status update? Certainly a relaxation of the JCL limit is a better use of resources than each product's supplying its peculiar alternative. And, to my knowledge, none of the alternatives provides for symbol substitution which is so valuable in the JCL PARM. YA alternative is a Rexx wrapper which can provide a PARM of up to 32KiBytes, but no convenient symbol substitution. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: COBOL compiler options JCL PARM.
Paul Gilmartin wrote: In a recent note, Bill Klein said: Date: Tue, 12 Dec 2006 09:07:51 -0600 There have been previous requests for COBOL to have the same type of DD that PL/I has had for years (and that LE has recently introduced) to avoid this. However, there certainly is none right now. There was a flurry of excitement (but not unanimous support) in this list many months ago when an IBM employee hinted that a relaxation of the 100-character limit might be possible. Is this still under consideration? can we get a status update? Certainly a relaxation of the JCL limit is a better use of resources than each product's supplying its peculiar alternative. And, to my knowledge, none of the alternatives provides for symbol substitution which is so valuable in the JCL PARM. YA alternative is a Rexx wrapper which can provide a PARM of up to 32KiBytes, but no convenient symbol substitution. In a recent post I pointed out the availability of a new LE service: * CEE3PR2 callable service - returns up to 32K bytes of program parms; not sure how to specify those parms yet, but this seems to lay the groundwork for the future Perhaps the other shoe will drop soon. Kind regards, -Steve Comstock -- 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: COBOL compiler options JCL PARM.
Now all you have to worry about is them including options that you DON'T want in production -Original Message- Nuttall, Peter ... recommend to our programmers that they use the CBL statement in their source for any extra options they might want to add. -- 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: COBOL compiler options JCL PARM.
Yes, on second thoughts, maybe I won't recommend that !! ... If they get desperate we may look for other ways (ie changing the compiler defaults !!) Kind Regards, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ken Porowski Sent: 12 December 2006 16:38 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Now all you have to worry about is them including options that you DON'T want in production -Original Message- Nuttall, Peter ... recommend to our programmers that they use the CBL statement in their source for any extra options they might want to add. -- 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: COBOL compiler options JCL PARM.
Having been down this path before in a galaxy far, far away: Because you can have multiple CBL cards at the beginning, have a PDS (SAF.PROT.CBL.DATA) whose members consist of single control cards - for example XREFY = CBL XREF XREFN = CBL NOXREF LISTY = CBL LIST LISTN = CBL NOLIST (of course, this is not an exhaustive list) Then have a proc: //DOMYCOMP PROC XREF=Y,LIST=N,PROG=XYZ ... //C EXEC PGM=IGYCBL00,... //SYSIN DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(XREF&XREF) // DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(LIST&LIST) //* THE FOLLOWING CONTAINS CBL PARMS THAT WE NEVER, EVER, EVER //* WANT THE PROGRAMMERS TO OVERRIDE, E.G., NOSSRANGE // DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(ALWAYS) // DD DISP=SHR,DSN=OUR.BIG.OLD.SOURCE.COBOL(&PROG) ... You give the programmers the opportunity to override selected parms, and since CBL statement processing always takes the last specification of a keyword, the ALWAYS member contains those you want to enforce. And SAF is your friend preventing those pesky application programmers from creating their own custom members. Would this help in your situation? Best regards, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Nuttall, Peter [CCC-OT_IT] Sent: Tuesday December 12 2006 09:10 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Yes, on second thoughts, maybe I won't recommend that !! ... If they get desperate we may look for other ways (ie changing the compiler defaults !!) Kind Regards, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ken Porowski Sent: 12 December 2006 16:38 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Now all you have to worry about is them including options that you DON'T want in production -Original Message- Nuttall, Peter ... recommend to our programmers that they use the CBL statement in their source for any extra options they might want to add. -- 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: COBOL compiler options JCL PARM.
> YA alternative is a Rexx wrapper which can provide a PARM of up to > 32KiBytes Maybe, probably not. From the PG "The compiler recognizes only the first 100 characters in the list." In my experience wrestling with this very issue, some of the various compilers (I mean various compilers, not various versions of EC -- OS/VS COBOL 5740-CB1 comes to mind) do in fact recognize more than 100 bytes of parameters, and some do not. I don't remember which category EC fell into. In any event, it's no sure thing, going against the published docs. I agree with Gil's other point 100% -- better a general solution than a thousand particular solutions. We beat this issue to death a few months ago -- it became apparent that relaxing the limit could be done in a way that had few negative repercussions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Tuesday, December 12, 2006 7:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Certainly a relaxation of the JCL limit is a better use of resources than each product's supplying its peculiar alternative. And, to my knowledge, none of the alternatives provides for symbol substitution which is so valuable in the JCL PARM. YA alternative is a Rexx wrapper which can provide a PARM of up to 32KiBytes, but no convenient symbol substitution. -- 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: COBOL compiler options JCL PARM.
In a message dated 12/12/2006 11:20:11 A.M. Central Standard Time, [EMAIL PROTECTED] writes: keyword, the ALWAYS member contains those you want to enforce. And SAF is your friend preventing those pesky application programmers from creating their own custom members. >> What keeps them from overriding the PROC? -- 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: COBOL compiler options JCL PARM.
On 12 Dec 2006 12:45:17 -0800, [EMAIL PROTECTED] wrote: >What keeps them from overriding the PROC? When I compile my programs for testing, I override the proc to / PARM.SGPF#2=(TEST,XREF,MAP,OUTDD(SYSOUX),DYNAM, / SSRANGE,RENT,BUFSIZE(2)), I recently persuaded people to add SSRANGE in the production proc - but haven't yet persuaded them to include this in the Endevor compile. There are some compile options I can put in the source code - which don't implemented when Endevor migrates them to production. -- 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: COBOL compiler options JCL PARM.
Charles Reading the posts in this thread I sometimes get the impression that this 100 character limit is being regarded as a convention rather than an absolute limit. Maybe it's because the "PG", by which I expect you mean the COBOL "Programmer's Guide", and other product manuals tend to give this impression. I expect you know but some reading the thread may not. The reason "The compiler recognizes only the first 100 characters in the list." is that this is the way the PARM operand works. See section 16.8.1, "Syntax" under section 16.8, "PARM Parameter" in z/OS V1R7.0-V1R8.0 MVS JCL Reference where you will find the following: Length: The length of the subparameters passed must not exceed 100 characters: ° Including any commas, which are passed to the processing program. ° Excluding any enclosing parentheses or apostrophes, which are not passed. Which is a slightly complicated way of saying that, by the time the program - any program - takes a look at the characters supplied by the EXEC statement PARM operand addressed indirectly by register 1[1], there will never be more that 100 of them. This is Paul's "JCL limit". [1] In which manual is this documented these days? Chris Mason - Original Message - From: "Charles Mills" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Tuesday, 12 December, 2006 6:46 PM Subject: Re: COBOL compiler options JCL PARM. > > YA alternative is a Rexx wrapper which can provide a PARM of up to > > 32KiBytes > > Maybe, probably not. From the PG "The compiler recognizes only the first 100 > characters in the list." > > In my experience wrestling with this very issue, some of the various > compilers (I mean various compilers, not various versions of EC -- OS/VS > COBOL 5740-CB1 comes to mind) do in fact recognize more than 100 bytes of > parameters, and some do not. I don't remember which category EC fell into. > In any event, it's no sure thing, going against the published docs. > > I agree with Gil's other point 100% -- better a general solution than a > thousand particular solutions. We beat this issue to death a few months ago > -- it became apparent that relaxing the limit could be done in a way that > had few negative repercussions. > > Charles > > -Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf > Of Paul Gilmartin > Sent: Tuesday, December 12, 2006 7:24 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: COBOL compiler options JCL PARM. > > Certainly a relaxation of the JCL limit is a better use of resources > than each product's supplying its peculiar alternative. And, to my > knowledge, none of the alternatives provides for symbol substitution > which is so valuable in the JCL PARM. > > YA alternative is a Rexx wrapper which can provide a PARM of up to > 32KiBytes, but no convenient symbol substitution. -- 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: COBOL compiler options JCL PARM.
Many thanks Ray, I may look into this as a possible long term solution. For the moment I have removed the options which are default at this site (some differ from the manual because they have been overridden by the sysproggys here) and abbreviated any that are left. Kind Regards, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ray Mullins Sent: 12 December 2006 17:19 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Having been down this path before in a galaxy far, far away: Because you can have multiple CBL cards at the beginning, have a PDS (SAF.PROT.CBL.DATA) whose members consist of single control cards - for example XREFY = CBL XREF XREFN = CBL NOXREF LISTY = CBL LIST LISTN = CBL NOLIST (of course, this is not an exhaustive list) Then have a proc: //DOMYCOMP PROC XREF=Y,LIST=N,PROG=XYZ ... //C EXEC PGM=IGYCBL00,... //SYSIN DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(XREF&XREF) // DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(LIST&LIST) //* THE FOLLOWING CONTAINS CBL PARMS THAT WE NEVER, EVER, EVER //* WANT THE PROGRAMMERS TO OVERRIDE, E.G., NOSSRANGE // DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(ALWAYS) // DD DISP=SHR,DSN=OUR.BIG.OLD.SOURCE.COBOL(&PROG) ... You give the programmers the opportunity to override selected parms, and since CBL statement processing always takes the last specification of a keyword, the ALWAYS member contains those you want to enforce. And SAF is your friend preventing those pesky application programmers from creating their own custom members. Would this help in your situation? Best regards, Ray -- 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: COBOL compiler options JCL PARM.
No, I don't mean that. I mean that if a calling program passes more than 100 characters, the compiler ignores those in excess of 100. That's what the manual says, and that's how some of the IBM COBOL compilers behave. My statement is not based on projecting the JCL limitation onto the compiler. The quoted passage is from the part of the PG that deals specifically with calling the compiler from an assembler program. My point was specifically intended to cast a shadow on Gil's logically-reasonable suggestion that the OP write a Rexx program to defeat the JCL limitation. WHY would the COBOL compiler behave this way? Perhaps to assure consistent results whether loaded as a jobstep program or from a calling program. (I disagree with the design decision.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Tuesday, December 12, 2006 10:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Charles Reading the posts in this thread I sometimes get the impression that this 100 character limit is being regarded as a convention rather than an absolute limit. Maybe it's because the "PG", by which I expect you mean the COBOL "Programmer's Guide", and other product manuals tend to give this impression. I expect you know but some reading the thread may not. The reason "The compiler recognizes only the first 100 characters in the list." is that this is the way the PARM operand works. See section 16.8.1, "Syntax" under section 16.8, "PARM Parameter" in z/OS V1R7.0-V1R8.0 MVS JCL Reference where you will find the following: -- 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: COBOL compiler options JCL PARM.
> [1] In which manual is this documented these days? It's in the Assembler Service Guide, which is where I would expect to find it (i.e., the first place I looked) Chapter 2, which is the first "real" chapter. Interestingly, they do not mention the 100-character limit, even though this section deals specifically with jobstep programs (not linkage in general -- note the references to PARM specifically). Perhaps there IS hope after all: "When your program receives control from the system, register 1 contains the address of a fullword on a fullword boundary in your program's address space (see Figure 2-4). The high-order bit (bit 0) of this word is set to 1. The system uses this convention to indicate the last word in a variable-length parameter list. Bits 1-31 of the fullword contain the address of a two-byte length field on a halfword boundary. The length field contains a binary count of the number of bytes in the PARM field, which immediately follows the length field. If the PARM field was omitted in the EXEC statement, the count is set to zero. To prevent possible errors, always use the count as a length attribute in acquiring the information in the PARM field." BTW, the use of "field" in the above is incorrect and should probably read "parameter" (although "PARM parameter" does sound funny and that may be why the writer avoided it). The JCL reference uses "field" to mean the major "areas" of JCL statements: the parameter field, the comments field, etc. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Tuesday, December 12, 2006 10:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Charles Which is a slightly complicated way of saying that, by the time the program - any program - takes a look at the characters supplied by the EXEC statement PARM operand addressed indirectly by register 1[1], there will never be more that 100 of them. This is Paul's "JCL limit". [1] In which manual is this documented these days? -- 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: COBOL compiler options JCL PARM.
In a recent note, Charles Mills said: > Date: Wed, 13 Dec 2006 06:50:24 -0800 > > WHY would the COBOL compiler behave this way? Perhaps to assure consistent > results whether loaded as a jobstep program or from a calling program. (I > disagree with the design decision.) > I concur with your disagreement. Silent truncation of operands is almost always bad design, particularly when the document says "must" in describing the limitation. (But is the truncation silent, or does the compiler issue an error message?) And there's no concern of consistency -- there's no need to make the behavior of the compiler when called from a program passing PARM>100 characters consistent with its behavior when loaded as a jobstep program with PARM>100 characters, because the latter can never occur. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: COBOL compiler options JCL PARM.
In a message dated 12/13/2006 9:30:37 A.M. Central Standard Time, [EMAIL PROTECTED] writes: And there's no concern of consistency -- there's no need to make the behavior of the compiler when called from a program passing PARM>100 characters consistent with its behavior when loaded as >> For those with short memories and lazy fingers. I put together a short zoomerang survey a few months ago. Published the results here and sent pretty picture to IBM. Never heard back one way or the other. This is .csv format should be able to cut and paste into Excel or Lotus. <---Start .csv --> Management Concerns, ,1,2,3,4,5 ,Strongly agree,Disagree,Neutral,Agree,Strongly Agree 1. We need this feature,0%,6%,21%,33%,40% ,0,4,14,22,27 2. Current programs and systems should continue to run unaltered,1%,0%,3%,15%,81% ,1,0,2,10,54 3. This feature should not open integrity exposure;i.e. buffer overrun,1%,4%,3%,21%,70% ,1,3,2,14,47 4. This option should be customizable by site.,12%,13%,34%,25%,15% ,8,9,23,17,10 5. This option should be OPER setable.,21%,18%,36%,18%,7% ,14,12,24,12,5 6. This should be a SHARE requirement,0%,12%,43%,22%,22% ,0,8,29,15,15 Implementation concerns, ,1,2,3,4,5 ,Strongly agree,Disagree,Neutral,Agree,Strongly Agree "1. Add DDNAME support, leave length alone.",39%,30%,18%,4%,9% ,26,20,12,3,6 2. Add DDNAME support and extend length.,31%,16%,30%,13%,9% ,21,11,20,9,6 3. Extend length without DDNAME.,8%,9%,21%,26%,36% ,5,6,14,17,24 4. Add a syntax scanner for PARM files.,11%,11%,59%,15%,5% ,7,7,39,10,3 Sysprog concerns, ,1,2,3,4,5 ,Strongly agree,Disagree,Neutral,Agree,Strongly Agree 1. New PARM in IAESYS to set.,8%,15%,33%,36%,8% ,5,10,22,24,5 2. New system command to toggle.,9%,24%,41%,17%,9% ,6,16,27,11,6 3. Implemented in future release,2%,2%,35%,41%,21% ,1,1,23,27,14 4. Not retro'd to previous releases,3%,17%,40%,28%,12% ,2,11,26,18,8 5. New bit to query for PARM length,14%,15%,28%,34%,9% ,9,10,18,22,6 6. Backout scenarios should be documented,6%,0%,27%,50%,17% ,4,0,17,32,11 This survey, ,1,2,3,4,5 ,Strongly agree,Disagree,Neutral,Agree,Strongly Agree Like to see more,0%,2%,47%,36%,15% ,0,1,28,21,9 Wish it were more detailed,0%,13%,58%,17%,11% ,0,7,31,9,6 Wish it were more detailed Need questions about desired length: that's the crux of the issue!!! Like to see more The parm length should NOT exceed x'7fff' under any circumstances as far too many old programs will break. Wish it were more detailed Length question was ignored "Like to see more limit to 32K, within 1/2 word value currently presented." "Wish it were more detailed Should ask about length issues, binder setting, APF program issues, etc." Like to see more A very fast and simple way to have a community position of a particular issue. Wish it were more detailed Some items could have explanation to suppres any doubt. Like to see moreonly if the ability to extend the parameter options were truly modifiable and will be used by those who really think that they need to extend the parameter beyond 100 characters <--.csv end> -- 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: COBOL compiler options JCL PARM.
Hello Peter, I'm glad I could provide some ideas! The one thing you can't guard against is people doing DD card overrides or even worse/better, writing their own compile procs. But if they're good enough to write their own procs, maybe they should move into systems. *g* (Hey, that's what I did 20+ years ago...) Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Nuttall, Peter [CCC-OT_IT] Sent: Wednesday December 13 2006 00:31 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Many thanks Ray, I may look into this as a possible long term solution. For the moment I have removed the options which are default at this site (some differ from the manual because they have been overridden by the sysproggys here) and abbreviated any that are left. Kind Regards, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ray Mullins Sent: 12 December 2006 17:19 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Having been down this path before in a galaxy far, far away: Because you can have multiple CBL cards at the beginning, have a PDS (SAF.PROT.CBL.DATA) whose members consist of single control cards - for example XREFY = CBL XREF XREFN = CBL NOXREF LISTY = CBL LIST LISTN = CBL NOLIST (of course, this is not an exhaustive list) Then have a proc: //DOMYCOMP PROC XREF=Y,LIST=N,PROG=XYZ ... //C EXEC PGM=IGYCBL00,... //SYSIN DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(XREF&XREF) // DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(LIST&LIST) //* THE FOLLOWING CONTAINS CBL PARMS THAT WE NEVER, EVER, EVER //* WANT THE PROGRAMMERS TO OVERRIDE, E.G., NOSSRANGE // DD DISP=SHR,DSN=SAF.PROT.CBL.DATA(ALWAYS) // DD DISP=SHR,DSN=OUR.BIG.OLD.SOURCE.COBOL(&PROG) ... You give the programmers the opportunity to override selected parms, and since CBL statement processing always takes the last specification of a keyword, the ALWAYS member contains those you want to enforce. And SAF is your friend preventing those pesky application programmers from creating their own custom members. Would this help in your situation? Best regards, Ray -- 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: COBOL compiler options JCL PARM.
R$ay, I have worked in several different environments. 1 They would not allow programmers write their own procs. 2 If programmers did write their own then it was unsupported by TS 3 Programmers had to use the procs provided by TS, even vendor supplied compile type procs had to be signed off by TS. I think 3 was the easiest to live in. Ed -- 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: COBOL compiler options JCL PARM.
Charles You'll have to take my word for it but that was actually the first manual I looked at also - I'm sure because Internet Explorer still retains the imprint of my having selected that manual and, for the purposes of this bit of research, only that manual. On searching with "PARM" none of the 15 hits looked promising - so I gave up. I also spotted that Chapter 2 was "Linkage Conventions" which I thought just might have it but none of the sections listed in the "Contents" looked promising - so I gave up again. Well, with the advice that I should concentrate on Chapter 2 and having seen a mention of "PARM" in the text you quote, I became emboldened. I checked the "PARM" hit list and selected "Programs in Primary Mode" - whatever that means - don't bother - I'm sure if I read enough of this chapter I'll find out. So in section 2.8.1, "Program in Primary Mode", we find your text and Figure 2-4, "Primary Mode Parameter List", which, in fact, actually shows the elusive 100 and how register 1 indirectly takes you to all 0-100 characters: http://publibz.boulder.ibm.com/bookmgr/pictures/iea2a660.p1z.gif Incidentally, I checked your text and found it identical - but you started in the middle of a paragraph so it wasn't so easy to spot at first. The first part of the paragraph reads rather oddly - since we're having a go at the author. The sentence immediately preceding your quoted text is most incongruous considering what is about to be described. The first part reads as follows: For a good example of how your primary mode programs can pass parameters, consider the way the system uses a register to pass information in the PARM field of an EXEC statement to your program. Unlike the parameter list produced for an EXEC statement, a general parameter list can have multiple parameters, there is no system-imposed limitation on the length of any parameter, and no parameter has a system-defined format. Lengths and formats of parameters are defined by the called service. "Lengths and formats of parameters are defined by the called service." would make more sense if it were replaced by "In general, lengths and formats of parameters are defined by the called service. However, for the case of the PARM field of an EXEC statement, it is clearly the *calling* service." The "asterisked" word would be in italics. I went through the remaining "PARM" hits and verified that this was the only relevant description. The PARM field of an EXEC statement is somewhat curiously used as an *example* of passing parameters in register 1 - supposedly a "good" one amazingly enough - which tends to support my not being bold enough to find it before. Chris Mason ----- Original Message - From: "Charles Mills" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Wednesday, 13 December, 2006 4:18 PM Subject: Re: COBOL compiler options JCL PARM. > > [1] In which manual is this documented these days? > > It's in the Assembler Service Guide, which is where I would expect to find > it (i.e., the first place I looked) Chapter 2, which is the first "real" > chapter. > > Interestingly, they do not mention the 100-character limit, even though this > section deals specifically with jobstep programs (not linkage in general -- > note the references to PARM specifically). Perhaps there IS hope after all: > > "When your program receives control from the system, register 1 contains the > address of a fullword on a fullword boundary in your program's address space > (see Figure 2-4). The high-order bit (bit 0) of this word is set to 1. The > system uses this convention to indicate the last word in a variable-length > parameter list. Bits 1-31 of the fullword contain the address of a two-byte > length field on a halfword boundary. The length field contains a binary > count of the number of bytes in the PARM field, which immediately follows > the length field. If the PARM field was omitted in the EXEC statement, the > count is set to zero. To prevent possible errors, always use the count as a > length attribute in acquiring the information in the PARM field." > > BTW, the use of "field" in the above is incorrect and should probably read > "parameter" (although "PARM parameter" does sound funny and that may be why > the writer avoided it). The JCL reference uses "field" to mean the major > "areas" of JCL statements: the parameter field, the comments field, etc. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf > Of Chris Mason > Sent: Tuesday, December 12, 2006 10:32 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject
Re: COBOL compiler options JCL PARM.
>I actually look after the change management software and am trying to > >Ahh well, I will make sure all the opts are abbreviated and recommend to our programmers that they use the CBL statement in their source for any extra options they might want to add. > As an ex-change management person, I have to recommend you do not do that and indeed that you prohibit your programmers from using the CBL statements. (Even add a filter to the compile procedure to kick the CBL statements out!) You, as the change manager, want to be in exclusive control of the compile options. Maybe your best bet is just to automatically, in the compile procedure, pre- pend the source code of the programs that you need to compile with a set of CBL statements to set the options you require. Cheers, Jantje. -- 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: COBOL compiler options JCL PARM.
Jan MOEYERSONS wrote: I actually look after the change management software and am trying to Ahh well, I will make sure all the opts are abbreviated and recommend to our programmers that they use the CBL statement in their source for any extra options they might want to add. As an ex-change management person, I have to recommend you do not do that and indeed that you prohibit your programmers from using the CBL statements. (Even add a filter to the compile procedure to kick the CBL statements out!) You, as the change manager, want to be in exclusive control of the compile options. Everybody wants to be king [or queen]. But there are always cases where the supplied defaults are not the right values for a situation. My approach would be: 1) establish your standards and install the compiler with those values as the defaults; 2) make sure everyone is aware of the standard default values, what they mean and why they are in place; 3) allow applications programmers to override default values when they see a need. Maybe your best bet is just to automatically, in the compile procedure, pre- pend the source code of the programs that you need to compile with a set of CBL statements to set the options you require. Cheers, Jantje. Kind regards, -Steve Comstock The Trainer's Friend, Inc. http://www.trainersfriend.com -- 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: COBOL compiler options JCL PARM.
In a recent note, Chris Mason said: > Date: Thu, 14 Dec 2006 05:52:00 +0100 > > http://publibz.boulder.ibm.com/bookmgr/pictures/iea2a660.p1z.gif > > > For a good example of how your primary mode programs can pass parameters, > consider the way the system uses a register to pass information in the PARM > field of an EXEC statement to your program. Unlike the parameter list > produced for an EXEC statement, a general parameter list can have multiple > parameters, there is no system-imposed limitation on the length of any > parameter, and no parameter has a system-defined format. Lengths and formats > of parameters are defined by the called service. > > > > "Lengths and formats of parameters are defined by the called service." would > make more sense if it were replaced by "In general, lengths and formats of > parameters are defined by the called service. However, for the case of the > PARM field of an EXEC statement, it is clearly the *calling* service." The > "asterisked" word would be in italics. > Not really. I'll agree with the manual here. The called service always defines the lengths and formats. The EXEC statement or the programmer may pass parameters that don't conform to the definition by the called service, in which case the called service will properly report an error. A couple examples (using TSO for convenience rather than JCL, but the interface is identical, even to the 100-character limit): READY call *(GIMSMP) 'foobar' PAGE 0001 - NOW SET TOZONE DATE 12/14/06 TIME 06:46:07 SMP/E 33.18 SMPOUT OUTPUT GIM42401ITHE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC STATEMENT FOR GIMSMP: 'FOOBAR'. GIM20307T ** THERE IS A SYNTAX ERROR IN THE EXEC PARM STATEMENT AT CHARACTER 01. ... the format of the passed parameter did not meet the requirements of the called service, which reported an error. READY call *(CSNBOWH) 'wombat' IKJ56641I CSNBOWH ENDED DUE TO ERROR+ READY ... CSNBOWH defines a requirement for multiple parameters. Neither CALL nor EXEC can define it otherwise, but when either passes only a single parameter, CSNBOWH fails with an error. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: COBOL compiler options JCL PARM.
On the other hand if change control changes code in any way they become responsible for the results. IBM Mainframe Discussion List wrote on 12/14/2006 04:31:46 AM: > As an ex-change management person, I have to recommend you do not do that > and indeed that you prohibit your programmers from using the CBL > statements. (Even add a filter to the compile procedure to kick the CBL > statements out!) You, as the change manager, want to be in exclusive > control of the compile options. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: COBOL compiler options JCL PARM.
Paul Not for the first time on this list I believe the discussion is concerning the fashion sense of the angels dancing on the head of a pin. Both your examples concern *content* not "lengths and formats". In the case of an Assembler program necessarily written to be called by logic associated with the operating system, clearly the program, the "called" logic, is written *after* the logic associated with the operating system, the "calling" logic, and so the *calling* logic defines the "lengths and formats" - and does so according to the now famous Figure 2-4. I've replaced the word "service" with "logic" for clarity. In the general case, the program being written is the "calling" logic and it calls "services", already written, which define the format of any parameters - obviously. If you are combining "services" as in your examples, a "calling" service and a "called" service, they both need to understand a particular common definition of "lengths and formats" for the purposes of passing a character string. The user of the "calling" service can control the content of the character string, the passed parameter, and the user must abide by rules set by the "called" service. But it's *content*, not "lengths and formats". This is all so obvious - even tautologous - I must be missing something somewhere. Chris Mason - Original Message - From: "Paul Gilmartin" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Thursday, 14 December, 2006 3:03 PM Subject: Re: COBOL compiler options JCL PARM. > In a recent note, Chris Mason said: > > > Date: Thu, 14 Dec 2006 05:52:00 +0100 > > > > http://publibz.boulder.ibm.com/bookmgr/pictures/iea2a660.p1z.gif > > > > > > For a good example of how your primary mode programs can pass parameters, > > consider the way the system uses a register to pass information in the PARM > > field of an EXEC statement to your program. Unlike the parameter list > > produced for an EXEC statement, a general parameter list can have multiple > > parameters, there is no system-imposed limitation on the length of any > > parameter, and no parameter has a system-defined format. Lengths and formats > > of parameters are defined by the called service. > > > > > > > > "Lengths and formats of parameters are defined by the called service." would > > make more sense if it were replaced by "In general, lengths and formats of > > parameters are defined by the called service. However, for the case of the > > PARM field of an EXEC statement, it is clearly the *calling* service." The > > "asterisked" word would be in italics. > > > Not really. I'll agree with the manual here. The called service > always defines the lengths and formats. The EXEC statement or the > programmer may pass parameters that don't conform to the definition > by the called service, in which case the called service will properly > report an error. A couple examples (using TSO for convenience rather > than JCL, but the interface is identical, even to the 100-character > limit): > > READY > call *(GIMSMP) 'foobar' > PAGE 0001 - NOW SET TOZONE DATE 12/14/06 TIME 06:46:07 SMP/E 33.18 SMPOUT OUTPUT > > GIM42401ITHE FOLLOWING PARAMETERS WERE SPECIFIED ON THE EXEC STATEMENT FOR GIMSMP: 'FOOBAR'. > GIM20307T ** THERE IS A SYNTAX ERROR IN THE EXEC PARM STATEMENT AT CHARACTER 01. > > ... the format of the passed parameter did not meet the requirements > of the called service, which reported an error. > > READY > call *(CSNBOWH) 'wombat' > IKJ56641I CSNBOWH ENDED DUE TO ERROR+ > READY > > ... CSNBOWH defines a requirement for multiple parameters. Neither > CALL nor EXEC can define it otherwise, but when either passes only > a single parameter, CSNBOWH fails with an error. -- 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: COBOL compiler options JCL PARM.
Steve, That's exactly my take on the position. There are times when an application programmer needs to do something that requires a change to the options. The onus is on the AP to understand the option he is changing. Kind Regards, Peter -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Steve Comstock Sent: 14 December 2006 13:23 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL compiler options JCL PARM. Everybody wants to be king [or queen]. But there are always cases where the supplied defaults are not the right values for a situation. My approach would be: 1) establish your standards and install the compiler with those values as the defaults; 2) make sure everyone is aware of the standard default values, what they mean and why they are in place; 3) allow applications programmers to override default values when they see a need. Kind regards, -Steve Comstock The Trainer's Friend, Inc. http://www.trainersfriend.com -- 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: COBOL compiler options JCL PARM.
AFAIR IBM will change the JCL limit in the future. Wasn't this discussed months ago. After this there is a good chance that the Cobol-Compiler would follow Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Saturday, December 16, 2006 4:32 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL compiler options JCL PARM. To the best of my knowledge, no current or (relatively recently past, i.e. OS/VS COBOL or later) compiler has created object code that "truncates" passed parameters to called subprograms. It *IS* true that the compiler itself may (as documented) only pay attention to the first 100 bytes of passed data, but that has nothing to do with object code created by it. NOTE: From VS COBOL II thru IBM COBOL for OS/390 & VM, the compiler was "single-sourced". Therefore, as the 100-byte limit is a JCL, not a VM or CMS restriction, this would surprise me BUT it may be that only 100 bytes for the compiler was the documented restriction. -- 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: Fw: COBOL compiler options JCL PARM.
Bill Klein wrote: If the parm string sets environment variables, you can move those into a separate DD. Do a search on _CEE_ENVFILE. > > There have been previous requests for COBOL to have the same type of DD that > PL/I has had for years (and that LE has recently introduced) to avoid this. > However, there certainly is none right now. > > Steve has given a couple of answers, and using a CBL (Process) card (that > you can concatenate with your source code) is one way. > > HOWEVER, I would suggest that you also look at the programming guide for > what the "smallest" abbreviation is for each compiler option. I have rarely > seen sites use the minimum for each option. If you need to find them, check > out: > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG31/CCONTENT > S > > "Nuttall, Peter [CCC-OT_IT]" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>... > > Hi All, > > > > Enterprise COBOL compiler v3.4. > > > > Am pretty sure someone else must have hit this. I have hit the 100 char (I > think ?) limit for the opts passed to the compiler via the Parm setting in > the JCL. > > > > For the Enterprise PL1 compiler I solved this by setting > PARM='+DD:OPTIONS' in the JCL and then putting the compiler opts in the dd > named OPTIONS. Is there a way for doing this with the Enterprise COBOL > Compiler ? ... I have been looking through the manuals, and have not found > anything ? > > > > Many thanks in advance for any help, > > Peter -- Don Poitras - zSeries R & D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- 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
Fw: Fw: COBOL compiler options JCL PARM.
environment variable? At compile-time? (LE *does* let you use a DD for setting run-time options - if you are on z/OS 1.8) "Don Poitras" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Bill Klein wrote: > If the parm string sets environment variables, you can move those into a > separate DD. Do a search on _CEE_ENVFILE. > > > > -- 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
IBM Enterprise COBOL - compiler options that impact "behavior"
This is a follow-up on an earlier IBM-MAIN thread. I thought that it might be interesting AND USEFUL to "document" which IBM Enterprise COBOL compiler options can "impact" run-time behavior. By this I mean that the same source code will compile "cleanly" with any setting of these options but that for programs that COMPLETE their "run" the "output" might be different. (I phrase it this way to avoid options that impact "storage" usage at compile or run-time. I am also "ignoring" performance differences.). Looking at the list of options at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/CCON TENTS My initial list of "potentially impacting" options is: - ADV - CICS (depending on suboptions) - CODEPAGE - CURRENCY - DATEPROC - DYNAM (only if CANCEL is used) - FASTSRT (only if DECLARATIVES are used) - INTDATE - NUMPROC - PGMNAME - QUOTE/APOST (figurative constant, not literals) - SQL (depending on suboptions) - SSRANGE (if checking is turned on at run-time) - THREAD - TRUNC - YEARWINDOW - ZWB Of you "IBM COBOL" types, do you have any opinions on any that I have missed - or that I have included that you think do NOT impact run-time behavior? -- Bill Klein wmklein ix.netcom.com -- 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
IBM Enterprise COBOL - compiler options that impact "behavior"
See comments below for some of my "responses". I thought I was clear that I was NOT talking about "performance" or "storage" impacts. I think most of those types of "impacts" are cases where you and I disagree. "Steve Comstock" <[EMAIL PROTECTED]> wrote in message news:<442C6C2B.7020105 > > - DYNAM (only if CANCEL is used) > This impacts runtime behavior whether or not CANCEL is used DYNAM and NODYNAM do not impact the output/results of a program UNLESS a CANCEL is used. CANCEL of a program CALLed via a literal with NODYNAM does NOT place the subprogram in "initial state" - while it does with DYNAM specified. What other run-time behavior difference do you know of? > > > - FASTSRT (only if DECLARATIVES are used) > This impacts runtime behavior whether or not DECLARATIVES are used, > I believe I know of NO time that FASTSRT impacts run-time results (other than the OBVIOUS performance implication) except for when a DECLARATIVE should be "reached" by a "bad SORT". This works with NOFASTSRT, but not with FASTSRT. > > - PGMNAME > I don't see the runtime behavior impact of this Depending upon the setting of PGMNAME, a CALL to "A2345678" may or may not find a subprogram with the name "a2345678" or "A234567899" > > > - QUOTE/APOST (figurative constant, not literals) > I don't see the runtime behavior impact of this With QUOTE the figurative constant QUOTE is " With APOST it is ' That impacts comparisons and often DISPLAY and written output > In some sense, TEST can impact runtime behavior. I think that IBM accepts as "APARABLE" and case where a programs that are compiled with various TEST options and the programs run to completion give different results. Do you know of cases where semantics ARE impacted? > > ARITH can impact runtime behavior You are probably right. I was thinking that most of the differences would be detected at compile-time if you tried using numeric items over 18 digits. However, this can impact "Intermediate results" - even if all data individual items are limited to 18 digits. > > DLL can impact runtime behavior How? > > OPTIMIZE can impact runtime behavior Again, like "TEST", I believe that IBM accepts as APARable any differences in the results (other than performance) from various settings of OPT. Even the "removal" of non-referenced data items can't impact run-time BEHAVIOR for "valid" COBOL programs. > > OUTDD can impact runtime behavior I thought about including this. However, I think that LE will do a DYNAMIC allocation of whatever this points to, so that the results are always the same - just different DDNames. > > RENT can impact runtime behavior (along with DATA) How? (Other than where storage is allocated? This impacts performance but not RESULTS for two different programs that both run to successful conclusion. > > In some sense, RMODE can impact runtime behavior > -- 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: IBM Enterprise COBOL - compiler options that impact "behavior"
Bill Klein wrote: This is a follow-up on an earlier IBM-MAIN thread. I thought that it might be interesting AND USEFUL to "document" which IBM Enterprise COBOL compiler options can "impact" run-time behavior. By this I mean that the same source code will compile "cleanly" with any setting of these options but that for programs that COMPLETE their "run" the "output" might be different. (I phrase it this way to avoid options that impact "storage" usage at compile or run-time. I am also "ignoring" performance differences.). Looking at the list of options at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/CCON TENTS My initial list of "potentially impacting" options is: - ADV - CICS (depending on suboptions) - CODEPAGE - CURRENCY - DATEPROC - DYNAM (only if CANCEL is used) This impacts runtime behavior whether or not CANCEL is used - FASTSRT (only if DECLARATIVES are used) This impacts runtime behavior whether or not DECLARATIVES are used, I believe - INTDATE - NUMPROC - PGMNAME I don't see the runtime behavior impact of this - QUOTE/APOST (figurative constant, not literals) I don't see the runtime behavior impact of this - SQL (depending on suboptions) - SSRANGE (if checking is turned on at run-time) - THREAD - TRUNC - YEARWINDOW - ZWB Of you "IBM COBOL" types, do you have any opinions on any that I have missed - or that I have included that you think do NOT impact run-time behavior? In some sense, TEST can impact runtime behavior. ARITH can impact runtime behavior DLL can impact runtime behavior OPTIMIZE can impact runtime behavior OUTDD can impact runtime behavior RENT can impact runtime behavior (along with DATA) In some sense, RMODE can impact runtime behavior So, my opinion, for what it's worth. Kind regards, -Steve Comstock -- 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: IBM Enterprise COBOL - compiler options that impact "behavior"
"good options" list in a "consultant" report AWO [VB output only] CMPR2(NO) DYNAM(NO) FASTSRT(YES) [consultant says nothing about declaritives] NUMPROC(PFD) OPT(STD) SSRANGE(NO) TEST(NO) TRUNC(OPT) IBM Mainframe Discussion List wrote on 03/30/2006 06:11:37 PM: > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG30/CCONTENTS > My initial list of "potentially impacting" options is: > - ADV > - CICS (depending on suboptions) > - CODEPAGE > - CURRENCY > - DATEPROC > - DYNAM (only if CANCEL is used) > - FASTSRT (only if DECLARATIVES are used) > - INTDATE > - NUMPROC > - PGMNAME > - QUOTE/APOST (figurative constant, not literals) > - SQL (depending on suboptions) > - SSRANGE (if checking is turned on at run-time) > - THREAD > - TRUNC > - YEARWINDOW > - ZWB - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: IBM Enterprise COBOL - compiler options that impact "behavior"
ALL31 is a recommended choice for CICS. It cuts down on a lot of load overhead. And, it doesn't stop you from loading 24-bit. It only loads the prefix code when you call a 24, rather than all the time. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IBM Enterprise COBOL - compiler options that impact "behavior"
Bill Klein wrote: See comments below for some of my "responses". I thought I was clear that I was NOT talking about "performance" or "storage" impacts. I think most of those types of "impacts" are cases where you and I disagree. Well, I was mostly thinking about performance, so I missed your caveat there. A few thoughts are below, marked by ===> "Steve Comstock" <[EMAIL PROTECTED]> wrote in message news:<442C6C2B.7020105 - DYNAM (only if CANCEL is used) This impacts runtime behavior whether or not CANCEL is used DYNAM and NODYNAM do not impact the output/results of a program UNLESS a CANCEL is used. CANCEL of a program CALLed via a literal with NODYNAM does NOT place the subprogram in "initial state" - while it does with DYNAM specified. What other run-time behavior difference do you know of? ===> I was thinking performance; there is, of course, also ===> module size of static vs. linked; finally, there are ===> different linkages / capabilities between DYNAM and DLL - FASTSRT (only if DECLARATIVES are used) This impacts runtime behavior whether or not DECLARATIVES are used, I believe I know of NO time that FASTSRT impacts run-time results (other than the OBVIOUS performance implication) except for when a DECLARATIVE should be "reached" by a "bad SORT". This works with NOFASTSRT, but not with FASTSRT. - PGMNAME I don't see the runtime behavior impact of this Depending upon the setting of PGMNAME, a CALL to "A2345678" may or may not find a subprogram with the name "a2345678" or "A234567899" ===> ISTR Tom Ross saying dynamic calls always had ===> their target module names uppercased; but, I ===> could be mis-remembering. DYNAM will never ===> find A234567899, but DLL might. - QUOTE/APOST (figurative constant, not literals) I don't see the runtime behavior impact of this With QUOTE the figurative constant QUOTE is " With APOST it is ' That impacts comparisons and often DISPLAY and written output In some sense, TEST can impact runtime behavior. I think that IBM accepts as "APARABLE" and case where a programs that are compiled with various TEST options and the programs run to completion give different results. Do you know of cases where semantics ARE impacted? ===> again, I was thinking performance; also, behavior is ===> different at abend time. ARITH can impact runtime behavior You are probably right. I was thinking that most of the differences would be detected at compile-time if you tried using numeric items over 18 digits. However, this can impact "Intermediate results" - even if all data individual items are limited to 18 digits. DLL can impact runtime behavior How? ===> there are two dynamic call styles in COBOL; one ===> is invoked when you compile with DYNAM; if you ===> compile with DLL, all dyanmic calls are DLL-style, ===> the second style of dynamic calls. You cannot mix ===> these in a single program. The two styles use ===> different mechanisms to locate subroutines, the ===> style being dependent on DEFSD information. OPTIMIZE can impact runtime behavior Again, like "TEST", I believe that IBM accepts as APARable any differences in the results (other than performance) from various settings of OPT. Even the "removal" of non-referenced data items can't impact run-time BEHAVIOR for "valid" COBOL programs. ===> again, I was thinking performance was included in ===> your criteria. OUTDD can impact runtime behavior I thought about including this. However, I think that LE will do a DYNAMIC allocation of whatever this points to, so that the results are always the same - just different DDNames. ===> Yes, but the user / developer / debugger may ===> have to look in unexpected places to find some ===> output they are expecting. RENT can impact runtime behavior (along with DATA) How? (Other than where storage is allocated? This impacts performance but not RESULTS for two different programs that both run to successful conclusion. ===> It can impact interactions with other programs, ===> especially older programs with differing AMODEs. In some sense, RMODE can impact runtime behavior Kind regards, -Steve Comstock -- 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: IBM Enterprise COBOL - compiler options that impact "behavior"
Bill Klein wrote: ... DYNAM and NODYNAM do not impact the output/results of a program UNLESS a CANCEL is used. CANCEL of a program CALLed via a literal with NODYNAM does NOT place the subprogram in "initial state" - while it does with DYNAM specified. What other run-time behavior difference do you know of? ... DYNAM/NODYNAM can have a drastic impact on program results if the called subroutine changes and the owner of the calling program fails to relink and continues to execute a now obsolete, non functional, version that is statically linked. Or conversely, a program deliberately intended to work with "old" data could be broken if a new version of a subroutine was dynamically loaded, when a specific older version was intended to be statically linked. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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
