Page 1 of 1
Killing a CICS transaction.
Posted: Sun Apr 01, 2018 4:58 pm
by Mainframe Bear
Hi,
How can we kill a CICS transaction? In case the transaction stuck. may be in a loop or for some other reason then how do you kill that transaction?
Or can we kill the associated task too?
I did not know the answer, as we always approached support group and never it our own.
Re: Killing a CICS transaction.
Posted: Sun Apr 01, 2018 6:18 pm
by Robert Sample
The best, and easiest, way is to use the system monitoring tool (OMEGAMON, MAINVIEW are the main examples) to identify and kill the program. Without one of them, you would have to use CEMT to identify which transaction is the problem and remove it. There are actually three possible looping cases:
1. transaction is executing CICS commands but not doing RETURN TRANSID. This allows you to kill that transaction.
2. transaction is executing CICS commands including RETURN TRANSID. This will be very difficult to kill since the transaction id is constantly changing.
3. transaction is looping without executing CICS commands (also known as a hard loop). Generally without a system monitor the only resolution for this type of loop is to bounce the CICS region.
Re: Killing a CICS transaction.
Posted: Mon Apr 02, 2018 11:23 pm
by Mainframe Bear
Thank you so much Robert Sample.
For point if we kill all the transactions in question, can that work?
Re: Killing a CICS transaction.
Posted: Tue Apr 03, 2018 12:06 am
by Robert Sample
If you can disable the transaction in question, then it won't be able to do a START (or RETURN) TRANSID and that'll stop the looping. How do you propose to "kill all the transactions in question"? The task number will be constantly changing if a new TRANSID is started via the RETURN (or START).
Re: Killing a CICS transaction.
Posted: Wed Apr 04, 2018 11:43 am
by Mainframe Bear
But will not there be a single 'master task' for the entire unit of work?
Re: Killing a CICS transaction.
Posted: Wed Apr 04, 2018 5:17 pm
by Robert Sample
But will not there be a single 'master task' for the entire unit of work?
No, there will not. With pseudo-conversational coding, you issue RETURN TRANSID when the program is ready for user input -- which ends the current task and starts a new task with a new task number. I suspect you are confused about "logical unit of work" -- which is a way of identifying when to use SYNCPOINT / ROLLBACK for coordinated updates.
Re: Killing a CICS transaction.
Posted: Thu Apr 05, 2018 8:55 am
by Mainframe Bear
oh then how would a programmer know for how long a 'unit of work' is going to work?
Re: Killing a CICS transaction.
Posted: Thu Apr 05, 2018 5:17 pm
by Robert Sample
From
https://www.ibm.com/support/knowledgece ... vices.html :
If an individual task fails, backout is performed automatically by CICS®. If the CICS system fails, backout is performed as part of the auto start process.
However, for long-running programs, it might not be desirable to have a large number of changes, which have accumulated over a period of time, exposed to the possibility of backout if a task or the system fails. You can avoid this possibility by using the EXEC CICS SYNCPOINT command to split the program into logically separate sections that are called logical units of work (LUWs); the end of an LUW is called a synchronization point (syncpoint).
If failure occurs after a syncpoint but before the task has been completed, only changes that were made after the syncpoint are backed out.
LUWs should be entirely logically independent, not merely with regard to protected resources, but also with regard to execution flow. Typically, an LUW comprises a complete conversational operation bounded by EXEC CICS SEND and EXEC CICS RECEIVE commands. A BROWSE is another example of an LUW. An EXEC CICS ENDBR command must therefore precede the syncpoint.
Hence, a programmer will NOT know "for how long a 'unit of work' is going to work" -- the programmer inserts the EXEC CICS SYNCPOINT where it makes sense to the application. Sometimes this is determined by the update count -- every 10 / 100 / 1000 updates the SYNCPOINT is issued; sometimes other factors are used to determine when the SYNCPOINT is issued.
Re: Killing a CICS transaction.
Posted: Fri Apr 06, 2018 11:16 am
by Mainframe Bear
Thanks. Can I compare the SYNCPOINT with Checkpoint restart in batch? And that's the reason we don't have checkpoint restart in CICS?
Re: Killing a CICS transaction.
Posted: Fri Apr 06, 2018 2:05 pm
by nicc
They are synonyms.
Re: Killing a CICS transaction.
Posted: Fri Apr 06, 2018 2:31 pm
by enrico-sorichetti
SYNCPOINT is a synonym of CHECKPOINT
any idiot can SYNCPOINT/CHECKPOINT
( it just takes a &couple of calls)
RESTART is a completely different can of worms
it need to be carefully planned and at the end it will considerably
change also the SYNCPOINT/CHECKPOINT process
( a quick and dirty example
You have some items and running totals IN STORAGE/MEMORY ONLY - nothing wrong with it
issuing the SYNCPOINT/CHECKPOINT calls will take care of the database things
but, what about the IN STORAGE/MEMORY ONLY data
how will they be resync when restarting )
the above applies mostly to batch processing
but there are cases where it applies also to CICS transactions
BTDTGTTS
meditate please, meditate