Clarification on GHU call

kratos86 · Posted: Thu Aug 25, 2011 7:18 pm

Hello,

I have a query on the control GHU is obtaining on the segment. If i have a program A and program B, where both accessing the same database. When program A access the database with a GHU call without a need to replace/delete the segment. At the same time if program B tries to access the same segment by issuing a GHU call. Both the PSB are having the procopt options as GOT.

What will happen?. Will it abend/both the program can issue GHU to a segment at the same time?

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Since the procopt allowing only read access, both programs can read at the same time.

Even if program C has the segment held for an update, both A and B can read it.

If program C then later rolls back the update, A and B will NOT know it and will have the updated segment. (That's the "O").

kratos86 · Posted: Fri Aug 26, 2011 8:14 am

Thanks for the timely reply Ed.

kratos86 · Posted: Fri Aug 26, 2011 3:23 pm

I have one more question, If the procopt option of program A is A and it access the segment with a GHU call without the intention to update/delete. If the program B with procopt - GOT tries to access the same segment, will the call fail with GG return code.

I got a scenario where my job failed with GG return code and analysing the issue we got to know that a job with PROCOPT- A was accessing the same database with GHU calls without any replace/delete function.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Yes...that will cause a GG.

Program A does a get-hold, then Program B tries to read. Since the procopt has the "T" in it, Program B tries a second time after some short interval. When the second call is denied, it gets a GG back from IMS.

The easy fix is to change program A to use GU instead of GHU. Another fix would be to have Program B try several times if it gets a GG.

It's weird to get what your getting though. If program A really hasn't updated anything, the hold should be released as soon as the next call moves off of that segment. I would normally expect an actual update to cause a GG, that's why we try and perform checkpoints frequently during update programs.

I guess I'm telling you that Program A may actually be updating the database, even if you've been told that it doesn't. Either that, or it's reading a segment and sitting on it for a long time.