IMS abend 0849

guruji · New User Joined: 13 Apr 2007 Posts: 59 Location: Chennai

Hi,

When I searched for the reason for IMS abend 0849, it's found that an illegal datashare of a database can cause this abend. Can someone throw some light on this?

The databases which face this issue are part of an application which has a control database. So if there is any illegal access in this particular database, will that cause abend in all the related database?

Thanks for your help,

Reni.

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

My manual says this is a pseudoabend... did you look up the original abend code?

guruji · New User Joined: 13 Apr 2007 Posts: 59 Location: Chennai

Hi,

I've read the manual and saw that it's a pseudo abend. But we are getting this when we try to acces the databases through IMS Filemanager. Though checked in IMS Logs, original abend could not be found.

Anyone has faced any such issues before?

Thanks,
Reni.

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

From the IBM manual about processing options ( the PROCOPT in the PSB)
O
If the O option is used for a PCB, IMS does not check the ownership of the segments returned. Therefore, the read without integrity program might get a segment that has been updated by another program. If the updating program abends and backs out, the read without integrity program will have a segment that does not exist in the database and never did. If a segment has been deleted and another segment of the same type has been inserted in the same location, the segment data, and all subsequent data returned to the application, can be from a different database record. Therefore, if you use the O option, do not update based on data read with that option. O must be specified as GO, GON, GONP, GOT, GOTP, or GOP only.

IMS recognizes some of these error types and converts them to abend U0849. However, other conditions that occur under PROCOPT GOx are not detected as having been caused by the read-without-integrity. It is possible to get loops, hangs, and system abends. When using this PROCOPT, carefully consider system design to determine if concurrent update activity is likely to cause higher risk of these kinds of conditions.

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

If you look at the description of U0849, it tells you how to find the original abend, and it's NOT in the logs.

guruji · New User Joined: 13 Apr 2007 Posts: 59 Location: Chennai

Hi,

I've changed my PCB such that the PROCOPT is NOT 'GO' now and tried to access the DB. But whichever procopt I give (e.g., A, G, GR, GIRD, GPR), the Filemanager is issuing the error ' IMS call to free current database record lock failed RC 0 status code AD' .

As AD points to incorrect function code, it sounds like non other than GOx suits here. Anyone has any idea?

Thanks,
Reni.

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

Hmmm... Are you using an existing PSB? Are you sure you are selecting the correct PCB within it?

Also, you seem to have divined an odd explanation again from the error message. AD does not point to an incorrect function code. It's saying that the function code is inappropriate for the PCB being used. That's a world of difference.

I would try letting FileManager build the PSB dynamically and see if that helps.

I am suspicious that you are working with a different PCB than you think you are. You know that if you include a "COMPAT=YES" in a PSB that it adds an extra PCB up front? If you use a DB call against that PCB, you would get an AD error.

Anuj Dhawan · Posted: Wed Feb 29, 2012 4:11 pm