Work Storage not inicialize when call the program again

delago · New User Joined: 29 Jul 2005 Posts: 21 Location: Brazil

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

mlp · New User Joined: 23 Sep 2005 Posts: 91

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.

dbzTHEdinosauer · Posted: Thu Dec 30, 2010 5:40 pm

cancel the previous advice.

PROGRAM-ID ABCDEI INITIAL.

Robert Sample · Posted: Thu Dec 30, 2010 5:44 pm

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.

Chalcedony Herbertson · New User Joined: 30 Dec 2010 Posts: 3 Location: Chennai

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,

dbzTHEdinosauer · Posted: Thu Dec 30, 2010 6:31 pm

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

B.S.

Robert Sample · Posted: Thu Dec 30, 2010 7:04 pm

Kjeld · Posted: Fri Dec 31, 2010 2:24 am

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.

mlp · New User Joined: 23 Sep 2005 Posts: 91

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

dbzTHEdinosauer · Posted: Fri Dec 31, 2010 2:27 pm

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.

mlp · New User Joined: 23 Sep 2005 Posts: 91

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.