APAR status
Closed as program error.
Error description
If a subfile that uses block indexing is opened with detac/hold and successfully accesses a non-prime block, then unsuccessfully accesses another non-prime block (e.g. I/O error), DBCLS ABORT results in a CTL-10. The 'last' block is the one with the I/O error and it was released by SERRC processing. UWBE attempts to locate the blocks to be reattached and released using the block index lrecs in the prime block. There are 2 problems, 1) the check for 4 byte FA subfiles is incorrect and should be NE instead of EQ to jump out of the 2nd loop and try a new FA. 2) The setup for UWB5 case 7 uses SW00FAW3 which isn't updated with the newly located FA in the block index lrec. Consequently the same address is retried and results in a CTL10. #DO INF MVC DFP.IDECFA,SW00FAW3 SEARCH ARG FOR ATTAC DFLNK UWB5,7 ATTAC,ACPDB,SW00AL# #DOEX CLI,DFP.IDECCT0 1,NE,1 THEN BLOCK FOUND #GOTO UWBEE03E,IF, # TM,SW00ID6,#BIT0,Z,ORIF, NOT DETAC W/BLKIDX # OC,SW00SKE,SW00SKE,Z,AND, OR NOT BLOCK INDEX # TM,SW00OP3,#BIT5,Z AND NOT B TREE INDEX **************************************************************** *** * ROUTINE TO FIND ENTRY POINT VIA BLOCK INDEX **************************************************************** *** #IF OC,SW00SKE,SW00SKE,NZ BLOCK INDEX? L R14,SW00PCA BASE PRIME BLOCK LH R7,SW00CNB INITIAL NAB #DO INF LA R15,0(R14,R7) BASE OF LREC * #IF CLC,STDFCH,EQ,=F'1' IF EXPANDED HEADER MVC SW00NBC(L'STDNAB),ISA.ISTD8_NAB NAB->WR1 #ELSE MVC SW00NBC(L'STDNAB),STDNABA NAB TO WR1 #EIF #GOTO UWBEE03E,IF, # CH,R7,NL,SW00NBC,OR, NO MORE LRECS IN PRIME # CLI,ZZZZKEYF,NE,#ZZZZK02 NOT BLOCK INDEX #DOEX CLC,STDFCHA,EQ,=F'1',AND, EXPANDED HEADER # CLC,ZZZZFA1F,NE,DFP.IDECFA,ORIF, NEW FA NOT TRIED # CLC,STDFCHA,NE,=F'1',AND, NORMAL HEADER # CLC,ZZZZFA1F(4),EQ,DFP.IDEC2ND4 NEW FA NOT TRIED AH R7,ZZZZSIZF STEP TO NEXT BLOCK INDEX STH R7,SW00CNB SAVE CURRENT NAB IN BLOCK #EDO , * Local mod applied to correct this problem: #GOTO UWBEE03E,IF, # CH,R7,NL,SW00NBC,OR, NO MORE LRECS IN PRIME # CLI,ZZZZKEYF,NE,#ZZZZK02 NOT BLOCK INDEX #IF CLC,STDFCHA,EQ,=F'1' IF EXPANDED HEADER **FIX** MVC SW00FAW3,ZZZZFA1F POSS NEW SEARCH ARG **FIX** #ELSE **FIX** XC SW00FAW3,SW00FAW3 CLEAR LAST ADDRESS **FIX** MVC SW00FAW3 4(4),ZZZZFA1F POSS SEARCH ARG **FIX** #EIF **FIX** #DOEX CLC,STDFCHA,EQ,=F'1',AND, EXPANDED HEADER # CLC,ZZZZFA1F,NE,DFP.IDECFA,ORIF, NEW FA NOT TRIED # CLC,STDFCHA,NE,=F'1',AND, NORMAL HEADER # CLC,ZZZZFA1F(4),NE,DFP.IDEC2ND4 NEW FA NOT **FIX**
Local fix
na
Problem summary
SUBJECT: APAR NUMBER: PK62875 REFERENCE: AREA: TPFDF CENTRAL DATABASE ROUTINES SEGMENT: UWBE13 - RELEASE: TPFDF (Assembler) Pre-requisite APARs are (TPF only) : FOR SEGMENT UWBE13 (Assembler) - REL TPFDF PQ32210 PQ42198 PQ49738 PQ61837 PQ51955 PQ74483 PQ75887 PQ80141 PQ94935 PQ96246 PK05540 PK03317 PK13562 To be applied in the order listed for each segment. ABSTRACT OF PROBLEM ___________________ Possible CTL-4 or CTL-10 dump in DBCLS ABORT after an OPR-DB0100 (file retrieval error) with a file that uses block indexing. COMMENTS ON PROBLEM ___________________ In the DBCLS ABORT processing in UWBE, TPFDF attempts to clean up all of the core blocks. With block indexing active, it will do so by stepping through the TLRECs in the prime block and trying to attach each of the file addresses referenced in the TLRECs. However there are two problems in that routine. 1. The check for STDFCH is done with the wrong base register which could cause a CTL-4 dump or the NAB value loaded to be unpredictable. 2. The check for whether the 4 byte file address in the TLREC matches the file address on the DECB is done with the wrong condition ('EQ' is used instead of 'NE'). Secondly, the desired file address is not set up in SW00FAW3 which is used in the subsequent ATTAC. This could cause an infinite loop through the TLRECs which results in a CTL-10 dump.
Problem conclusion
SOLUTION ________ 1. In segment UWBE, the STDFCH check is changed to use a suffix so that the correct base register is used. 2. UWBE was also updated so that the condition for matching file addresses now correctly uses 'NE'. The correct address is now set up in SW00FAW3 prior to being used in the subse- quent ATTAC in UWB5. DEPENDENCIES ____________ Related Segments Affected By This APAR. _______________________________________ Segments to be assembled or compiled: Segments to be link edited: Load Modules to be loaded: Migration Considerations ======================== None -- END APAR PK62875
Temporary fix
Comments
APAR Information
APAR number
PK62875
Reported component name
TPFDF 1.1.3
Reported component ID
570619601
Reported release
113
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-03-18
Closed date
2008-08-28
Last modified date
2008-08-28
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
TPFDF 1.1.3
Fixed component ID
570619601
Applicable component levels
R113 PSY
UP
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSZL53","label":"z\/Transaction Processing Facility (TPF)"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"113","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSCFK4C","label":"TPF Database Facility for ALCS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"113","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
28 August 2008