COBOL WORKING /LOCAL-STORAGE, reentrancy, CICS

[yuriyking]

Hi all.
I’m new to COBOL and I came from C/C++.
My question is: what is the difference between
LOCAL-STORAGE SECTION and WORKING-STORAGE SECTION.
As I understood, in terms of C, LOCAL-STORAGE SECTION – automatic storage class(stack), WORKING-STORAGE SECTION – static storage class. Am I right?

If yes, my next question:
A COBOL program for CICS should be at least quasi-reentrant in order to run correctly from several transactions concurrently.
If I compile/link-edit COBOL program without RENT option and I did not provide quasi-reentrancy in it (for example, I modify WORKING-STORAGE between two EXEC CICS calls) then I can get inconsistent concurrent execution.
I was almost sure about it before I read:

“Multithreading requires that all CICS application programs be reentrant; that is, they must be serially reusable between entry and exit points. CICS APPLICATION PROGRAMS USING THE EXEC CICS INTERFACE OBEY THIS RULE AUTOMATICALLY. For COBOL, C, and C++ programs, reentrancy is ensured by a fresh copy of working storage being obtained each time the program is invoked.”

http://publibz.boulder.ibm.com/cgi-...19/2.1.2.12?SHELF=&DT=20020416125733&FS=FALSE

Does it mean that I may to compile COBOL program without RENT option even if it modifies WORKING-STORAGE between two EXEC CICS calls?
Does it mean that COBOL program has its own copy of WORKING-STORAGE for every concurrent running transaction?
What about C? Does it mean that C program has its own copy of static storage for every concurrent running transaction?

Thanks.

 

[yuriyking]

Considering I have RELOAD(NO) in CICS program definition.

 

[FearsomeFastFemale]

A CICS COBOL program may modify the the working storage between some exec cics calls
CICS programs need to be(well usually should be) psedoconvestational. So that the transaction (and associated program) end between tasks.
a common example:-
inquiry (keyboad) -> CICS -> response (screen) -> inquiry
during the time the operator is entering data on the screen a cics task will terminate and start again when the operator send the data back to CICS (enter or attention key)

All task storage is released by CICS at termination. Task initation must reference the previous execution. This is normally done by saving some key information in the commarea (or in the TCTUA)
eg exec cics return
transid(xxxx) commarea(....) length(....)
end-exec

so when the screen is sent (using exec cics send for example) the program then issues a return to end the task.

When screen is actioned the transaction will start again the program starting at line 1. You then use your saved data(from the commarea) to continue processing. The contents of the working storagae will have been lost and be back at inital values.

And you should use RENT to compile.

a couple of good book for CICS are
CICS Essentials: For Application Developers and Programmers
ISBN 0070358699
and
"CICS a programmers reference" by Phyllis Donofrio
ISBN 0070176078

 

[yuriyking]

Thanks, FearsomeFastFemale.
But it is still unclear:
if I compile COBOL program without RENT otions,
will it run correctly in multithread environment?
If yes, how does CICS supply this?
For example, C program which modifies static memory and is compiled without RENT, will not run correctly within several transactions concurrently.

 

[FearsomeFastFemale]

You should always use RENT when compiling CICS programs it will cause errors but I am not sure of specific errors as we always do.

Regards

 

[yuriyking]

OK. I will do it.
Thanks FearsomeFastFemale.

 

[ciczman]

Yuriyking,
Working Storage is Local until a conversation has been started, at which time control of the data is shared.
FearsomeFastFemale is correct, but if there's a requirement for not using Rent. Read on .....
There is nothing to prevent non-reentrant application programs being executed by CICS. However, such an application program would not provide consistent results in a multi-threading environment.
To use non-reentrant programs, that are modifiable by other programs. Specify the RELOAD(YES) option on their resource definition. RELOAD(YES)results in a fresh copy of the program or module being loaded into storage
for each request. This option ensures that multithreading tasks that access a non-reentrant program work from their own copy of the program, and are unaffected by changes made to another version of the program by other concurrent tasks running in the CICS region. Hope this answers your questions.
So virtually anything is possible, it just depends what you are trying to accomplish. Application Programmer manual

http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dfhjap3e/CCONTENTS

 

[yuriyking]

Hi, ciczman.
I did not understand your statement:
"Working Storage is Local until a conversation has been started, at which time control of the data is shared."
Could you clarify it please.

My core question was:
As I understood, in terms of C, LOCAL-STORAGE SECTION – automatic storage class (stack, every thread has its own copy of it), WORKING-STORAGE SECTION – static storage class(all threads acess the same memory area). Am I right?

 

