PM78203: THE OLREORG CURSOR ACTIVE FLAG IS NOT RESET IN ALL CASES

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When an HALDB Online Reorganization is active and a timestamp
  recovery is done prior to the HALDB Online Reorganization, the
  OLREORG CURSOR ACTIVE flag is not reset in all cases.  As a
  result of having the flag on, both sets of data sets appear to
  be active.
  

Local fix

• Use a CHANGE.DB DBD(name) OLRRGOFF command to turn the flag off.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IM V13 DBRC users recovering HALDB       *
  *                 databases when Online Reorganization         *
  *                 records exist in the RECON when              *
  *                 a timestamp recovery is executed.            *
  ****************************************************************
  * PROBLEM DESCRIPTION: When multiple timestamp recoveries      *
  *                      are run with multiple HALDB Online      *
  *                      Reorganization records, the             *
  *                      OLREORG CURSOR ACTIVE flag is not       *
  *                      turned off in certain cases.            *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  When the next HALDB Online Reorganization is not active and a
  timestamp recovery is done prior to the HALDB Online
  Reorganization, the OLREORG ACTIVE flag did not get turned
  off.  The OLREORG CURSOR ACTIVE =YES is on and both data sets
  show as active (ACTIVE DBDS=A-J and M-V) in the partition
  database record.
  
  Timeline for the problem found:
  
          |<---------------------------------------------------R3
          |<---------------------------------------------------R4
                                  |<---------------------------R1
                                  |<---------------------------R2
  (A)IC1
     |--A1--------D1----A2--------------D2--A3---------|
           |OLR1(N)|    |OLR2(Y)| |OLR3(N)| |-OLR4(Y)--
  
  
                        |<-------------------------------------RA
                        |<-------------------------------------RB
                        |<-------------------------------------RC
                        |<-------------------------------------RD
  (M)
     |-----AA-----------------DA--AB-----------------DB--|
           |OLR1(Y)|    |OLR2(N)| |OLR3(Y)| |-OLR4(Y)--
  
  Legend:
  A1,D1,A2,D2,A3, - all allocations/deallocations for A-J
  R1, R2, R3, R4 - timestamp recoveries for A-J (done after RD)
  OLR1,OLR2,OLR3,OLR4 - OLRs (Y-RECOV=YES, N- RECOV=NO)
  AA,DA,AB,DB - all allocations/deallocations for M-V
  RA,RB,RC,RD - timestamp recoveries for M-V (done prior to R1)
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  For a Point-in-time recovery (PITR), if the recov-to-time
  equals the HALDB Online Reorganization run time, the
  recovery is considered to done prior to the reorg. If the
  recov-to-time is less than or equal to the stoptime of
  a completed HALDB Online Reorganization, the recovery
  is consider to be done within the reorg.
  
  If the recov-to-time is equal to the HALDB Online
  Reorganization run time, the class locate previous correctly
  did not find a previous reorg.  However, a class locate next
  did not find the reorg record that was equal to the
  recov-to-time.  Before doing a class locate next when a
  previous reorg is not found, a class locate NOTGT is now done
  to find a reorg record that is equal to the recov-to-time.
  
  The OLREORG ACTIVE flag is set off in the case where
  the recover-to-timestamp is not in the middle of an active
  HALDB Online Reorganization.
  
  Prior to this APAR, a recovery prior to an open
  OLR would delete the OLR and mark the DBDS as image copy
  needed.  Now the open OLR is not deleted.  The image copy
  recommended flag is set on instead of the image copy needed
  flag.  A new image copy is needed to establish a new
  purgetime for change accumulation processing.
  When a PITR recovery is done to the middle of an OLR, the
  image copy recommended flag is also set on.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

  PM78201

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

  UK92991

Modules/Macros

•    DSPURT00 DSPURT20 DSPURT95
  

Fix information

• Fixed component name

  IMS V13

• Fixed component ID

  5635A0400

Applicable component levels

• R300 PSY UK92991

     UP13/04/02 P F304 Ž

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.