Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Work Storage not inicialize when call the program again

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
delago

New User


Joined: 29 Jul 2005
Posts: 21
Location: Brazil

PostPosted: Thu Dec 30, 2010 5:16 pm    Post subject: Work Storage not inicialize when call the program again
Reply with quote

Hi Guy´s.

This is a mystery for me. I never seen this in a program with CICS.

I developer a program (sub-program for more exactly) and it run in IMS system, but work with DB2.
In the program, created various variables:

wk-sum-tot01 USAGE IS COMP-2 VALUE ZEROS.
wk-sum-tot02 USAGE IS COMP-2 VALUE ZEROS.
wk-sum-tot03 USAGE IS COMP-2 VALUE ZEROS.

When program run I use variables to acumulate values. See:

wk-sum-tot01 = wk-sum-tot01 + wk-tax

The same operation occur with another variables (k-sum-tot02 and k-sum-tot03).
The program finish ok.
But, I have a problem when call the program again. The variables (created in the work storage program) isn't clean. The continue stored in the variables.

I never this occur when work with Cobol and CICS.
My question: It his a problem or I need to contact my Support Development to seen the enviroment IMS?

Best Regards

Fernando Delago - Brazil/São Paulo
Back to top
View user's profile Send private message

mlp

New User


Joined: 23 Sep 2005
Posts: 91

PostPosted: Thu Dec 30, 2010 5:25 pm    Post subject:
Reply with quote

I think you are calling your sub-program from your main program inside a loop.

Once the call is complete and program control returns back to the main program and then again you are going for the call just before that use CANCEL <sub-prog name> to initialise the working storage of your sub-program. See below. This is how your main program should be.

CALL SUB-PROG
.
.
.
CANCEL SUB-PROG
CALL SUB-PROG

I hope this helps.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Dec 30, 2010 5:40 pm    Post subject:
Reply with quote

cancel the previous advice.

PROGRAM-ID ABCDEI INITIAL.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7912
Location: Bellevue, IA

PostPosted: Thu Dec 30, 2010 5:44 pm    Post subject:
Reply with quote

Congratulations! You have now found one of the differences between CICS and batch programs!

Batch subprograms don't reinitialize themselves between calls unless the INITIAL attribute is used, as Dick mentioned. EXEC CICS CALL invokes a program that has been initialized, every time.
Back to top
View user's profile Send private message
Chalcedony Herbertson

New User


Joined: 30 Dec 2010
Posts: 3
Location: Chennai

PostPosted: Thu Dec 30, 2010 5:54 pm    Post subject:
Reply with quote

Hi Fernando,

mlp is right.

There are two types of call
1) static call - sytnax is CALL '<subroutine name>'
when a subroutine is called statically, the working storage value (of the subroutine) will be lost once the program returns the control to the main program.

2)Dynamic call -
sytnax is
MOVE '<subroutine name>' to ws-called-program.
CALL ws-called-program.
When a subroutine is call dyamically, the working storage (of the subroutine) will be present in the dynamic memory space allocated for the main program to run. until an CANCEL command is encountered.
so when ever you have called the subroutine dynamically it is best practice to code the following verb:
CANCEL ws-called-program.

Regards,
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Dec 30, 2010 6:31 pm    Post subject:
Reply with quote

Chalcedony Herbertson & mlp,
Thankyou for helping end this year with so much

B.S.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7912
Location: Bellevue, IA

PostPosted: Thu Dec 30, 2010 7:04 pm    Post subject:
Reply with quote

Quote:
the working storage (of the subroutine) will be present in the dynamic memory space allocated for the main program to run.
WHAT dynamic memory space? The address space does not have any dynamic memory that I'm aware of -- memory may be allocated or unallocated, but the address space cannot change memory size; it is fixed based on the system IPL parameters.

