PQ62661: MSGIIUB013E FOR RECON3 IF USING RECON DD STMT (HALDB). USES DYN-AMIC ALLOCATION EVEN THOUGH DD STMTS ARE SPECIFIED. FFIT PQ61858

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Several problems will be corrected:
  1.  In HALDB case:
  When defining RECONs in the DD statements, RECON3 would get
  messages:IEC161I 072-053
           IEC161I
           and
  +IIUB013E NO RECON3   DD STATEMENT OR DYNAMIC ALLOCATION MEMBER
  
  2.  Index Builder uses the dynamic allocation modules even
  though DD statements are specified for the indexes.
  
  3.  The following input statements were mistakenly specified
  for an HDAM database:
     PROC BLD_PRIMARY,DDVSCR1D
        INDEX DDVSCR1S
        INPUT SCAN
  
  Index Builder did not indicate access method specified
  was incorrect.  Error message
  IIUB003E DBD NAME SCR1S.   INVALID IN INDEX    CONTROL STATEMENT
  was issued hundreds of times with different DBD names in
  message text.
  
  Forward fit V2.1 PQ61858.
  

Local fix

• Define the RECONs in the dynamic allocation library (DFSMDA)
  the MSGIIUB013E is not issued.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: ALL IMS INDEX BUILDER V2.2 USERS.            *
  *                 (Forward-fit to UQ69009 of H22O210)          *
  ****************************************************************
  * PROBLEM DESCRIPTION: CUSTOMER OBSERVED THAT AN OLD SECONDARY *
  *                      INDEX DD NAME HAD BEEN OBTAINED FROM AN *
  *                      OLD DYNALIB MEMBER WHILE DD CARDS HAD   *
  *                      BEEN SUPPLIED.                          *
  *                      CUSTOMER OBSERVED THAT WHEN APPLYING    *
  *                      BUILD_PRIMARY FOR HDAM THE ERROR MESSAG *
  *                      IIUB003E WAS ISSUED REPEATEDLY INSTEAD  *
  *                      OF A SINGLE IIUB015E MESSAGE.           *
  *                      TESTERS OBSERVED MISLEADING IIUB013     *
  *                      MESSAGES ON RECON3 WHEN RECONS HAD BEEN *
  *                      DEFINED BY DD STATEMENTS ONLY AND HALDB *
  *                      WERE PROCESSED.                         *
  *                      CUSTOMER EXPERIENCED ABEND S0C4 RC11 AT *
  *                      OFFSET 1028 IN IIUBDBD.                 *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  DD/DSN COLLECT WASN'T CORRECTLY PROGRAMMED.
  IN SCAN MODE, NO CHECK WAS PERFORMED FOR DB ORGANIZATION.
  A RECON ALLOCATION CHECK MODE FLAG WASN'T RESET DURING
  DYNAMIC ALLOCATION, SO STATUS COULD BE INHERITED.
  WHEN EXTRACTING THE INDEX MAINTENANCE CSECT FROM THE DBD SOME
  ARBITRARY LENGTH WAS USED, BEING HIGH ENOUGH. IN SOME CASES,
  DATA OUTSIDES THE DBD WAS MOVED, AND IT COULD BELONG TO A PAGE
  NOT OWNED BY THE APPLICATION.
  

Problem conclusion

• DD/DSN COLLECT HAS BEEN REWRITTEN.
  WITH BUILD_PRIMARY IN SCAN MODE, DBORG CHECK IS ISSUED.
  THE RECON ALLOCATION CHECK MODE FLAG IS RESET UPON ENTRY
  TO DYNAMIC ALLOCATION.
  THE EXACT INDEX MAINTENANCE CSECT LENGTH IS USED.
  

Temporary fix

Comments

APAR Information

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

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

  UQ69034

Modules/Macros

•    IIUBDBDM IIUBDBD7 IIUBDBD8 IIUBDYNA IIUBINIM
  IIUBINI7 IIUBINI8
  

Fix information

• Fixed component name

  IMS INDEX BUILD

• Fixed component ID

  5655E2400

Applicable component levels

• R220 PSY UQ69034

     UP02/08/19 P F208

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.