A fix is available
APAR status
Closed as program error.
Error description
IMS program is using FP DEDB PCB with PROCOPT=GOT or GON. IMS returns statuscode=GG to program when an invalid segment code is found at buffer RBA on "get" call (Gx, GU, GN, GNP..). This indicates that application is doing "dirty" reads (reading data without integrity) and another application has modified DEDB database pointer(s) with "update(s)" but has not committed/backed-out those changes yet. The "read-only" application reissues Gx call which usually results in statuscodeGG again. "GO" buffers are allocated for GO application processing. These buffers are not always refreshed so a re-read of same data will likely return GG status again. This change will "stage" a refresh of DB buffer when GG statuscode is returned to application so that a Gx DLI call from this application for the same data will get a refreshed buffer, increasing the likelihood that buffer will contain valid data/segment code.
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: * * IMSFP V14 DEDB PROCOPT GO/GON/GOT USERS. * **************************************************************** * PROBLEM DESCRIPTION: * * IMS - PROCOPT GON/GOT PROGRAM CODED TO REISSUE Gx CALL * * AGAINST DEDB FOLLOWING GG STATUS CODE USUALLY RESULTS IN GG * * AGAIN. * **************************************************************** * RECOMMENDATION: * * INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** IMS program is using FP DEDB PCB with PROCOPT=GOT or GON. IMS returns status code=GG to program when an invalid segment code is found at buffer RBA on "get" call (Gx, GU, GN, GNP..) This indicates that application is doing "dirty" reads (reading data without integrity) and another application has modified DEDB database pointer(s) with "update(s)" but has not committed/backed-out those changes yet. The "read-only" application reissues Gx call which usually results in status code GG again. "GO" buffers are allocated for GO application processing. These buffers are not always refreshed so a re-read of same data will likely return GG status again. This change will "stage" a refresh of DB buffer when GG status code is returned to application so that a Gx DLI call from this application for the same data will get a refreshed buffer, increasing the likelihood that buffer will contain valid data/segment code.
Problem conclusion
The following change has been made to correct the reported problem: DBFIRC10: Check if receive status code GG ( GGSTAT STATGG ), go through the GO buffer DMHRset and set maximum access count to force a refresh of data in these buffers on the next DLI get call.
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI94191
Reported component name
IMS V14
Reported component ID
5635A0500
Reported release
400
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-02-22
Closed date
2018-03-08
Last modified date
2018-04-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI54344
Modules/Macros
DBFIRC10
Fix information
Fixed component name
IMS V14
Fixed component ID
5635A0500
Applicable component levels
R400 PSY UI54344
UP18/03/13 P F803
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":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPH2","label":"IMS"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"14.1","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
01 December 2023