PK13524: DRF V3 SUPPORT FOR INDEX BUILDER AND DFSPREC0

APAR status

• Closed as new function.

Error description

• DRF V3 support for Index Builder and DFSPREC0
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMS Database Recovery Facility Version 3     *
  *                 Release 1 users who wish to have Index       *
  *                 Builder or DFSPREC0 utilities invoked as     *
  *                 a post processing step to recovery.          *
  ****************************************************************
  * PROBLEM DESCRIPTION: The DRF recovery tool lacks an          *
  *                      integrated interface to the IMS Index   *
  *                      Builder and HALDB Index Rebuild         *
  *                      utilities.                              *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  IMS and DRF customers require an IBM product to provide the
  capability to build primary and secondary index data sets for
  HIDAM, HISAM, PHIDAM and PHISAM organized databases while
  recovering the database.  Customers also require the ability to
  produce HALDB Index List data sets while recovering the
  database.
  

Problem conclusion

Temporary fix

Comments

• DRF is enhanced to provide customers with the capability to
  invoke the IBM IMS Index Builder and HALDB Index Rebuild (ILDS)
  utilities under the same recovery job.  These utilities will be
  driven by DRF after recovery of the database data sets are
  complete.
  
  The following maintenance is required to support this function:
   Index Builder Version 2 Release 3:
     PK11688 (UK17185)
   If running with HPIC Version 4 Release 1:
     PK30631 (UK17699)
   If running with HPIC Version 3 Release 2:
     PK30633 (UK17702)
   If running with IMS Version 9 Release 1:
     PK28526 (UK17506)
   If running with IMS Version 8 Release 1:
     PK28520 (UK17505)
  ------------
  The following Doc changes are required in:
  IBM IMS Database Recovery Facility for z/OS,
  User's Guide and Reference, Version 3 Release 1 (SC18-9407-00)
  Chapter 3. Defining and tailoring the IMS Database Recovery
  Facility enviornment
  
  At the end of the section that describes "DISP(OLD|NEW)" and
  "NEW" at about page 30, add the following:
   ...
   NOTE:  The following is a list of attribute/field names that
          will be retrieved from an existing data set:
          - DEVTYP
          - VOLSER
          - STORCLAS
          - DATACLAS
          - MGMTCLAS
          - NVSMATTR
          - VSAMTYPE
          - VSAMREUS
          - ATTR2
          - PRIMSPAC
          - SCONSPAC
          - SPACOPTN
          - LRECL
          - AMDKEY
          - AMDCIREC
          - PHYBLKSZ
          - NOBLKTRK
          - VSAMSTAT
          - NOBYTTRK
  --------
  In section "Specifying UTILGBL() global control statement
  parameters" at about page 37, change the third paragraph to
  remove "IB()" from the first sentence.
  --------
  In section "Secifying UTILGBL() global control statement
  parameters", insert the following after the third paragraph:
   While the use of UTILGBL is allowed for IB() control
   statements, it is important to remember that these parameters
   will be effective for every DBDS that is recovered and could
   result in unwanted side effects if the user is recovering
   multiple DBDS consisting of mixed database types (HALDB, HDAM,
   HIDAM, Primary Index).  Some examples of this are;
     x Specifying HALDB=BOTH on the UTILGBL statement when
       recovering a mix of HALDB, HDAM and HIDAM would result in
       the DFSPREC0 IMS utility being initiated to rebuild the
       Index and ILE data sets not only for HALDB databases, but
       also for HDAM and HIDAM.  These would end with non-zero
       return codes, which be reflected in the final result for
       the recovery of those DBDS.
     x Specifying BLD_PRIMARY on the UTILGBL statements when
       recovering a mix of HIDAM, HDAM and Primary Index would
       result in Index Builder being called not only for the
       HIDAM DBDS, but also for the HDAM and Primary Index.
       Since Index Builder cannot build a Primary Index for HDAM
       or a recovered Primary Index, Index Builder would
       terminate with a non-zero return code for these requests.
     x Specifying HALDB=BOTH,BLD_PRIMARY on the UTILGBL statement
       when recovering a mix of HALDB, HDAM and HIDAM would
       result in the DFSPREC0 utility being initiated for
       recovered HDAM and HIDAM.  It would also result in having
       the Primary Index for the HALDB DBDS rebuilt twice.  Once
       by the DFSPREC0 utility and a second time by Index
       Builder.
     x Specifying HALDB on the UTILGBL statement will cause
       DFSPREC0 to run even if IB() is not specified on the ADD()
       statement.
     x Specifying BLD_SECONDARY or BLD_PRIMARY on the UTILGBL
       statement will cause IB to run even if IB() is not
       specified on the ADD() statement.
   Because of this, it is recommended the judicious use of the
   IB() parms on the UTILGBL statement when the Integrated
   Auxiliary Processing utilities are to be invoked from DRF.
  --------
  After the section "Updating the MVS program properties table"
  at about page 41, add the following new section:
   ...
   Tailoring for Integrated Auxiliary Processing
  
   When Index Builder (IB) is running under DRF, the following IB
   input control statement are required and will be hardcoded in
   IB code (cannot be changed by the user):
   - SORTE35  YES
   - ALTER    NO
   - STEPLIB  TRAN
   - SORTE15  YES
   Currently DRF allows customers to specify SORTE35 and SORTID
   in the DRF input control statements for IB.  The following
   will now be true:
   - If SORTE35 is specified, it will be ignored and SORTE35 YES
     will be used by IB.
   - SORTID can be specified by customer, but if not specified a
     SORTID value of T is set.  The sort procedure requires two
     parameters in the JCL (&INDEX and &STEPLIB).  The STEPLIB
     TRANS control statement is required in order to make sure
     the same libraries used in the main IB job get passed and
     used in the IIUBSRT procedrue.
   These restrictions and requirements only pertain to IB running
   under DRF.  Standalone IB will continue to operate as it
   currently does.
   - The sample DRF IB and DFSPREC0 procedure is as follows:
  
   //x                                                          x
   //x Licensed Materials - Property of IBM                     x
   //x                                                          x
   //x 5655-N47                                                 x
   //x                                                          x
   //x (C) Copyright IBM Corp. 2006 All Rights Reserved         x
   //x                                                          x
   //x US Government Users Restricted Rights - Use, Duplication x
   //x or disclosure restricted by GSA ADP Schedule Contract    x
   //x with IBM Corp.                                           x
   //x                                                          x
   //x                                                          x
   //x PROCEDURE PROC FOR  DRF IB/DFSPREC0  |  NPHIDAM   |      x
   //DRFIAX PROC RGN=0M,SOUT='*',
   //            RESLIB='DRF.SFRXRESL',
   //            IBRES='IB.RESLIB',
   //            BPECFG=FRXBPECF,
   //STEP1  EXEC PGM=FRXSDR10,
   //            PARM='DRF,BPECFG=&BPECFG',
   //            REGION=&RGN,TIME=1440
   //STEPLIB  DD DSN=&RESLIB,DISP=SHR
   //         DD DSN=&IBRES,DISP=SHR                   <-- IB RES
   //         DD DSN=IMS.SDFSRESL,DISP=SHR
   //         DD DSN=IMS.DYNALLOC,DISP=SHR
   //x DD STATEMENTS COMMON TO BOTH IB AND DFSPREC0             x
   //DFSRESLB DD DSN=IMS.SDFSRESL,DISP=SHR
   //IMS      DD DSN=&IBRES,DISP=SHR
   //         DD DSN=IMS.PSBLIB,DISP=SHR
   //         DD DSN=IMS.DBDLIB,DISP=SHR
   //IMSACBA  DD UNIT=SYSDA,DISP=SHR,
   //            DSN=IMS.DELTALIB
   //         DD DSN=IMS.ACBLIB,DISP=SHR
   //IMSACBB  DD UNIT=SYSDA,DISP=SHR,
   //            DSN=IMS.DELTALIB
   //         DD DSN=IMS.ACBLIB,DISP=SHR
   //MODSTAT  DD DSN=IMS.MODSTAT,DISP=SHR
   //SYSUDUMP DD SYSOUT=&SOUT
   //x DFSPREC0 DD STATEMENTS                                   x
   //x INDEX BUILDER DD STATEMENTS                              x
   //DFSVSAMP DD DSN=IMS.DFSVSAMP.DATA(VSM885FP),DISP=SHR
   //PROCLIB  DD DSN=IMS.PROCLIB,DISP=SHR
   //IEFRDER  DD DSN=IMS.IMS02.OLDSP0,DISP=SHR,
   //            DCB=(RECFM=VB,BLKSIZE=22528,LRECL=22524,BUFNO=5)
   //IEFRDER2 DD DSN=IMS.IMS02.OLDSP1,DISP=SHR,
   //            DCB=(RECFM=VB,BLKSIZE=22528,LRECL=22524,BUFNO=5)
   //PRINTDD  DD SYSOUT=&SOUT
   //FRXPRINT DD SYSOUT=&SOUT
   //WTSRPRT  DD SYSOUT=&SOUT
   //IMSERR   DD SYSOUT=&SOUT
   //IMSMON   DD DUMMY
   //         DD DSN=IMS.DBDLIB,DISP=SHR
  
   - The sample sort procedure for IB is as follows:
  
   //x COMPLIMENTARY SORT PROCEDURE FOR DRF V3 when calling     x
   //x IB(), IC() and PC()                                      x
   //IIUBSRTT PROC INDEX=,IIUSTEPL=
   //IEFPROC  EXEC PGM=IIUBSCTL,REGION=0M,TIME=1439       33M
   //STEPLIB  DD   DISP=SHR,DSN=&IIUSTEPL
   //IEFRDER  DD   DISP=SHR,DSN=&INDEX,
   //              AMP=('BUFND=128,BUFNI=128')
   //SRTO     DD   SYSOUT=*
   //SRTC     DD   DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(TRK,(1,1)),
   //              DCB=(RECFM=FBA,LRECL=121,BLKSIZE=24200)
   //IIUDKEYS DD   SYSOUT=*
   //SYSUDUMP DD   SYSOUT=*
   //SORTWK01 DD   DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(CYL,(1,1))
   //SORTWK02 DD   DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(CYL,(1,1))
   //SORTWK03 DD   DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(CYL,(1,1))
  
   - If you want DFSPREC0 to be driven, module DFSDAPL0 needs to
     be updated by inserting the following three statements:
       PGMR     DC    CL8'FRXSDR10'       DRF IAP PROCESSING
       PROCOPTR DC    CL4'A'
       MASKR    DC    X'0000'
     In addition, you need to assemble and link edit the updated
     DFSDAPL0 into the IMS runtime load library.
  --------
  Chapter 5. Starting the IMS Database Recovery Facility
  
  In the section "Choosing SYSIN control statement input" at
  about page 62, add the following after "Considering batch
  recovery control statements":
  
   NOTE: Comments entered within DRF control statements must be
         enclosed within a "/x" and "x/" pair.
  --------
  In the section that describes "IB" at about page 69, add the
  following:
  
   While it is normally permissible to define multiple DBD names
   on an ADD statement for recovery processing, it is recommended
   that care should be taken when doing this if there will also
   be integrated auxiliary processing with DFSPREC0 or Index
   Builder parms included with the ADD statement.  The
   combination can be susceptible to the same type of errors
   described in the "Specifying UTILGBL() global control
   statement parameters" section in Chapter 3.
  
   If multiple DBD names are specified in a single ADD statement
   and IB parms are also included:
    x Insure that the database type (HDAM, HIDAM, PHDAM, PHIDAM)
      for the databases are all the same.
    x When multiple DBD names are included on the ADD statement
      only BLD_SECONDARY=ALL should be specified.
      BLD_SECONDARY=SELECTED will return inconsistent results.
      Only ADD statements with a single DBD name specified
      should have the BLD_SECONDARY=SELECTED.
    x ADD statements for the recovery of a Primary Index DBDS
      should not specify any IB parms.
    x DRF supports the recovery of a recoverable Index database
      data set.  It also support the generation of an image copy
      and execution of pointer checking of that index with the
      use of the IC() and PC() keywords.  DRF, however, currently
      does not support the above combination with the addition
      of an index rebuild as a post process.
  --------
  In the section that describes "HALDB(ILE|INDEX|BOTH)" at about
  page 69, add:
  
   This parameter should be specified on the ADD statements for
   PHIDAM only.
  --------
  In the section that describes "BLD_PRIMARY" at about page 70,
  add:
   When DFSPREC0 is needed for HALDB Primary Index and ILE
   processing, DFSDAPL0 must be modified (See "Tailoring for
   Integrated Auxiliary Processing" in Chapter 3).
  
   This parameter is relevant for a HIDAM database only and if
   specified on an ADD statement for a HDAM database, will result
   in Index Builder being called and ending with a non-zero
   return code.
  --------
  In the section that describes "BLD_SECONDARY" at about page 70,
  add:
   BLD_SECONDARY(secixdbname1,...) should only be used with an
   ADD statement which specifies a single recovered DBDS.
  --------
  In the section that describes "ICNDX(NO|YES)" at about page 72,
  change the first paragraph to say:
  
   This option does not apply to HALDB primary index and ILE data
   sets because they are not recoverable.  This also does not
   apply to secondary index that are not recoverable.  However,
   if you specify ICNDX(YES), both secondary indexes for non-
   HALDB and HALDB databases are image copied.  For non-HALDB,
   recoverable primary indexes will be image copied.
  --------
  In the section that describes "PC" at about page 74, add:
  
   NOTE: For HALDB, neither the primary index or secondary index
         are checkd by the pointer checker through Index Builder.
  --------
  Chapter 7. Messages and Codes of IMS Database Recovery Facility
  
  Add the new reason description for the following message:
  FRD6124A INVALID DATA ENCOUNTERED.  KEYWORD: keyword RSN=rsn
  ...
  rsn
    UNIQUE VOLUMES REQUIRED ON VOLSER AND VOLSER2
        If generating dual IC outputs on tape, VOLSER and VOLSER2
        can be specified optionally to provide a list of tape
        volumes for each set.  The volumes in one list cannot
        be provided in the second list, otherwise the image copies
        being generated may overlay one another.
  --------
  Modify the following message message text:
  FRD9002A utiltype ENCOUNTERED RETURN CODE rtn REASON CODE rsn
           PROCESSING
  
  change it to:
  FRD9002A utiltype ENCOUNTERED RC=rtn RSN=rsn PROCESSING
  --------
  For the following message, add another utiltype:
  FRD9003A utiltype DYNAMIC ALLOCATION rtn RESON CODE rsn FOR
           dsname
    ...
    * WT - WTO capture services
    ...
  Module:
    ...
    FRXVSTA0
  --------
  Add the following new message:
  FRD9006W INDEX DATA SETS WILL NOT BE IMAGE COPIED AFTER A
           REBUILD IF STACK SPECIFIED
  
  Explaination:  IMS Database Recovery Facility is invoked to
  generate image copies of the recovered database stacked on tape.
  It is also invoked to perform an index rebuild.  Following the
  index rebuild, an image copy will not be generated for the
  index data set if stacking is being performed.
  
  System programmer response: To generate an image copy of your
  index data sets, run a seperate image copy utility after
  recovery.  Alternately, DRF will allow IB to have image copies
  generated if STACK is not specified.
  
  Module: FRXVASD0
  &#215;**** PE06/10/02 FIX IN ERROR. SEE APAR PK32290  FOR DESCRIPTION
  

APAR Information

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

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

  UK18259

Modules/Macros

• FRXBDMG0 FRXEDRF0 FRXEDSG0 FRXEGRM  FRXEGRM0
  FRXEPCC0 FRXEPSS0 FRXGAPI0 FRXIAUX  FRXIOCN0 FRXIOSM0 FRXIVCN0
  FRXIVSM0 FRXLBLD0 FRXLRCN0 FRXLUTR0 FRXMNP   FRXMSTR1 FRXMTC
  FRXMTRM0 FRXMTRM1 FRXRAUA0 FRXRAUD0 FRXRAUW0 FRXRAUX  FRXRAUX0
  FRXRVGB  FRXSASP  FRXSDR20 FRXSVCS0 FRXSV35S FRXTAPI  FRXTAPI0
  FRXTAU00 FRXTPIB0 FRXTPPR0 FRXTSIB0 FRXTSPR0 FRXUAPI0 FRXUPRE0
  FRXUSST  FRXUTGB  FRXUTIB0 FRXVASD0 FRXVRCV0 FRXVSTA0 FRXVSTA1
  FRXVSTA2 FRXVWSP  FRXWRTN0 H27L310J
  

Fix information

• Fixed component name

  IMS DB RECOVERY

• Fixed component ID

  5655I4400

Applicable component levels

• R310 PSY UK18259

     UP06/09/26 P F609