|
View previous topic :: View next topic
|
| Author |
Message |
ashek15
New User
Joined: 20 Oct 2015
Posts: 48
Location: USA
|
|
|
|
Hi All
I need some info on command 'STOP REGION XX ABDUMP'. We had a situation where below happened
1)User issued a CICS conversational transaction to query IMS back-end.
2) He left his screen as it for 3-4 hours
3) Meanwhile transaction held many IMS DBs and was hanging
4) Later by IMS automation 'STOP REGION XX ABDUMP' was issued but there was no response by IMS
5) After some time IMS DBs were DBRed (by automation) as part of routine work which seems to worsen situation as DBs were stopped now
6) CICS Transaction still held resources
7) Later 'STOP REGION XX CANCEL was issued but this also did not free up the resources
8) Finaly, IMS had to be recycled to release the resources
Please note above mentioned automation was established by DBAs long back but 'STOP REGION' command never gave any issue with any other CICS transaction in past.
Please advise whose is at fault here a) Application programmer b) DBA or c) IMS SYSTEM programmer and why? |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
Is it really down to a forum and its members to determine guilt ?
Surely the plan forward is to determine how to stop the same problem arising in the future rather than pointing fingers at others |
|
| Back to top |
|
|
ashek15
New User
Joined: 20 Oct 2015
Posts: 48
Location: USA
|
|
|
|
| No. but we in order for us to prevent any such future occurrence, we need to know the areas of improvement..am sorry, I did not mean to say guilt..but who should start fixing things here..I guess it's app team who need to rewrite cics transaction code to make it more controlled to avoid similar situation..pls advise |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Quote: |
1)User issued a CICS conversational transaction to query IMS back-end.
2) He left his screen as it for 3-4 hours |
How can it be a conversational then when there is no RETURN issued with TRANSID while waiting for users response and holding the resources?
Its a program bug and that needs to be fixed. |
|
| Back to top |
|
|
ashek15
New User
Joined: 20 Oct 2015
Posts: 48
Location: USA
|
|
|
|
| User mentioned that his screen was frozen and he thought it is some VPN or network issue and he left thinking nothing would be impacted. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
Why the screen got locked? Did anyone investigated ? It is because of the same transaction which held up resources or something else could have happened to DB by any process?
But regardless it should have been handled in program if DB busy then error out and also it should RETURN with TRANID when its idle. was there any other reason apart from this? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
How can it be a conversational then when there is no RETURN issued with TRANSID while waiting for users response and holding the resources?
|
lets look at the thing form the CICS point of view ...
the normal terminology is ...
PSEUDO CONVERSATIONAL return transid
to the end usr it looks like a single task
for CICS it is a sequence of tasks
CONVERSATIONAL write/read ( or converse )
to the end user - the same as above
for CICS ONE task , which implies all the locks and enqueues living for a loong time
it is a bad design, but if the update patterns are convoluted it will make the backout easier in case of error |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| That's right, PSEUDO CONVERSATIONAL is the right terminology to be used. But I guess since RETRUN with TRANSID is missed at some place(s) which Enqued the whole task with DB hold up or there might be a looping problem. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| But I guess since RETRUN with TRANSID is missed at some place(s) |
the return transid is missing because the application was designed that way ... CONVERSATIONAL
and those suffering from locks/enqueues would be the other tasks not the running one
if somebody else had a lock/enqueue outstanding it would not make any difference for the victims( CONVERSATIONAL vs. PSEUDO ...) |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
Any CICS program shouldn’t be coded conventional way , right If so then that’s first place to fix the program.
If ENQ at all used by TS then ENQ model should generally be defined in such a way that not more than one task allowed to be in waiting state unless it’s CICSPlex environment and others should kicked out by enqbusy condition.
If first task is locked the resources by flaw in program logic then it needs to be fixed anyways.
One other possibility I would think of is , if the IMS query is taking more time than usual then check if there is any timeout defined by DBA else CICS Will wait for the query response till either one give up. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| Any CICS program shouldn’t be coded conventional way , right If so then that’s first place to fix the program. |
again the problem is not to fix the program ...
if the application has been designed that way, the whole design must be reviewed and the program REWRITTEN(NOT FIXED) accordingly
if a program relies on having all the data and the info to be passed at each terminal interaction in working storage fixing the program is not just adding a return transid, |
|
| Back to top |
|
|
ashek15
New User
Joined: 20 Oct 2015
Posts: 48
Location: USA
|
|
|
|
Hi Everyone
Thanks a lot for your valuable inputs.
Regards |
|
| Back to top |
|
|
|
|
