II08571: DB2 V4 INSTALLATION and MIGRATION HINTS and TIPS. CONTINUED IN II10542.

APAR status

• Closed as canceled.

Error description

• 5740XYR00 DB2 R410             Last updated on (08/31/99 jbw)
  The purpose of this INFOAPAR is to document hints and tips
  for DB2 R410 installation or migration.  Continued in II10542.
  ----------------------------------------------------------------
  Prior releases of DB2 ERLY code had 3 modules:
     DSN3EP  used by MVS/XA
     DSN3EPX used by MVS/ESA
     DSN3INI used by both XA and ESA
  
  Version 4 only runs with MVS/ESA so DSN3EP is no longer
  necessary. The ERLY code for V4 consists of:
     DSN3EPX   subsystem interface
     DSN3INI   master scheduler initialization
     DSN7GARM  (MVS ARM - auto recover manager)
  
  Job DSNTIJMV updates SYS1.PARMLIB. The new format of IEFSSNxx
  incorrectly lists DSN3EP as the parm. It should list DSN3EPX
  however, the code is smart enough to know you are running
  MVS/ESA and therefore need DSN3EPX. It will call the correct
  module no matter what you list in the IEFSSNxx member.
     Incorrect loading, or downlevel DSN3xxx csect will usually
  result in various abends in IEFJRASP (MASTER subsystem).
  See R310/R410 compatibility apar PN58259.
  ================================================================
  DSNTIJTC - CATMAINT problems
     S04E rc00E40600 or rc00E40601 in DSNUEXUN during migration
  could mean you have duplicate rows in SYSLGRNG.  Check the
  following locations in the dump for pertinent information.
  1) Reg2 points to the error message - Unexpected RC from
      insert LGRNX ...DSNUEXUN followed by Unexpected RC from
      read ...DSNUGABN
  2) Reg3 points to the duplicate row in SYSLGRNG. The format
      of the data is:  DBID, PSID, modification date & time,
      starting RBA. See V3 Diagnosis Guide pg. 328 for details.
      CATMAINT stops after it finds the first duplicate row in
      SYSLGRNG.  There could be others.
  Two options for resolution are:
  1) Delete SYSLGRNG, redefine and re-initialize it. Migrate
     to V4. Take image copies to repopulate SYSLGRNX.
     drawback: Recovery time may be longer since you will need
     to scan the logs from last IC for updates to tables.
  2) Run REPORT RECOVER on all tablespaces to find duplicates
     then run MODIFY to delete old SYSCOPY and SYSLGRNG records.
     If you need to keep one of the records, then run REPAIR
     DELETE to remove the duplicate.
     drawback: Time consuming to run REPORT and MODIFY on
     tablespaces.
        (This is resolved in APAR PN81769, PTF is UN89571).
  ==============================================================
  DSNTIJTC - CATMAINT problems
     Abend04E RC00E40601 in module DSNUEXDL during migration.
  Abend occurs because DSNXICTB issues a negative SQLcode. Check
  the following locations for pertinent information.
  1) Reg7 points to the CT.  CT + x'34' points to RDA.  RDA
      + x'08' points to SQLCA.  SQLCA contains the SQL return
      code, error message and description of problem.
  2) Reg2 contains address of error message (RC)
  3) Reg3 contains address of SQL statement that failed
  4) Reg4 &/or reg5 may contain the negative SQL code in the
      format FFFFFxxx. This number converted from hex to decimal
      is the -SQL code.  EXample: x'FFFFFDA7' = decimal -601.
                         (Note: -601 means DUPLICATE dsname)
  Customers need to determine what the exact failure is from
  the above locations before proceeding. Some common errors are:
  - Utility in process before CATMAINT was begun (return to
     V3, -term the utility then re-run CATMAINT)
  
  - DSNDB07 is out of space (expand the size of 4K temp files to
     accomodate the new indexes)
     See apar PN91535 in UQ01338 in reference to VSAM out
     of space conditions while running CATMAINT (rc00D70014).
  
  - RESOURCE UNAVAILABLE: unable to open dataset due to unexpected
     level id. (Customers should run the migration version of
     DSNTIJID not the install version. The Migration version of
     DSNTIJID initializes SYSLGRNX and its indexes DSNLLX01 and
     DSNLLX02 as TYPE 1 indexes (uses DSNTIS75 & DSNTIS76). The
     other new indexes do not need to be initialized since they
     will be built & initialized by CATMAINT.  The install version
     DSNTIJID initializes all the indexes but as type2.)
  
  - Also note in reference to DSNTIJID in a DataSharing SYSPLEX,
    failure to properly/cleanly run DSNTIJID before merging a
    second DS member into the PLEX, will result in msgDSNJ130i
    with mismatched BSDS | DSNZPARM VSAM ICF CATALOG names.  The
    migration utility must be run so as to setup the proper
    ICF CATALOG NAME | ALIAS into the BSDS.
  
  - there could be other reasons, check SQLCA for cause of
     the abend.
  
  - If customer finds there is a duplicate (-601) dsname for
     SYSIBM.SYSPROCEDURES check to see if an OEM product called
     MDI Gateway has been installed.  MDI has been using a
     tablespace called SYSPROCEDURES with DB2 for several years.
     The default name of this tablespace is shipped as
     SYSMDI.SYSPROCEDURES but some customers have modified this
     name to SYSIBM.SYSPROCEDURES. The original HLQ (High Level
     Qualifier) or anything except SYSIBM must be used for MDI's
     tablespace name BEFORE installing DB2 V4.1.
     NOTE: err can be rc00E40600 or rc00E40601 sqlcode601 (-601)
  
  There are 10 new indexes added via job DSNTIJTC when migrating
  to V4. If there is not enought space in DSNDB07 to handle these
  new indexes, CATMAINT issues rc00E40601.  You can increase the
  size of DSNDB07 (for sizing see section, DASD Requirements for
  Work File Database in Chapter 2) and then re-run CATMAINT.
  You have to increase work space for DSNDB07 under DB2 V3.
  Customers may need to increase the 4K temp. tablespaces.
     Note: If DSNTIJTC fails for any reason, that reason MUST
  be corrected and the job MUST be run again from the TOP.
  This CATMAINT utility has NO checkpoint/restart ability.
  After completion, you might wish to run CHECK INDEX to insure
  that the new INDEX created is good,  and also run a LISTCAT
  to insure that the physical characteristics of the INDEX are
  acceptable.  A VSAM dataset can have 119 extents, If the
  INDEX is physcally correct after this CATMAINT job ends, then
  the entire index should tend to be in the 1 primary extent.
     See DB2 R410 Installation Guide chap2 page249 (see PN91535)
  
  The new indexes on table (columns) are listed below:
  See Diagnosis Guide and Reference, chap7 - Directory and
  Catalog Diagrams to find tablespace/table relationships.
  DSNSCX01 on SYSIBM.SYSCHECKS (TBOWNER, TBNAME, CHECKNAME)
  DSNSDX01 on SYSIBM.SYSCHECKDEP   (TBOWNER, TBNAME, CHECKNAME,
                                    COLMANE)
  DSNKCX01 on SYSIBM.SYSPROCEDURES (PROCEDURE, AUTHID DESC,
                                    LUNAME DESC)
  DSNATX03 on SYSIBM.SYSTABAUTH    (GRANTEE, GRANTEETYPE, COLLID,
                                    CONTOKEN)
  DSNDRX01 on SYSIBM.SYSINDEXPART  (IXCREATOR, IXNAME, PARTITION)
  DSNDPX01 on SYSIBM.SYSTABLEPART  (DBNAME, TSNAME, PARTITION)
  DSNDDX02 on SYSIBM.SYSDATABASE   (GROUP_MEMBER)
  DSNVVX01 on SYSIBM.SYSVIEWS      (CREATOR, NAME, SEQNO)
  DSNDKX01 on SYSIBM.SYSKEYS       (IXCREATOR, IXNAME, COLNAME)
  DSNDXX03 on SYSIBM.SYSINDEXES    (TBCREATOR, TBNAME, CREATOR,
                                    NAME)
  ================================================================
  ABEND04E rc00E40601 in module DSNUTILA csect DSNUECMI during
  migration job DSNTIJTC (CATMAINT). msgDSNT500i resource
  unavailable for DSNDB01.DSNLLX01.  This was caused by running
  the migration version of DSNTIJID but on the wrong dataset.
  ================================================================
  For customers with Install Guide -00 make the following
  changes under chapter 2-9 IVPs. On page 2-256 topic Special
  consideration for COBOL programs, modify the paragraph after
  table 58, second to last sentence change "except those marked
  with an asterisk." to "except those noted otherwise."
  Also add the following sentence on page. 2-258 after the bullet
  "-Add the parameter CICSOPT(COBOL2)..."  Add: "You must make
  the change yourself; the installation CLIST will not make the
  change for you."
  ================================================================
  Customers wanting to add stored procedures to an existing
  V4.1 DB2 subsystem can NOT use UPDATE mode on the Install
  CLIST.  They can chose an option below.
  
  1) Run the Install CLIST in INSTALL or MIGRATE mode using a new
     set of libraries on panel DSNTIPT.
   - specify remote location name on panel DSNTIPY(required to
     generate IVP jobs DSNTEJ6S and DSNTEJ6P)
   - set accept SQL call to YES on panel DSNTIPX, as well as
     fill in the rest of the fields on this panel.
   - specify a location name on panel DSNTIPR (required to
     generate the IVPs jobs DSNTEJ6S and DSNTEJ6P)
   - use PLI370 by leaving fields 7 & 9 blank on panel DSNTIPG
     (required for IVP jobs DSNTEJ6S and DSNTEJ6P)
  
  Or, if you can not easily run the CLIST in INSTALL or MIGRATE
  mode, you can manually add stored procedures.  This does not
  give you a migration path since your DSNTIDxx member and
  DSNTIJUZ parms are not saved for future input.  You could
  modify your DSNTIDxx member but this is dangerous.
  
  2) Edit DSNTIJUZ to add values to parms:  STORMXAB, STORPROC,
     and STORTIME
     -generate a SPAS PROC filling in all pertinent fields
      (PROCNAME, SUBSYS name, NUMTCB, STEPLIB libraries)
     -authorize the ID associated with the SPAS PROC to use CAF
  
  This procedure will not generate the IVP jobs DSNTEJ6S and
  DSNTEJ6P since you are not running the DSNTINST CLIST.
  ================================================================
  Users setting up IEFSSNxx for DB2 R410 with multiple character
  command prefix on a system that will continue to have R310 or
  R230 DB2 subsystems should be aware that R310 and R230 must
  continue to use a single character prefix (known in these
  releases as the subsystem recognition character or SRC).
  
  Symptoms of trying to use multiple character cmd prefixes with
  releases prior to r410 include MSGDSN9019I NOT A KNOWN COMMAND
  and MSGDSN9023I ABNORMAL COMPLETION.
  ================================================================
  If you do not specify DSNTIDXA in field 6 of panel DSNTIPA1
  during the first migration or installation of V4, you will
  encountered errors during DSNTINST CLIST processing.
  The error include but are not limited to:
    msgDSNT456i error in variable CICS release, value is 6
    msgDSNT460i value is too hig, max is 4 (for CICS)
    msgDSNT465i variable CICS release is set to 4
    msgDSNT465i error in variable SEQCACH, value is BYPASS
    msgDSNT465i values permitted are nulls or yes
    msgDSNT465i variable SEQCACH set to null
  ==============================================================
  The installation CLIST (DSNTINST or DSNTINS0) does not save
  any of the panel values until it COMPLETES successfully. At
  completion, the panel values will be saved if you specified a
  DSNTIDxx name in field 7 of panel DSNTIPA1.
  
  The CLIST can be run multiple times, however be forewarned
  that you need to change the prefix.NEW.SDSNSAMP, SDSNTEMP and
  SDSNCLST names or you will delete any previous output in these
  libraries.
  ===============================================================
  For DB2 4.1, (To be documented in the v4 Install Guide), the
  linkage editor attributes of the Call Attachment language
  interface module (DSNALI) were changed from
     AMODE(ANY)/RMODE(24)    to     AMODE(31)/RMODE(ANY).
  This allows DSNALI to be loaded above the 16MB line. So, in
  v4, DSNALI **CAN BE** loaded above OR below the 16MB line.
  NOTE: The DB2 user may request that DSNALI be LOADed below
  the 16MB line by specifying RMODE(24) during linkedit, i.e.
  //SYSLIN   DD  *
   ORDER DSNAA
   INCLUDE ADSNLOAD(DSNAA)
   INCLUDE ADSNLOAD(DSNALI)
   ENTRY DSNALI
   ALIAS DSNHLI2
   ALIAS DSNWLI2
   MODE AMODE(ANY),RMODE(24)     <====
   NAME DSNALI(R)
  ...
  Some DB2 customers were counting on DSNALI RMODE(24) to hold
  their application programs below the 16MB line. While this
  worked for many customer applications, it is really the
  responsibility of the particular installation to insure
  that their application programs are LOADed correctly above
  or below the line as they choose.
     See also II09144 (v4 Application Programming & SQL Guide)
  and II09154 (v4 Install Guide) for the documentation changes.
  ===============================================================
  MSGDSNT379I Invalid IRLM subsystem name and/or rc00C90093 for
  error in IRLM can occur when falling back from DataSharing
  mode to non-DataSharing mode of DB2 if its IRLM remains up on
  the system when the DB2 member is brought down and restarted
  after making the required changes to disable data sharing.
  
  11/06/96 - v4 migration
  ---------------------------------------
  It should be noted that the order for stopping/starting the
  catalog and directory in v4 has changed. Starting/stopping the
  catalog/directory may be necessary for some of the migration
  steps. See info apar II09565 and apar PN83190 which is
  recommended. You may need to apply the ptf for this apar before
  migrating. The recommended order is:
  NOTE: When stopping and starting these 2 databases individually
        the correct order MUST be:
        (1) STOP DB(DSNDB06)
        (2) STOP DB(DSNDB01)
         ------------------
        (3) START DB(DSNDB01)
        (4) START DB(DSNDB06)
   (Note: Install SYSADM auth is required to START db DSNDB06)
          DSNTIPP DSN6SPRM SYSADM = SPRM +x'21'
  --------------------------------------------------------------
  APAR PN78797 and new DB2 pre-compiler support
  
  NOTE: Apar PN78797 added new DB2 pre-compiler support
  for IBM OO Cobol and C++ languages. There is NO install
  support added so it is recommended to keep your current
  default language specification unless there is some reason
  a change is needed. This is set via install panel DSNTIPF.
  Apar PN78797 provides the information needed to employ the
  pre-compiler support.
  ================================================================
  03/11/97 - reported problem with edit proc DSN8EAE1 for R410
  when running IVP job DSNTEJ1
  (appears to be identical to problem mentioned in II05712 for
  prior releases of DB2).
  -------------------------------------------------------
  Users could encounter the following message if a library
  concatenation is not done for the edit proc or other modules.
    msgDSNT500i DSNUGBAC - resource unavailable
       reason rc00c9008a, type 00000240, name DSN8EAE1
  The resolution is to ensure that the DBM1 address space has
  the library containing the edit proc in a STEPLIB or is in the
  LINKLST and is compiled RENT.  This could also occur for the
  MSTR or DIST address space modules.  All 3 DB2 startup PROCs
  (xxxxMSTR, xxxxDBM1 and xxxxDIST) should have the same library
  concatenations.
  ======================================================
  05/01/98 - PLBabend106-28 abend106 rc28
  ABEND106-28 during DB2 startup following migration.
  Good chance of an authorization problem. Check your MVS DB2 PPT
  (Program Properties Table). See v4 DB2 Install Guide, pg.2-209
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• DB2INFO CatMaint stuff: pq26271 II08571 II10128 II11442
  

APAR Information

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

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

Fix information

Applicable component levels