A fix is available
APAR status
Closed as program error.
Error description
Various abends occur during ISRT/DLET processing by multiple PST's against a single database. Error is timing dependent, and orginal submitter uses database as a scratchpad, thus heavy ISRT followed by almost immediate DLET. Database size is therefore very small, and most ISRT activity involves updating PTB from zero (bottom end of chain). Occured on root only db, but may be possible if child segments are present. Other abends include U0850 and U0808 as a result of "orphaned" roots (PTF and PTB pointers not updated), and invalid FSE's Some errors are found as a result of an index access (in HIDAM) that references orphaned segments, whose PTF or PTB are not maintained.
Local fix
The data is not lost, but can be overlooked when PTF or PTB ptrs are used. Unloading via the index will return those segments to the input file for reload.
Problem summary
**************************************************************** * USERS AFFECTED: All IMS V12 users of HIDAM databases with * * POINTER=TB (Twin Backward) specified at the * * root segment level and multiple dependent * * regions issuing concurrent inserts ( ISRT ) * * and deletes ( DLET ). * **************************************************************** * PROBLEM DESCRIPTION: ABENDU0808 or ABENDU0811 of a dependent * * region during a delete call of a HIDAM * * root segment when multiple dependent * * regions are issuing concurrent insert * * calls against a HIDAM root segment. * **************************************************************** * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** An ABENDU0808 or ABENDU0811 occurs when a dependent region is deleting a HIDAM root segment while multiple dependent regions are issuing concurrent insert calls against a HIDAM root segment. The U0808 and U0811 occur due to corrupt physical twin backward ( PTB ) and physical twin forward ( PTF ) pointers in the segment prefix. The corrupt pointers occur when a specific series of events take place that includes 3 dependent regions doing inserts ( ISRT ) and 1 dependent region doing deletes ( DLET ). The following table describes the scenario in sequence of events that leads to the abend. PST DLI CALL KEY VALUE HIDAM RBA POINTER (HEX) --- -------- --------- --------- ----------------- x'FF' x'2004' PTF=0 PTB=0 1 ISRT F x'2716' PTF=2004 PTB=0000 1 ISRT G x'3004' PTF=2004 PTB=2716 2 ISRT A x'35E6' PTF=2716 PTB=0000 3 DLET F x'2716' PTF=3004 PTB=35E6 3 DLET G x'3004' PTF=2004 PTB=35E6 1 ISRT E x'3004' PTF=2004 PTB=35E6 2 ISRT C x'6004' PTF=3004 PTB=35E6 2 ISRT D x'651E' PTF=3004 PTB=6004 4 ISRT B x'2716' PTF=3004 PTB=35E6 During insert processing PSTs 1, 2, and 4 call DFSDLR00 to set position in the database for insert. PST 1 and PST 4 issue a retrieve by key PSTSTLEQ x'F2' call via routine ROOTISRT. PST 2 issues a retrieve by key call via routine ISRTCHCK after label RISRTB20. Routine ISRTCHCK path is taken due to inserting keys C and D between existing keys A and E. Routine ISRTCHCK calls BYKEY by first calling SETL routine. Within SETL, DOBYKEYI routine is called to process retrieve by key x'F2' call. Within DOBYKEYI routine BYKEY is called after label NODEQ67. PSTs 1, 2, and 4 wait behind PST 3 since the delete call for keys F and G own the GRIDX root lock on HIDAM RBA x'3004'. When PST 3 releases the lock on RBA x'3004' PSTs 1, 2, and 4 are posted from waiting and a second attempt is made to obtain RBA x'3004' by issuing PSTSTLEQ x'F2'call after label DIDWAITA. PST 1 is the first PST to issue a second x'F2' call for X'3004'. The byte locate cannot find the requested record but instead finds the all foxes x'FF' key and gets an error return code PSTNOTFD x'18' from buffer handler. Since PST 1 issued a retrieve by key PSTSTLEQ x'F2' call via routine ROOTISRT flag JCBRI in byte JCBR2 is set after label RISRTB70 prior to calling SETL routine. From SETL routine, IBYTE routine is called and code after label BYKEY2 is issued to get a lock on the x'FF' key and then insert keys F and G. Next, PST 2 is posted from waiting on the lock for RBA x'3004' and like PST 1 a second x'F2' call for RBA X'3004' is issued. The byte locate call cannot find the requested record but instead finds the all foxes key ( x'FF' ) and gets an error return code PSTNOTFD x'18' from buffer handler. Since PST 2 issues a x'F2' call via routine ISRTCHCK, flag JCBRI is not set and code path to label NOENQ41 is taken from label KEYEND50. As a result of branching to label NOENQ41 a reread of RBA x'3004' is skipped. When branching to label NOENQ41 flag JCBREPET in byte JCBR1 is not reset. When returning to routine ISRTCHCK after label RISRTB20 a return code 4 is returned. A RC=4 issued from routine ISRTCHCK indicates insert position could not be established between the two existing keys in DSGLRKEY. Since position is not established another byte locate x'F2' call will be issued in routine BYKEY via a SETL call via function IOROTEQ ( retrieve key equal to or greater than call ) after label RISRTB70. When BYKEY issues the x'F2' call for RBA x'3004' it retrieves a new key value, key B, that is lower than the key value being inserted which is key C. After a buffer handler call at label BYKEYB the code path is taken to label DOENQ10 where flag JCBREPET is checked. Since JCBREPET flag is set a branch to label SECTIME is taken. After label SECTIMEA both key E and key G have the same RBA at x'3004' so a branch is taken to label NOENQ41. This code path causes a lock request for RBA x'3004' to be skipped and instead a lock request is issued for RBA x'35E6'. As a result PST 2 waits on a lock request for RBA x'35E6'. PST 4 now gets control and issues a second x'F2' call for X'3004' and successfully inserts key B. The table above shows the final result of the corrupt physical twin backward and foward pointers. RBA x'651E' has a physical twin forward pointer to RBA x'3004' but no physical twin backward. RBA x'2716' is inserted after RBA x'6004' and after RBA x'651E' but points past them to RBA x'3004'. The physical twin backward for RBA x'6004 is at RBA x'35E6. Once PST 4 obtains locks for RBA x'3004' and x'35E6' it still has an existing view of the index that shows x'3004' is the next higher key instead of RBA x'6004' that had been inserted by PST 1. When PST 3 issues a delete for RBA x'35E6', the corrupt physical twin backward and physical twin forward pointers cause PST 3 to abend with a U0808. Additional Keywords: ABENDU0777 SEGM PTR=TB PTR=TWINBWD
Problem conclusion
GEN: KEYWORDS: *** END IMS KEYWORDS *** ************ * DFSDLR00 * ************ Code is added in module DFSDLR00 after label NOENQ41 to reset flag JCBREPET in byte JCBR1.
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI46481
Reported component name
IMS V12
Reported component ID
5635A0300
Reported release
201
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-08-06
Closed date
2015-08-24
Last modified date
2015-10-02
APAR is sysrouted FROM one or more of the following:
PI44679
APAR is sysrouted TO one or more of the following:
UI30481
Modules/Macros
DFSDLR00
Fix information
Fixed component name
IMS V12
Fixed component ID
5635A0300
Applicable component levels
R201 PSY UI30481
UP15/09/02 P F509 Ž
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Platform":[{"code":"PF054","label":"z Systems"}],"Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
14 December 2020