II05712: DB2: COMMON INSTALL AND MIGRATION PROBLEMS 5740XYR00 R302 R210 R220 R230 R310

APAR status

• Closed as canceled.

Error description

• This info apar was opened to document common problems in
  DB2 install and migration.
  ----------
  Clist DSNTINST DSNTINS1 DSNTINS2 Text not found - diagnosis
  and resolution can be found in APAR PL85894, or II08296.
  The "text not found" message received during DSNTINST indicates
  the IBM target libraries DSNCLIST or DSNSAMP have been modified.
  If these libraries have been manually edited, they need to be
  restored to their original state.
  ----------
  R230 or R310, section completing the CLIST processing could
  return a misleading message - msgIKJ52304i after issuing
  msgDSNT478i beginning edited dataset output.  The IKJ52304i
  message had RC4714 or RC0218.  Although this indicates an
  allocation failure - it could be an out of space condition.
  Check all related volumes for space restrictions or security
  violations.  Check directory blocks (space & authority), pack
  mounted private, user not authorized for all packs in the
  stogroup or SMS group, TSO id temporary datasets
  (space & authority) and UADS.
  ----------------
  On panel DSNTIPA1, you must list DSNTIDXA in field 6 (input
  member name) the FIRST time you migrate or install.  DSNTIDXA
  contains the default values for all panel parameters and
  contains required data used by the install CLIST. If migrating,
  your previous releases DSNTIDxx member info. will override the
  defaults when appropriate. If you do NOT use DSNTIDXA on the
  first migrate or install, you will receive unpredicable
  results and strange error messages.
  --------------
  For migrating from R220 to R230   (see PN25700)
  Migration job DSNTIJTC - various ABENDS including RC00E40601
  RC00C90211 - General function and problem information follows.
  NOTE: For DB2 Install/migration (i.e. v230 to v310), many of
  the jobs are critical and need to complete. It may be necessary
  to alter and/or include the TIME parameter for the job so that
  enough time is allowed for the job to complete. It has been
  reported for example that if the DSNTIJTC job time's out, that
  a recover of the catalog may be necessary. If no TIME is
  specified, the system default (which may not be appropriate) is
  used. You may need to consider adding TIME=1440 or
  TIME=NOLIMIT. For further information see MVS/ESA JCL Reference
  regarding the JOB statement's TIME parameter.
  
  Functions performed by DSNTIJTC:
  DSNUPROC is called and passed the following three statements:
      CATMAINT UPDATE
      RECOVER INDEX (SYSIBM.DSNDTX02, SYSIBM.DSNATX02)
      CATMAINT UPDATE UNLDDN SYSREC
  1) The first CATMAINT UPDATE alters SYSIBM.SYSTABAUTH to add
     four columns, add index DSNDTX02 and DROP/CREATE index
     DSNATX02.
  2) The RECOVER INDEX recovers the two modified indexes.
  3) The last CATMAINT UPDATE (in the first job step, DSNTITC)
     makes other changes in the catalog and creates the new
     tables and indexes for R230.  Lastly, it unloads the
     SYSIBM.SYSGPAUT tablespace into the data set on the
     SYSREC DD card.
  
  If the SYSREC file output from the second CATMAINT call is
  lost, the catalog must be reloaded, and the migration jobs
  run again.  Once this second CATMAINT has been run to good
  eoj, it cannot be rerun.  Error message MSGDSNU766I CATALOG
  HAS ALREADY BEEN MIGRATED   NO ACTION WILL BE TAKEN
  will be produced if a rerun is attempted.
  This error message is produced if there is a row in SYSCOLUMNS
  for a column called NAME for SYSPACKAGE.  SYSPACKAGE
  is added in the middle of the second CATMAINT step.  The
  program assumes that if the row is present, the job
  completed successfully.
  To determine if this row is present, use SPUFI to do the
  following select:
   SELECT * FROM SYSIBM.SYSCOLUMNS
      WHERE NAME='NAME' AND TBNAME='SYSPACKAGE'  ;
  ----------
  MSGDSNU008I DSNUGBAC - Specified user failed validity check
  followed by MSGDSNU012I DSNUGBAC Utility execution terminated
  highest return code=08, when running migration step 22, job
  DSNTIJTC. The DB2 environment is not defined to the security
  package, see DSSC flashes 1182 and 2122 for additional
  explanation and information.
  DSNU008I DSNU012I rc08
  ----------------------
  For migrating R220 to R230
  When dsntijtc fails during the first step of the job, step
  DSNTITC, Catmaint Utility, a 'fallback' is often required.
  The steps for fallback is documented on page 2-204 of the DB2
  Administration Guide.
  
  Once the user is back on 2.2, you can use the following steps
  to recover the catalog.
    1) Recover each catalog tablespace using the 'to copy' parm.
       Also use the Recover utility to recover the indexes.
       There is a specific order and procedure that the catalogs
       and directory should be recovered. The steps are
       documented in the DB2 Administration Guide, Operations
       and Recovery Section page 6-119.
    2) Run DSN1CHKR and DSN1COPY/CHECK against the catalog
       tablespaces.
    3) Delete the new data sets allocated by DSNTIJIN and
       DSNTIJID. You can use DSNTIJDE to delete the data sets
       but make sure you examine the jcl in the job. You only
       want to delete the new 2.3 data sets.
    4) Re-run DSNTIJUZ (This will re-create the zparm and reformat
       the bsds back to 2.3)
    5) Re-run DSNTIJIN and DSNTIJID
    6) Start DB2 2.3
    7) Run DSNTIJTC to migrate the catalogs again.
       (Again, this is only done if DSNTIJTC failed, and did
        not complete with condition code zero.)
    8) Continue with the migration at step 23
  --------------------------------------------------------------
  For R220 to R230 migration
   Problems may be encountered running CATMAINT.  The table below
   describes the problem and the fix, by refresh level/quest.
   Quest 5 (December 1991 Refresh), Quest 6 (March 1992 Refresh).
   Quest 6 Mar GA means the base DB2 v2.3 code.  If listed on a
   PTF this means install PTF unless you have early support code.
   Please see the text in the APARs listed below for a detail
   description of the problem.
  ------- -------  ------- ------- -------------------------------
  
  Apar Q5 On DLL   APAR Q6 On DLL  Description
  ------- -------  ------- ------- -------------------------------
  PN14409 PN14409  PN15516 UN16633 KYE2222 ABEND RC00E40601 in
                                   DSNUEXDL if DSNTIJTC was run
                                   more than once.  RC00C90211
                                   RC00C900A6 RC00C902xx on
                                   SYSRESAUTH or SYSGPAUT
  PN14019 PN14019  PN15549 UN16637 KYE2212 ABEND04E RC00C90101
                                   VRACE5005 TYPE302 DSNDB06.
                                   SYSPLAN DSNICUMR x'A97' on
                                   SYSRESAUTH and it's INDEXES
  PN15358 AN15358  PN16356 UN17594 ABENDOC4 DSNUGXMA x'284'
                                   in Quest 5.  Offset is
                                   x'26C' in Quest 6.
                                   UN14335 is applied
  PN12484 BN12484  PN16119 UN18705 RC00E40601 DSNUECMI x'1B1A'
                                   ABEND04E
  --------------
  
    Migration job DSNTIJTC  performs DDL that will cause any plans
  containing static SQL referencing the objects to be invalidated
  (set for auto-rebind (autobind)):
  
       Tables:                        Index:
     sysibm.sysdatabase
     sysibm.systables
    (sysibm.systabauth)            sysibm.dsnatx02
     sysibm.sysplan
  --------------
  
  MSGDSNT418I SQLEXT=x'404040F0' encountered running R220 IVPs
  on a R230 system.  The R220 version of DSNTIAR, the SQL
  message formatter, is expecting the SQLCA in the 2.2 format.
  The system returned the SQLCA in the 2.3 format.  The 2.2
  DSNTIAR does not recognize the data in the field and produces
  the MSGDSNT418I message.  This can be ignored as long as the
  SQLCODE000 SQLCODE = 000. Additional keyword DSNTIAD.
  --------------
  ABEND04E DSNUTILA.DSNUEXD2 x'9F4' x'09F4' RC00E40601
  MSGDSNT501I Resource Unavailable DSNDB06.DSNSSX01
  Dump not produced.  Dump data sets empty.  Dump not
  supressed by DAE.
  Problem is caused by errors in DSNTIJIN or DSNTIJID.
  These two jobs should have been produced from the install
  clist run in MIGRATE mode.  The clist tailors the jobs to
  add and initialize the tablespaces new to R230.  If the jobs
  aren't run, or encountered errors, the abend listed above
  will occur.
  --------------
  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.
  ----------------
  DB2 R230, APAR PN30090 introduced new load module DSNCCOM0 for
  use with CICS PLT processing.
  If CICS V2, DSNCCOM0 is recommended but DSNCCOM1 can be used.
  If CICS V3, DSNCCOM0 must be used.
  ----------------
  DSNTIAUL can NOT handle 3 part names, nor aliases of tables
  with 3 part names.  If using an alias of a table with a 3
  part name you will receive SQLcode199 (-199) msgDSNT408i.
  Additional keyword:  SQLCODE -199
  ----------------11-14-95
  Migrating from DB2 v2.3 to v3.1
  Some customers upon migration run a job stream which STOPS and
  STARTS DB2 system DATABASES for purposes of creating IMAGE
  copies. As an example, in the first step certain DATABASES are
  STARTED in an access mode of RO. Also, -STOP DATABASE (DSNDB01)
  SPACENAM(SYSUTILX) is stopped and restarted in ACCESS (UT)
  mode. A problem occurred when command -STOP DATABASE (DSNDB06)
  SPACENAM(SYSCOPY) was issued. The problem occurred because this
  command in this job was issued from TSO batch which didn't have
  the proper authority (INSTALL SYSADM) to issue the command.
  This resulted in a hang of the TSO batch connection with SYSCOPY
  This is being documented here and is also mentioned in
  information apar II07352 because of an invalid authority
  problem with a vendor product. It should also be noted here
  that this procedure of STARTING and STOPPING DATABASES for the
  purposes of IMAGE copies is no longer necessary because of
  SHRLEVEL reference. It appears that this job originated
  prior to the SHRLEVEL function of DB2 v2.3.
  The next several steps of the job performed the image copies
  followed by another step which restarted the DATABASES with
  RW access.
  -----------------11-14-95
  After installing a new release of MVS, customer received
  msgDSNC016i when starting CICS/DB2 attachment facility with
  Abend04E and RC00C30007.  Batch CAF applications received
  Abend04E RC00C50103.  This problem was caused by customer
  moving JES2 from the first entry in parmlib member IEFSSNxx.
  DB2 Admin. Guide under install job DSNTIJMV, topic updates to
  SYS1.PARMLIB states JES must be the first line in the IEFSSNxx
  member.
  ----------------12-28-95----------
  Migration job DSNTIJTC step 18 gets Abend04E RC00e40020.
  This could be caused by DSNAPRHX issuing RC00F3001 because
  the home and primary ASIDs don't match. Or this could be
  caused by the DB2 affinity number not matching.  The DB2
  ERLY block lists the IEFSSNxx members and the number and type
  must match the SCOM list of IEFSSNxx members. Some OEM products
  can add an IEFSSNxx member to the SSVT which is recorded in the
  DB2 SCOM but not the DB2 ERLY block, causing the DB2 affinity
  number not to match.  Or this could be caused by the IEFSSNxx
  member missing line numbering in columns 72-80.
  ---------02/14/96------R310------------
  Potential JCL error msgIEF702I SYSCOPY UNABLE TO ALLOCATE in
  job DSNTEJ1 step PH01S19 and job DSNTEJ2A step UNLOAD because
  DSNTINST CLIST generates the UNIT parameter incorrectly for new
  permanent datasets. (Clist uses the temporary dataset parms)
  Customers may need to change the UNIT parameter to a value
  that is valid for permanent datasets before running these jobs.
  

Local fix

• ----New Installs only----
  When running install step 22 - DSNTIJTM to define temporary
  work files in DSNDB07 expect ABEND04E RC00C90101 during the
  job.  This abend can be ignored.
  DSNTIJTM (explained in Admin. Guide pages 2-181 & 2-182)
  will complete successfully even thought the ABEND04E does
  occur.  On a first time installation of DB2, DSNTIJTM will
  try to DROP DATABASE DSNDB07 which does not exist yet.  This
  DDL is processed by Data Manager which calls DSNILDBD to locate
  the DBD in the EDM pool.  Since the DBD does not exist, the
  ABEND04E occurs.  Looking at the dump title provides the
  failing module name and erqual5004.  Only in this circumstance
  (DSNDB07 does not exist when running DSNTIJTM on an initial
  install) can the abend be ignored.
  

Problem summary

Problem conclusion

Temporary fix

Comments

• CLOSED FOR DB2INFO RETENTION.
  

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