[ciczman]

Yuriyking,
Answer to the core question:
Every thread/task has it's own copy of working storage TRUE. A conversation is initiated whenever interaction (screen or transaction started) is initiated between a user/transaction and a program. The Working Storage holds the conversation results. Since the same program can be used synchronously, but process different data per conversation. Working Storage keeps the data integrity intact for the conversation. When you use an ATM you are having a conversation with your bank records. The working storage data is live until the conversation has ended. So you have multiple copies of a program with it's own data container (working Storage) processing the data as directed by the user and program.

 

[yuriyking]

...
But if "Every thread/task has it's own copy of working storage TRUE.", why should I compile COBOL program for CICS with RENT option if COBOL programs are naturally reentrant?

 

[ciczman]

Yuriyking,
It's been determined that inconsistencies can pop-up if you don't. It all depends on your code (logic). You don't have to compile with RENT, but if you experience problems. Remeber to try this change (compile w/ RENT).

 

[yuriyking]

2 ciczman

What means then IBM's statement:
“Multithreading requires that all CICS application programs be reentrant; that is, they must be serially reusable between entry and exit points. CICS APPLICATION PROGRAMS USING THE EXEC CICS INTERFACE OBEY THIS RULE AUTOMATICALLY. For COBOL, C, and C++ programs, reentrancy is ensured by a fresh copy of working storage being obtained each time the program is invoked.”

I understand it that I can compile COBOL program without RENT, if it uses EXEC CICS INTERFACE it will be anyway quasi-reentrant.

 

[stevexff]

yuriyking

In response to your original post:

WORKING-STORAGE is analogous to the static storage in C
LOCAL-STORAGE is equivalent to automatic storage in C or PL1

Local storage is really only used if you are coding a recursive program, for obvious reasons.

Historically, COBOL is a batch tool, where concurrency issues don't occur. Everything happens in your address space, in your copy of the program.
For non-reentrant programs, the working storage is actually in the module. For reentrant ones, a chunk of storage is GETMAINed and the WS is copied to it at run time.

CICS subverts this, so that at the start of each task the program's working storage gets copied to task-local storage, providing a kind of pseudo-reentrancy even if the program is compiled NORENT.

This only works for high level languages (unless your assembler modules are LE/370 compliant), and provides the concurrency needed by CICS while only requiring one copy of the executable to be loaded in memory.

So yes, you can safely modify your working storage between CICS calls, because it is your copy.

However, if you call another sub-module in the same enclave more than once from your main program, the working storage of the sub-module won't be refreshed to its initial values on subsequent calls. This can cause some interesting effects if you aren't expecting it. But you can make use of this if your sub-module needs to keep track of its state in WS between calls.
You can get around this by using LOCAL-STORAGE, but there is an overhead involved in GETMAINing the automatic storage and initialising it on each call, which could be significant on a busy system.

There is no cost in compiling your programs RENT (it's not as if you actually have to code for reentrancy yourself) so there really isn't any valid reason not to.



Steve

 

[yuriyking]

Hi Steve.
Thanks for your answer.
You wrote
"CICS subverts this, so that at the start of each task the program's working storage gets copied to task-local storage, providing a kind of pseudo-reentrancy even if the program is compiled NORENT."

I tested it with C. I wrote and compiled some non-reentrant program with static storage and started it from two terminals concurrent.
And I could see on one terminal the static storage modified by task started from another terminal.
So, in case of C, I don't believe that

"For COBOL, C, and C++ programs, reentrancy is ensured by a fresh copy of working storage being obtained each time the program is invoked."

Does CICS provide the copy of working storage for COBOL programs only?

 

[yuriyking]

In my last post I meant

So, in case of C, I don't believe that
"CICS subverts this, so that at the start of each task the program's working storage gets copied to task-local storage, providing a kind of pseudo-reentrancy even if the program is compiled NORENT."

Does CICS provide the copy of working storage for COBOL programs only?

 

[stevexff]

yuriyking

Had a look at the documentation, but there doesn't seem to be a definitive answer. You don't say which C compiler you are using (IBM, SAS-C, etc.) and this might make a difference.

The CICS support for C has a few quirks and this might be one of them. All the examples I've seen have the RENT option set on the compiler, and even the sample translate/compile/link deck on *.SDFHPROC supplied by IBM has RENT set.

Empirical evidence would suggest that you should use RENT, and then you shouldn't have to worry about concurrent usage and reentrancy problems.

Steve