A fix is available
APAR status
Closed as program error.
Error description
Running a DDLT0 BMP and using a PROCOPT=A PSB, do a GHU and DLET to the LAST root segment in a PHIDAM partition. Then put the job into a hold by placing a DFSDDLT0 WTOR control card immediately after the DLET. Run a second DDLT0 BMP on the same system using the same PSB and issue a qualified GHU against the same root segment which has just been deleted (but not yet committed) by the first BMP. The second job completes with RC=0 returning a 'GE' status for the GHU call. This is wrong since the job should have been held on an IRLM lock until the first DLET job has completed.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All IMS V12 HALDB PHIDAM users. * **************************************************************** * PROBLEM DESCRIPTION: Potential data integrity issue when * * the last root segment in a HALDB * * partition is deleted. * **************************************************************** * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** When multiple dependent regions are accessing the same HALDB PHIDAM database, if dependent region 1 deletes the last root segment in the partition, but does not immediately commit the update, if a second dependent region issues a GET call to retrieve the root that was just deleted, the second dependent region will receive a GE status ( STATUSGE ) even though dependent region 1 has not committed the delete. If dependent region 1 then fails and has to do backout, the STATUSGE returned to dependent region 2 is invalid. Because the root segment deleted by dependent region 1 was the last root in the partition, dependent region 2 does not ENQ on the next higher key, which would be the X'FF's key, allowing dependent region 2 to not wait until the commit of dependent region 1, returning the STATUSGE immediately and potentially causing a data integrity issue.
Problem conclusion
GEN: POSTREQ PM81487 KEYWORDS: *** END IMS KEYWORDS *** The following module and macro have been modified to correct the reported problem: ********** * DFSJCB * ********** New flag JCBLKAFF has been added in flag byte JCBR3 to indicate that a lock on the X'FF's key is needed to assure data integrity. ************ * DFSDLR00 * ************ Code has been added in the BYKEY routine, after label KEYEND50, when a segment NOTFOUND condition is detected to determine if a lock on the X'FF's key is required. If the lock is needed, flag JCBLKAFF is set and a branch to label BYKEY2 is done to ENQ on the X'FF's key to protect the integrity of the database.
Temporary fix
********* * HIPER * *********
Comments
REPINNED RP13/01/30 (ATXT) TO ADD POSTREQ PM81487 INFO. **** PE13/01/30 PTF IN ERROR. SEE APAR PM81487 FOR DESCRIPTION ×**** PE13/01/30 FIX IN ERROR. SEE APAR PM81487 FOR DESCRIPTION
APAR Information
APAR number
PM53588
Reported component name
IMS V12
Reported component ID
5635A0300
Reported release
200
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2011-12-05
Closed date
2012-10-20
Last modified date
2013-03-29
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK82803 UK82804
Modules/Macros
DFSDLR00 DFSJCB
Fix information
Fixed component name
IMS V12
Fixed component ID
5635A0300
Applicable component levels
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