Furthermore, CALL 'suprogram' may be static -- or dynamic -- depending upon the compiler options used. AND a static call means the memory for the subprogram is allocated when the load module is loaded into memory to start execution, and that memory will not be freed until the load module completes execution. In other words, Dony, the system works completely opposite from what you posted.
Back to top
View user's profile Send private message
Kjeld

Active User


Joined: 15 Dec 2009
Posts: 365
Location: Denmark

PostPosted: Fri Dec 31, 2010 2:24 am    Post subject:
Reply with quote

Hi Fernando,

In IMS/DC you are likely to get a 'dirty' loadmodule when you process a message in a MPP module. That means that you have to set or initialise all storage that you use during processing, in order to avoid interference with data from earlier transactions.

Value statements are only effective when a clean module is fetched from the reslib.
Back to top
View user's profile Send private message
mlp

New User


Joined: 23 Sep 2005
Posts: 91

PostPosted: Fri Dec 31, 2010 10:34 am    Post subject:
Reply with quote

This is how cancel statement works (as per enterprise cobol manual).

The CANCEL statement ensures that the referenced subprogram is entered in initial state the next time that it is called.

After a CANCEL statement for a called subprogram has been executed, that subprogram no longer has a logical connection to the program. The contents of data items in external data records described by the subprogram are not changed when that subprogram is canceled. If a CALL statement is executed later by any program in the run unit naming the same subprogram, that subprogram is entered in its initial state.

When a CANCEL statement is executed, all programs contained within the program referenced in the CANCEL statement are also canceled. The result is the same as if a valid CANCEL were executed for each contained program in the reverse order in which the programs appear in the separately compiled program.

A CANCEL statement closes all open files that are associated with an internal file connector in the program named in an explicit CANCEL statement. USE procedures associated with those files are not executed.

You can cancel a called subprogram in any of the following ways:
- By referencing it as the operand of a CANCEL statement
- By terminating the run unit of which the subprogram is a member
- By executing an EXIT PROGRAM statement or a GOBACK statement in the called subprogram if that subprogram possesses the initial attribute
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Dec 31, 2010 2:27 pm    Post subject:
Reply with quote

mlp,

using CANCEL to aviod coding appropriate initialization statements at beginning of processing (i.e. each invocation) is typical rookie programming.

Use of the INITIAL phrase in the Program-id statement removes the burden of coding CANCEL statements in the CALLing program.
and yes you are correct, the effect of the INITIAL phrase is the same as a CALLing program CANCEL.

In 30 years of COBOL programming, the only time I have seen a justified use of CANCEL was when the control program knows that the sub-module will never be called again and issues the CANCEL to free memory.

but to use CANCEL (and INITIAL)
because the programming of the sub-module is so poor that you have to
use a sledgehammer (CANCEL) to pound a tack (initialization code)
is not an answer.
Back to top
View user's profile Send private message
mlp

New User


Joined: 23 Sep 2005
Posts: 91

PostPosted: Fri Dec 31, 2010 4:12 pm    Post subject:
Reply with quote

Frankly speaking till this post, I was not aware of the significance of INITIAL in phrase. Its not that I have not used it, but never took time to look into details.

When I had encoutered the situation which Fernando is facing I had used CANCEL which solved my problem and that is reason I posted the solution.

I do agree with you that the CANCEL is bad programming practice and should be used as last option (like GOTO). The use of INITIAL phrase is more elegent solution.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts I can not compile my program PL1 V3.R... Miguel Fernandez PL/I & Assembler 7 Tue Dec 06, 2016 8:30 pm
No new posts IMS BMP program causes 878 system abend Artemk IMS DB/DC 7 Tue Nov 22, 2016 8:26 pm
No new posts Cobol EZASOKET call to SETSOCKOPT fails Andi1982 COBOL Programming 6 Thu Oct 06, 2016 7:12 pm
No new posts Strange EXEC function call in z/VM Willy Jensen CLIST & REXX 3 Wed Oct 05, 2016 2:07 pm
No new posts A sample of exit program for exit XMN... lind sh CICS 2 Mon Oct 03, 2016 5:07 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us