Skip to main content

Transaction Processing Facility (TPF) - Online Maintenance TPF Online Maintenance TPF Online Maintenance Skip to: Abstract | Comments | Solution | Related Segments | Migration | Download

SUBJECT:         APAR  NUMBER: PJ27415  (HIPER) 
 
REFERENCE:  AREA:     RECOUP 
            SEGMENT:  BKDB40     - RELEASE:  TPF4  (Assembler) 
 
 
Pre-requisite APARs are: 
FOR SEGMENT BKDB40     (Assembler) - REL TPF4 
 PJ21044  PJ24481  
To be applied in the order listed for each segment. 

ABSTRACT OF PROBLEM 
___________________ 
Recoup  does  not  chain chase the new communication record type 
for the SRT introduced in PJ27387. 
 

COMMENTS ON PROBLEM 
___________________ 
PJ27387 introduced new processor unique record  types  for  many 
communication fixed file records.  One of these record types was 
for the System Recovery Table (SRT) fixed file records (#SRTRU). 
These  records may contain long-term file address references.  A 
system recoup descriptor, BKDB, contains  information  to  allow 
recoup  to  chain  chase  the SRT file addresses.  Modifications 
were not made to BKDB to handle the new SRT record type. 
 

SOLUTION 
________ 
Recoup descriptor BKDB has been modified to contain  information 
about the new SRT record type (#SRTRU).  The old SRT record type 
(#SRTRI) has been removed from the descriptor. 
 
DEPENDENCIES 
____________ 
 
Related Segments Affected By This APAR. 
_______________________________________ 
 
Segments to be assembled or compiled: 
None 
 
Segments to be link edited: 
None 
 
Load Modules to be loaded: 
None 
 
Migration Considerations 
======================== 
Loosely coupled customers who do not have this APAR applied 
on all processors when migrating need to take the following 
action: 
 
The new SRT GROUP/INDEX definitions in recoup descriptor BKDB 
need to be added to any back level processor running recoup 
that does not have this APAR applied.  Recoup should only be 
run from a back level processor with these definitions added. 
Please note that if you do not plan to run recoup during migration 
then you do not need to take this action. 
 
The reason for this is due to a complicated migration scenario 
involving new record types (PJ27387 added #SRTRU) and the new 
recoup (PJ27469).  Both APARs are on PUT13.  The migration 
scenario for PJ27469 requires that any recoup during migration 
needs to be run from a back level processor that does not have 
PJ27469 applied.  HOWEVER, back level processors may not have the 
new SRT record defined (PJ27387).  Therefore, the GROUP/INDEX 
definitions in BKDB for the SRT, added with this APAR, need to be 
added to any back level processor running recoup to handle this 
problem.  This is true even if the customer does not apply 
PJ27469.  In other words, if a customer selectively applies PUT13, 
for example applying all PUT13 APARs except for PJ27469, the 
customer would still need to copy the following SRT GROUP/INDEX 
definitions to any back level processor to run RECOUP during 
migration.  Failure to do this will result in database 
corruption. 
 
 
 
BUILD/TEST INSTRUCTIONS 
_______________________ 
 
 ===BUILD Instructions=== 
 
No special build instructions. 
 
Stubs to be built: 
 
 ===TEST Instructions=== 
 
No special test instructions. 
 
-- END APAR PJ27415 
 
 
 



Download file(s): Login once to access server, leave window open, then click on link(s) below. Source