PK36640: ABEND0C4 AFTER PRILOG OPEN ERROR 07/01/16 PTF PECHANGE

APAR status

• Closed as program error.

Error description

• An abend occurred in the following scenario.
  (1) delete PRILOG RLDS from DASD to simulate the read error.
  (2) run a DB recovery job
  (3) IEC143I 213-04 was issued against PRILOG RLDS
  (4) DRF tried to allocate SECLOG SLDS on VTS, but got abend0C4.
  (5) Then, the customer set ERROR to PRILOG in RECON, and rerun
      the DB recovery job to recover using SECLOG SLDS on VTS.
      However, abend0C4 reoccurred.
  Abend0C4 occurred at FRXMSTR0(UK18327)+283A because reg4 is
  zero.
  FRXMSTR0(UK18327)+283A is in AllocRequestResp routine where
  FRXMSTR0 send a message to subordinate address space that an
  allocate device is available.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMS users with IMS Database Recovery         *
  *                 Facility Version 2 Release 1 installed.      *
  ****************************************************************
  * PROBLEM DESCRIPTION: Users may encounter an ABENDS0C4 in     *
  *                      FRXMSTR0 during a log data set read     *
  *                      error or when a log data set is being   *
  *                      accessed from tape.                     *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  When TAPECHK(Y) and CACHE(Y) is specified, users may encounter
  an ABENDS0C4 in FRXMSTR0 during log data set read errors or
  after accesses to log data sets residing on tape.  A conflict
  exist in the tape device request/permission logic between the
  log data set read and image copy caching processes.  This
  conflict was introduced by PK25407.
  

Problem conclusion

• AIDS: RIDS/UTIL RIDS/DBS DBS/UTIL
    DEP: NONE
    GEN:
  
  *** END IMS KEYWORDS ***
  FRXIDYN0 is changed to prevent the tape drive request logic
  (TAPECHK) from being invoked during image copy caching process
  (CACHE).  Tape drive request is required only when the image
  copies are being opened for reading.  During caching, the image
  copies only goes through deferred allocation and managed by
  VTS.  They are not opened by DRF for reading during this
  process.
  
  FRXAWEX, FRXRVRA, FRXMSTR0, FRXYALL0, and FRXYUNA0 are changed
  to remove code changes that were introduced by PK25407.
  PK25407 introduced code that tracked the access of log and
  change accumulation data sets with the number of available tape
  devices supplied on READNUM and coordinated it with the tape
  device requests from subordinate address spaces.  This was
  meant to help prevent the subordinate address spaces from
  exceeding the number of available tape devices when they are in
  use by log and CA data sets.  It was later determined that the
  image copy data set read process always occurs after all log
  and CA data sets are processed.  The image copy caching process
  occurs in parallel to the log and CA read process, however,
  caching does not require to follow the tape device request
  logic.
  

Temporary fix

Comments

• ×**** PE07/07/17 PTF IN ERROR. SEE APAR PK43011  FOR DESCRIPTION
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK21601

Modules/Macros

• FRXAWEX  FRXIDYN0 FRXMSTR0 FRXRVRA  FRXYALL0
  FRXYUNA0
  

Fix information

• Fixed component name

  IMS DB RECOVERY

• Fixed component ID

  5655I4400

Applicable component levels

• R210 PSY UK21601

     UP07/02/02 P F702 Ø