APAR status
Closed as program error.
Error description
Customer using a PROCOPT=H PCB issues issues a CHKPT call while positioned in the middle of a UOW (i.e. before receiving 'GC' status). In this case syncpoint was issued due to 'FW' status code. A GHU call was then issued to reposition the HSSP PCB since position is lost unless the syncpoint was issued due to 'GC' status. The GHU positioned the PCB to the last root in the UOW. A GN call was then issued, and customer expected to receive status 'GC' since a UOW boundary was crossed but received instead a blank status code. The problem here is that ECPBFLGM,EPCBFLMS is within the EPCB position information cleared at syncpoint by DBFSHDQ0. The GHU call will not set it - it's normally set on a move forward - and hence the next GN call when it detects crossing of a UOW boundary and calls DBFPGAP0, still fails to return 'GC' status. DBFPGAP0 finds the read-ahead UXRB unreferenced and EPCBFLMS not set, so skips the setting of the flags needed to return a GC status code. This apar will also add servicability traces when an HSSP PCB is repositioned backwards rather than to the next UOW, so that the reason (which may be valid) can be determined from the IMS log.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: IMSFP R910 DEDB PROCOPT=H users. * **************************************************************** * PROBLEM DESCRIPTION: NO STATUSGC GCSTAT STATGC RECEIVED * * WHEN CROSSING A UOW BOUNDARY AFTER A * * PRIOR SYNCPOINT TAKEN BEFORE 'GC' * * AND GU TO REPOSITION. * **************************************************************** * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** This service corrects a problem when customer using PROCOPT=H PCB issues a CHKPT call while positioned in the middle of a UOW. In this case syncpoint was issued due to 'FW' status code. A GHU call was then issued to reposition the HSSP PCB since position is lost unless the syncpoint was issued due to 'GC' status. The GHU positioned the PCB to the last root in the UOW. A GN call was then issued, and customer expected to receive status 'GC' since a UOW boundary was crossed but received instead a blank status code. The problem was due to flag EPCBFLMS in field ECPBFLGM being cleared at syncpoint by DBFSHDQ0. The GHU call will not set it - it's normally set on a move forward - and hence the next GN call when it detects crossing of a UOW boundary and calls DBFPGAP0, still fails to return 'GC' status. DBFPGAP0 finds the read-ahead UXRB unreferenced and EPCBFLMS not set, so it skips the setting of the flags needed to return a GC status code. This service will also add serviceability traces in log record type6707 when an HSSP PCB is repositioned backwards rather than to the next UOW, so that the reason can be determined from the IMS log.
Problem conclusion
AIDS: RIDS/FP RIDS/DEDB FP DEDB DEP: NONE GEN: *** END IMS KEYWORDS *** The following changes have been made: DBFSHDQ0: Add code to not clear the current DB DL/I position EPCBBPOS for procopt H. When a UOW position is being restored for a PROCOPT=H EPCB, the control blocks EPST, EPCB, and SPCB will be saved in type6707 log record for diagnostic purpose. ILOGREC: Add log record type6707. DFSL6701: Add subtype X'07' for log record type 67. ---------------------------------------------------------------- DOCUMENTATION CHANGE FOR APAR PK11357 LY37-3203-01: IMS VERSION 9 DIAGNOSIS GUIDE AND REFERENCE - THE FOLLOWING TEXT DESCRIBES THE DOC CHANGE: - TABLE 8. IMS LOG RECORDS USED TO ANALYZE IMS PROBLEMS +--------------------------------------------------------------+ | Type Mapping Macro Dsect Why Written (Issuing Module) | +--------------------------------------------------------------+ |x'67' DFSL6701 CTREC X'07' A HSSP PCB is reposition| | backward rather than to the | | next UOW. The control blocks | | EPST, EPCB, and SPCB will be | | snapped in this log record for| | diagnostic purpose. (DBFSHDQ0)| +--------------------------------------------------------------+
Temporary fix
Comments
APAR Information
APAR number
PK11357
Reported component name
IMS V9
Reported component ID
5655J3800
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
YesSpecatt / Serviceability / Xsystem
Submitted date
2005-09-01
Closed date
2006-09-14
Last modified date
2007-02-13
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK18003
Modules/Macros
DBFSHDQ0 DFSL6701 ILOGREC
| LY37320301 |
Fix information
Fixed component name
IMS V9
Fixed component ID
5655J3800
Applicable component levels
R900 PSY UK18003
UP06/09/22 P F609
[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCVRBJ","label":"System Services"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
13 February 2007