In CICS pgm how to clear WS space when transaction is active?

[8101]

Dear all,

Can I free the working storage space occupied by the CICS program when the transaction is in active state itself.

The background is

From CICS program I am reading messages from queue manager (in MQ server)and once all message r processed, the program goes to sleep state. again when the message come to queue the program 'wakes up' and process the messages.

the CICS program (which is active, whether in sleep/wake mode) allocates WS area space every time it's executed(invoked) and storage space gets acculumated and poses storage problem to us.

If I am not clear, kindly ask me. I can detail further
Please suggest or advise some solution / alternatives

thank you in advance, Vinodh

 

[stevexff]

Vinodh

When your program reads the MQ messages, where does it put them? Depends what language the program is written in. For COBOL, if you are putting them in working storage, then it shouldn't make any difference, as you will re-use the same storage with each message. But if you GETMAIN some storage to hold each message, then you should really FREEMAIN it again after the message has been processed.

Also, how does your program shut down? Does it just get killed when CICS closes down?

Steve

 

[8101]

Thanks Steve. Appreciate your quick response on this.

The program (rather transaction) will be shut down in two scenarios - 1. when the program receives a "special message" saying 'STOP THE EXECUTION' or 2. the operator terminates it before bringing the CICS down at the day end.

The program processes the message and go to sleep mode.
When a new message comes to queue, it gets up (wake mode)
and process the message(s) and on completion again goes to sleep mode. (we use Signaling feature). This transaction will be alive until one of the above scenarios happen.

Yes it's a COBOL program and we uses MQ functions like MQOPEN, MQGET, MQPUT, MQCLOSE to deal with the queues.
The messages are read into Working storage (WS size is defined to store 2.5 MB as we anticipate huge message).
We are not using GETMAIN and hence FREEMAIN right now.

Steve, like to confirm my understanding with you. It's that when the program is hit for the first time (by the transaction - which will be in wake/sleep mode all day time)
working storage space will be allocated. For subsequent messages again the transaction hits the same 'live' program - which will use the same space of WORKING STORAGE it has allocated earlier for the first message.

In simple words, the WORKING Storage space allocated for processing 1st message, the "same WS space" space will be used for 2nd, 3rd, 4th... so on messages. am I right?

If this is the case then I wonder why our storage administators report to us that our transaction is acculumating space for each hit/message processing and they advise us to free the storage occupied; i.e., to tune the program to handle the problem. Any futher thoughts on this?

For time being since we are in test region, we terminate the transaction in regular period - which releases or clear all acculumated storage by the program, this can't be afforded when we go live to production (real-time scenario).

Hope I make clear and make sense. Thanks for your valuable help and interest.

If anything not clear or specific, I can detail further.
Appreciate for your time, Thanks again! - Vinodh

 

[stevexff]

If the messages are this big, then (I'm assuming) they don't arrive very often, and your program spends most of its time asleep. Do you take a SYNCPOINT after each message is processed, as this could be the cause of the storage creep?

Another possibility would be to change your design so that MQ triggers CICS to start a transaction when each message arrives, so you don't have to sit around holding 2.5MB of storage in between messages. This is the least resource-hungry method, and you don't have to have a special message to shut it down. It is described fully, with examples, in the application programmer's guide SC34-6062-03.

Steve

 

[8101]

Steve,

The messages can arrive frequently too.
To your query, we have not used any SYNCPOINT as of now.

MQ triggering the CICS transaction, I guess folks here are having some concern. will propose this design option anyway and try to understand why they are not interested, if so.

Thank You very much for the valuable suggestions.
I will post the update once we achieve some milestone.

Latest: Right now we planned to read the message and store in Linkage section (with a pointer from Working storage)
then use GETMAIN to allocate memory - process the message - then use FREEMAIN to release memory. Any remarks on this?

the same will be applied for each new message processing.
mqget - getmain - process - mqput - freemain.
Hope this approach will get rid of the storage problem.

Thanks Steve.

Regards, Vinodh

 

[stevexff]

Vinodh

Suggest you try EXEC CICS SYNCPOINT after you process each message. The storage creep may be caused by CICS holding resources in case it needs to do a backout, like the DTB log for example. See if this fixes the problem.

MQ triggering, I expect they are worried about flooding the system and going short on storage. Put the transaction in a TRANCLASS and set MAXACTIVE to a sensible value.

CICS likes transactions that start, process quickly, and then get out. Then ALL their resources (storage, MQ connections, DB connections, etc. are immediately available for reuse by anyone else in the system.

Latest: don't waste your time. In order to do a MQGET with the WAIT option, you have to pass it the message buffer. Which means you have to GETMAIN the buffer before you go to sleep, which is just as bad as using working storage except you have the (admittedly) small overhead of the GETMAIN/FREEMAIN as well.

Steve