I'm trying to initiate a CICS transaction from a JCL. I use the IPCPBTCH utility and the 'init KC' command. Can this be used?. The transaction by itself has to restart after reading 10 records. Now the problem is, it restarts only 3 or 4 times. I've used a "CICS START" command with TRANSID option. Is there any restrictions on this, namely restart can occur only twice or thrice?. When I use a "CICS Return" with a transid option the transaction executes fine in CICS terminal, but fails when initiated through the JCL.
Please help me with this case.
There is no CICS restriction about the number of times a transaction instance can restart itself - there is nothing to stop multiple instances of the same non-terminal transaction running concurrently.
If you only want to be able to initiate activity within CICS from JCL, have a look at one of my SupportPacs (via the CICS Web Site) that permits a program to be invoked within a CICS region from JCL (or even a MVS Pipe!)
Having written this utility (which uses EXCI to talk to CICS) I'd be a little surprised if you initiate a transaction via this vendor utility and then initiate another non-terminal background transaction and expect to get output back from this 2nd non-terminal transaction. No doubt there is some interesting code involved.
It also occurs to me that as the program you are invoking ends with XC RETURN TRANID(x) this is not the way to get the next transaction running when not at a terminal. This option only works for pseudo-conversational actiity at a terminal (real or Bridge emulated). You have got to get the next transaction in the sequence going via an XC START TRANID(x).
The other thing you should investigate, via Trace, is why you only get the 3/4 reinitiations. Is there some sort of Abend Code, or Exception Trace generated? Or does the initiation command succeed but the task itself never get going? Is there any interference due to TCLASS issues or MAXTASK effects? Any interesting messages around? Is the routing exit interfering this things?
Is there any good reason for limiting the transaction to processing 10 things? I'd be rather inclined to have a design which did one thing at a time or everything in one go.
This was first published in September 2002