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.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
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.
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.