IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Query regarding STOP REGION XX ABDUMP command


IBM Mainframe Forums -> IMS DB/DC
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
ashek15

New User


Joined: 20 Oct 2015
Posts: 48
Location: USA

PostPosted: Fri Oct 19, 2018 10:13 am
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Fri Oct 19, 2018 11:28 am
Reply with quote

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
View user's profile Send private message
ashek15

New User


Joined: 20 Oct 2015
Posts: 48
Location: USA

PostPosted: Fri Oct 19, 2018 7:03 pm
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Fri Oct 19, 2018 11:29 pm
Reply with quote

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
View user's profile Send private message
ashek15

New User


Joined: 20 Oct 2015
Posts: 48
Location: USA

PostPosted: Sat Oct 20, 2018 1:39 am
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Sat Oct 20, 2018 2:03 am
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Sat Oct 20, 2018 2:30 am
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Sat Oct 20, 2018 2:32 am
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Sat Oct 20, 2018 3:02 am
Reply with quote

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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Sat Oct 20, 2018 3:48 am
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Sat Oct 20, 2018 4:17 am
Reply with quote

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
View user's profile Send private message
ashek15

New User


Joined: 20 Oct 2015
Posts: 48
Location: USA

PostPosted: Wed Oct 24, 2018 4:26 am
Reply with quote

Hi Everyone

Thanks a lot for your valuable inputs.

Regards
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> IMS DB/DC

 


Similar Topics
Topic Forum Replies
No new posts Routing command Address SDSF to other... TSO/ISPF 2
No new posts DTL - how to define key with stacked ... TSO/ISPF 3
No new posts LTJ command CA Products 4
No new posts RC query -Time column CA Products 3
No new posts How to 'Ping' a CICS region in JCL CICS 2
Search our Forums:

Back to Top