Re: COBOL Working Storage being reset
This got sent to Gilbert only. Reposting for the list. Good idea. I'll give it a try. We also created the worlds shortest Cobol program that does something. It calls the Assembler program thereby also creating an enclave. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Gilbert Saint-Flour <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 04:28 PM Please respond to [EMAIL PROTECTED] To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset Alan, I suggest that you add CALL ILBOSTP0 at the beginning of the assembler program (make sure R13 is clean). This is the simplest way to create an enclave and tell the COBOL module that it's a sub-program, not a main program. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. 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 Working Storage being reset
Does the RTEREUS=(ON) option help in this case? I know it greatly reduces overhead when invoking a COBOL program from a non-LE environment because the runtime doesn't need to be reestablished. I don't know for sure how it affects Working Storgae. Note that this only works for COBOL (not other LE-based C or PL/I programs). Regards, Rich -- 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 Working Storage being reset
Alan, I suggest that you add CALL ILBOSTP0 at the beginning of the assembler program (make sure R13 is clean). This is the simplest way to create an enclave and tell the COBOL module that it's a sub-program, not a main program. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[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
Re: COBOL Working Storage being reset
Alan Schwartz wrote: Brian (and John), I've been reading the Cobol and LE books for ILC information. In my z/OS 1.7 LE Writing ILC Applications topic 14.3 there's "Table 61. What Occurs When Non-Language Environment-Conforming Assembler Invokes an HLL Main". for invoking options LOAD and BALR, when LE is up, it says "CEE393 is signaled. You cannot LOAD and BALR a main routine under Language Environment. However, in COBOL, this is supported because the COBOL program would be a subroutine, not a main." Perhaps I misinterpreted this to mean the Assembler was ok as was. Alan The call is supported, but as that table also points out, an Initial enclave is created. This is what tells you the working-storage is created fresh each time, since the module must be loaded each time. (There's more to it but that's enough to cause the symptoms you see.) To get the COBOL module in its last-used state each time you call, you will have to make the Assembler program LE-conforming. 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 Working Storage being reset
It's been a while, but I thought there were global options that get set when the product is installed, one of which affects how to treat working storage. I also thought that you could create a separate set of options that could be used to override the global ones (on a per job basis). -- 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 Working Storage being reset
Brian (and John), I've been reading the Cobol and LE books for ILC information. In my z/OS 1.7 LE Writing ILC Applications topic 14.3 there's "Table 61. What Occurs When Non-Language Environment-Conforming Assembler Invokes an HLL Main". for invoking options LOAD and BALR, when LE is up, it says "CEE393 is signaled. You cannot LOAD and BALR a main routine under Language Environment. However, in COBOL, this is supported because the COBOL program would be a subroutine, not a main." Perhaps I misinterpreted this to mean the Assembler was ok as was. Alan Brian Peterson <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 02:54 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset Is your assembler main program Language Environment-aware (by calling the CEEENTRY macro with MAIN=YES)? If not, then each time the assembler program calls the COBOL program, Language Environment builds a brand new runtime environment for the COBOL program to execute within. This overhead will result in additional CPU cost, as well as the behavior you're seeing. The Assembler main program should be made Language Environment-aware. Check the Enterprise COBOL Migration Guide (GC27-1409) on the LE bookshelf for details. Brian ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. 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 Working Storage being reset
1. The Assembler code is not LE conforming. Much consists of proprietary type macros (CKSYSTEM, CKDEBUG, CKENTER, CKCOMSHD, CKCALL CKCFNCTR) for example. 2. Compiler options have some differences as expected. The Enterprise Cobol options do have RENTand NOTHREAD 3. The source is exactly the same between runs. Just changing invoking program name. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Steve Comstock <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 02:58 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset 1. Is the Assembler code LE-conforming? 2. Does the compile proc for the Enterprise compiler use different options from the OS/VS compiler? In particular, consider RENT and THREAD 3. Is it the same program each time or do you have Enterprise COBOL version and an OS/VS version? Kind regards, -Steve Comstock ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. 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 Working Storage being reset
Exactly. Been in this section. The subprogram has no 'cancel' and there is no LOCAL-STORAGE-SECTION. I haven't seen anything proving the INITIAL attribute one way or the other. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Kirk Talman <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 02:56 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset 4.1.2 Ending and reentering main programs or subprograms A subprogram is usually left in its last-used state when it terminates with EXIT PROGRAM or GOBACK. The next time the subprogram is called in the run unit, its internal values will be as they were left, except that return values for PERFORM statements will be reset to their initial values. (In contrast, a main program is initialized each time it is called.) There are some cases where programs will be in their initial state: A subprogram that is dynamically called and then canceled will be in the initial state the next time it is called. A program with the INITIAL attribute will be in the initial state each time it is called. Data items defined in the LOCAL-STORAGE SECTION will be reset to the initial state specified by their VALUE clauses each time the program is called. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. 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 Working Storage being reset
Alan Schwartz wrote: I'm trying to help someone upgrade their Cobol code from OS/Cobol to Enterprise Cobol and they've run into a problem I haven't been able to solve (yet). The main program is an Assembler (HLA as I can see 569623400 in the module code) and it calls a number of other programs depending on logic. The particular Cobol programs we're working on is called multiple times. In the working storage section is this definition: 01 UPDATES-SWITCH PIC X VALUE 'N'. 88 NO-UPDATES VALUE 'N'. and the programmer has added these displays to prove the situation: DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH MOVE 'Y' TO UPDATES-SWITCH. DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH The results of the display first time through the Cobol program are: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program is OS/Cobol the subsequent displays show: UPDATES-SWITCH BEFORE Y UPDATES-SWITCHY but with Enterprise Cobol we get: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY Control from the Cobol program is returned to the Assembler program via GOBACK. I'm hoping for some suggestions as to why the UPDATES-SWITCH field is being reset to N. I'm still researching and if I find anything myself I'll let the list know. Thanks. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 1. Is the Assembler code LE-conforming? 2. Does the compile proc for the Enterprise compiler use different options from the OS/VS compiler? In particular, consider RENT and THREAD 3. Is it the same program each time or do you have Enterprise COBOL version and an OS/VS version? 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 Working Storage being reset
4.1.2 Ending and reentering main programs or subprograms A subprogram is usually left in its last-used state when it terminates with EXIT PROGRAM or GOBACK. The next time the subprogram is called in the run unit, its internal values will be as they were left, except that return values for PERFORM statements will be reset to their initial values. (In contrast, a main program is initialized each time it is called.) There are some cases where programs will be in their initial state: A subprogram that is dynamically called and then canceled will be in the initial state the next time it is called. A program with the INITIAL attribute will be in the initial state each time it is called. Data items defined in the LOCAL-STORAGE SECTION will be reset to the initial state specified by their VALUE clauses each time the program is called. IBM Mainframe Discussion List wrote on 07/06/2006 03:39:59 PM: > I'm trying to help someone upgrade their Cobol code from OS/Cobol to > Enterprise Cobol and they've run into a problem I haven't been able to > solve (yet). The main program is an Assembler (HLA as I can see 569623400 > in the module code) and it calls a number of other programs depending on > logic. > The particular Cobol programs we're working on is called multiple times. > In the working storage section is this definition: > 01 UPDATES-SWITCH PIC X VALUE 'N'. > 88 NO-UPDATES VALUE 'N'. > and the programmer has added these displays to prove the situation: > DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH > MOVE 'Y' TO UPDATES-SWITCH. > DISPLAY 'UPDATES-SWITCH ' UPDATES-SWITCH > The results of the display first time through the Cobol program are: > UPDATES-SWITCH BEFORE N > UPDATES-SWITCH Y > and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program > is OS/Cobol the subsequent displays show: > UPDATES-SWITCH BEFORE Y > UPDATES-SWITCH Y > but with Enterprise Cobol we get: > UPDATES-SWITCH BEFORE N > UPDATES-SWITCH Y > Control from the Cobol program is returned to the Assembler program via > GOBACK. > I'm hoping for some suggestions as to why the UPDATES-SWITCH field is > being reset to N. I'm still researching and if I find anything myself > I'll let the list know. > Thanks. > Alan Schwartz - 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 Working Storage being reset
Is your assembler main program Language Environment-aware (by calling the CEEENTRY macro with MAIN=YES)? If not, then each time the assembler program calls the COBOL program, Language Environment builds a brand new runtime environment for the COBOL program to execute within. This overhead will result in additional CPU cost, as well as the behavior you're seeing. The Assembler main program should be made Language Environment-aware. Check the Enterprise COBOL Migration Guide (GC27-1409) on the LE bookshelf for details. Brian On Thu, 6 Jul 2006 14:39:59 -0500, Alan Schwartz <[EMAIL PROTECTED]> wrote: >I'm hoping for some suggestions as to why the UPDATES-SWITCH field is >being reset to N. I'm still researching and if I find anything myself >I'll let the list know. > >Thanks. > >Alan Schwartz -- 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 Working Storage being reset
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz > Sent: Thursday, July 06, 2006 2:40 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: COBOL Working Storage being reset > > > I'm trying to help someone upgrade their Cobol code from OS/Cobol to > Enterprise Cobol and they've run into a problem I haven't > been able to > solve (yet). The main program is an Assembler (HLA as I can > see 569623400 > in the module code) and it calls a number of other programs > depending on > logic. > > The particular Cobol programs we're working on is called > multiple times. > In the working storage section is this definition: > > 01 UPDATES-SWITCH PIC X VALUE 'N'. > 88 NO-UPDATES VALUE 'N'. > > and the programmer has added these displays to prove the situation: > > DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH > MOVE 'Y' TO UPDATES-SWITCH. > DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH > > The results of the display first time through the Cobol program are: > > UPDATES-SWITCH BEFORE N > UPDATES-SWITCHY > > and is the same for OS/Cobol and Enterprise Cobol. When the > Cobol program > is OS/Cobol the subsequent displays show: > > UPDATES-SWITCH BEFORE Y > UPDATES-SWITCHY > > but with Enterprise Cobol we get: > > UPDATES-SWITCH BEFORE N > UPDATES-SWITCHY > > Control from the Cobol program is returned to the Assembler > program via > GOBACK. > > I'm hoping for some suggestions as to why the UPDATES-SWITCH field is > being reset to N. I'm still researching and if I find > anything myself > I'll let the list know. > > Thanks. To avoid this problem, your HLASM program must be Language Environment. The problem is that Enterprise COBOL is LE. When it is invoked from an non-Language Environment program, such as most assembler, then LE reinitializes itself, which means the program's Working Storage is reinitialized. >From "z/OS: Language Environment Programming Guide" Under Language Environment, an application terminates when any of the following conditions occur: ... COBOL's GOBACK statement in a main program ... -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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 Working Storage being reset
RENT, REUS on the binder different? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz Sent: Thursday, July 06, 2006 2:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL Working Storage being reset I'm trying to help someone upgrade their Cobol code from OS/Cobol to Enterprise Cobol and they've run into a problem I haven't been able to solve (yet). The main program is an Assembler (HLA as I can see 569623400 in the module code) and it calls a number of other programs depending on logic. The particular Cobol programs we're working on is called multiple times. In the working storage section is this definition: 01 UPDATES-SWITCH PIC X VALUE 'N'. 88 NO-UPDATES VALUE 'N'. and the programmer has added these displays to prove the situation: DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH MOVE 'Y' TO UPDATES-SWITCH. DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH The results of the display first time through the Cobol program are: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program is OS/Cobol the subsequent displays show: UPDATES-SWITCH BEFORE Y UPDATES-SWITCHY but with Enterprise Cobol we get: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY Control from the Cobol program is returned to the Assembler program via GOBACK. I'm hoping for some suggestions as to why the UPDATES-SWITCH field is being reset to N. I'm still researching and if I find anything myself I'll let the list know. Thanks. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 Working Storage being reset
I'm trying to help someone upgrade their Cobol code from OS/Cobol to Enterprise Cobol and they've run into a problem I haven't been able to solve (yet). The main program is an Assembler (HLA as I can see 569623400 in the module code) and it calls a number of other programs depending on logic. The particular Cobol programs we're working on is called multiple times. In the working storage section is this definition: 01 UPDATES-SWITCH PIC X VALUE 'N'. 88 NO-UPDATES VALUE 'N'. and the programmer has added these displays to prove the situation: DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH MOVE 'Y' TO UPDATES-SWITCH. DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH The results of the display first time through the Cobol program are: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program is OS/Cobol the subsequent displays show: UPDATES-SWITCH BEFORE Y UPDATES-SWITCHY but with Enterprise Cobol we get: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY Control from the Cobol program is returned to the Assembler program via GOBACK. I'm hoping for some suggestions as to why the UPDATES-SWITCH field is being reset to N. I'm still researching and if I find anything myself I'll let the list know. Thanks. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. 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
