|
View previous topic :: View next topic
|
| Author |
Message |
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
| I'm confused about the behavior of the program, i guess it may be due to compiler options. I'm not sure. |
|
| Back to top |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
| I'm confused about the behavior of the program |
you are not going to get any help here if you do not describe the behavior that is confusing you. |
|
| Back to top |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
If a sub program(dynamic call) is called twice, for the first call normally a sub program(goback) returning the control back to main program the local variable will contain the initial values for second call. In my case why that program retains the values (first call) in second call. Please let me know.
Thanks,
Murali. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
What are the compile options? What does the CALL statement look like? Is program B linked into program A or is it an independent module?
You've stated that the call is dynamic, but you've provided no proof of this. A static call will retain values, and unless you've read and understood the COBOL Programming Guide and Language Reference manuals on dynamic calls, it is easy to think a static call is dynamic. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
a dynamic call will also perform the same.
the only time a CALLed module
does not retain working-storage values, generated during the invocation,
on second, third call is - the CALLed program is CANCELed
- the CALLed program has the INITIAL phrase as part of the PROGRAM-ID statement
- the CALLed program has code in procedure division that modifies working-storage variables before start of processing
Murali,
you want the working-storage variables at an initialized value for each invocation:
you don't want to change the sub-module
you need to CANCEL the module after return to the CALLing module each time. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Not quite the same (but gives predictable results) is always passing these fields from the caller to the called module. There would be no question of the value and if someone changes the way the module is called one day, the program will still perform consistently.
This was the standard for subroutine processing at several sites i've supported.
fwiw. . . |
|
| Back to top |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
Proof for Dynamic call,
| Code: |
2200-GET-POSSIBLE-MATCHES.
MOVE '2200-GET-POSSIBLE-MATCHES' TO WS-PARAGRAPH-NM.
MOVE ZERO TO IP-B002-ADDR-COUNT.
MOVE ZERO TO IP-B002-CSPCLT-COUNT.
CALL WS-R243B002 USING LK-ECA-HEADER,
LK-R243B002-DATA-IN,
LK-R243B002-DATA-OUT.
IF LK-ECA-RETURN-CD = '0000'
|
working storage declaration
| Code: |
01 WS-CALLED-PROGRAMS.
05 WS-R243B002 PIC X(08) VALUE 'R243B002'.
05 WS-R243B003 PIC X(08) VALUE 'R243B003'.
05 WS-R243B004 PIC X(08) VALUE 'R243B004'.
05 WS-R243B005 PIC X(08) VALUE 'R243B005'.
|
Program WS-R243B002 is reffered as PROGRAM 'B' and compiled with dynam option.
Thanks,
Murali. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Did anybody notice that the question was about LOCAL-STORAGE area ?
| pkmurali wrote: |
| the Local-storage values remains the same when program 'A' calls Program 'B' second time. |
|
|
| Back to top |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
Hope i have given the proof for Dynamic call ( apart from calling statement the compiler is not specified as DYNAM so in default it would be NODYNAM), But still i am not clear about how the sub program behaving like an static call.
I believe, the below statement is correct,
A statically called subroutine will not be in its initial state the next time it is called unless you explicitly use INITIAL or you do a CANCEL. A dynamically called routine will always be in its initial state.
In static linking, the called subroutine is link-edited into the calling program , while in dynamic linking, the subroutine & the main program will exist as separate load modules. You choose static/dynamic linking by choosing either the DYNAM or NODYNAM link edit option. (Even if you choose NODYNAM, a CALL identifier (as opposed to a CALL literal), will translate to a DYNAMIC call).
What could be the reason for this sort of behaviour any changes in program Genes  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| What could be the reason for this sort of behaviour |
Unless i've missed something, what you are saying is that everything is working as documented |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
pkmurali, your bold statements in your last post are not correct. From the COBOL Programming Guide, emphasis added by me
| Quote: |
1.1.3.2 Comparison of WORKING-STORAGE and LOCAL-STORAGE
How data items are allocated and initialized varies depending on whether the items are in the WORKING-STORAGE SECTION or LOCAL-STORAGE SECTION.
WORKING-STORAGE for programs is allocated at the start of the run unit.
Any data items that have VALUE clauses are initialized to the appropriate value at that time. For the duration of the run unit, WORKING-STORAGE items persist in their last-used state. Exceptions are:
* A program with INITIAL specified in the PROGRAM-ID paragraph
In this case, WORKING-STORAGE data items are reinitialized each time that the program is entered.
* A subprogram that is dynamically called and then canceled
In this case, WORKING-STORAGE data items are reinitialized on the first reentry into the program following the CANCEL.
WORKING-STORAGE is deallocated at the termination of the run unit. |
For batch programs the run unit starts with the main program initialization and continues until the main program ends. Unless your subprogram explicitly has INITIAL in the PROGRAM-ID paragraph, OR it is dynamically called and then canceled, the subprogram variables will retain their values across subprogram calls. Whether the program is dynamically linked does not matter unless the calling program does a CANCEL on the subprogram. If you don't have a CANCEL in your calling program, and you do not have INITIAL on your subprogram PROGRAM-ID paragraph, then your variables in the subprogram will retain the same values from call to call.
Also, be aware that LOCAL-STORAGE and WORKING-STORAGE are very different items now. You need to distinguish between them as WORKING-STORAGE is allocated by run unit while LOCAL-STORAGE is allocated by invocation. |
|
| Back to top |
|
|
|
|
