CICS transaction - Query

shanudarling · New User Joined: 20 Dec 2006 Posts: 55 Location: noida

I have a write a new cics program which will conduct inquiries for bulk customers (around 30-40000 records). For each customer 3 inquiries will be conducted which will also use 3rd party (this means that around 100000 inquiries will be conducted for each run of the program).

I have 2 options for writing the program -
option1 - there will be 1 single transaction which will process all the records

option2 - one transaction will process record for 1 customer and then it will trigger another transaction to process the 2nd customer record, the transaction for the 1st customer will end. This process will continue till all the records are processed.

My question is which approach should be used.

My client has specifically asked me to make sure that this particular transaction should not use all the cics resources and this transaction should not impact functioning of other transactions. It should be efficient.

Binop B · Posted: Fri Apr 06, 2012 12:26 pm

Hi Shanu,

From my personal view, Option 2 is certainly better especially with the huge amount of I/O that is to be expected. The part you need to be careful about is to not initiate too many transactions. Have a CWA field counter or something like that to control to the active transactions.

Use CWA fields to intially run only 5 customer process at a time... Increase it gradually to a point where you feel the performace is good and not taking up a huge amount of the CICS resources.

Peter cobolskolan · Posted: Fri Apr 06, 2012 12:35 pm

Starting many transactions/tasks requires of course mor resources than starting a single one.
My opinion is that you should not produce more output than can be presented on one (1) screen at a time. If the result you produce will need many screens in total, produce the first screen an show it (SEND MAP) and return (RETURN TRANSID()) COMMAREA(). Save enough information in your Commarea so the next task can start where the other ended. If the user requires another screen of information, just produce it and return (RETURN TRANSID()) COMMAREA() again. Every produced screen could be saved (e.g.TS), so you dont have to produce it again if the user wants to browse back.
Eventually the user quits after a couple of screens, and doesnt need all other, not yes produced, screens. This approach saves resources.
If you need to produce all screens/information always, just do it in one task, as there is no locking as long as you just read from your files/tables, and no need to split it into many tasks.
For every read you make from a file, CICS can dispatch other tasks while the I/O is performed, doesnt matter if there are a few or many Reads.

Bill O'Boyle · Posted: Fri Apr 06, 2012 7:21 pm

Any program in the mix that addresses the target CWA field, must use ENQ/DEQ API's, using the same internally-defined RESOURCE name, in order to make the access serial and retain data integrity.

If in the future you migrate to Threadsafe, this would be mandatory, as you would now introduce multiple TCB's (not just a single QR), running concurrent tasks.

dbzTHEdinosauer · Posted: Fri Apr 06, 2012 8:39 pm

have you modeled the process
so that you can at least guess at the probable length of this process?

what feedback are you expected to provide the user?

why can't this be a batch process?
then leave just 3 screens in cics:

1-bulk customer request input
2-bulk customer request status
3-bulk customer request detail

as the batch process finishes, it updates a db2 table, a CICS QUEUE.
items 2 and 3 would access the request status
and either display the stautus (2)
or display the detail (3)

that way few cics resources.

don't tell me, this idiot 3rd party tool is only accessable in CICS.