II13617: INFORMATION PERTAINING TO DB2 FOR OS/390 AND Z/OS UTILITIES. R610 R710 R810 R910 RA10 RB10 RC10

APAR status

• Closed as canceled.

Error description

• Information pertaining to DB2 for OS/390 and z/OS Utilities.
  R610 R710 R810 R910 RA10 RB10 RC10
  -----------------------------------------------------------
  ****************************** 06/19/2003 ****** DGH ******
  MSGIGD17051I ALLOCATION FAILED FOR DATA SET xxx,
  PRIMARY SPACE EXCEEDS 65535 TRKS
    Users running DB2 utilities with TEMPLATE may receive
  IGD17051I if the size DB2 calculates for the primary
  quantity of the dataset exceeds 65535 trks.  Depending
  on the expected size of the dataset, the DB2 page size
  of the target object, and/or the total size of (amount
  of data in) the object, the calculation could be correct
  but this message could be received anyway, failing the
  job.  This is not a defect.  In this case users are
  advised that they should utilize one of the following
  options:
   1) Define the dataset using the SMS Extended Sequential
  methodology.  Datasets defined this way are not limited
  to a primary quantity of 65535 trks.  Please refer to the
  appropriate IBM documentation for more information.
   2) On the TEMPLATE statement, specify an explicit primary
  and secondary quantity using the SPACE parameter.
   3) On the TEMPLATE statement, limit the primary quantity
  request by specifying either MAXPRIME or PCTPRIME.
  ****  UPDATE 6/30/2005  ****
    There is now a fix available which may help users
  experiencing this problem.  Users are advised to
  apply apar PQ98622 and should read the text of this
  apar for more details.
  ***********************************************************
  ******************************** 1/3/2006 ***** DGH *******
  MSGIEC070I 104(004) or 034(004)-220
  MSGDSN1992I VSAM PUT ERROR RPLERREG 008 RPLERRCD 028
  when using DSN1COPY on a VSAM object greater than
  4 gigabytes.
  Recommendation: both source and target objects should
  use extended addressability ( EA ).  If that is not
  possible, one of the following workarounds can be used:
  
  A1. Create the target data set using EA (extended architecture).
  DSN1COPY can then be used, one piece at a time, to copy the
  data from the non-EA source to the target.
  
  If this is not possible (due to unavailability of EA), or
  does not work (due to data or other problems), then an
  alternate procedure is available.
  B1. Take a full image copy of the entire source
  object (DSNUM ALL).
  B2. Allocate the target object with DSSIZE 2G.
  B3. Define A002, A003, etc. datasets with IDCAMS
  (each 2G).  Define enough pieces to hold the entire
  source.
  B4. Run DSN1COPY with the image copy as the source
  (SYSUT1) and the target object as SYSUT2.  Use the
  DSSIZE (2G) parm.
  
  This will limit each piece to 2G so the target
  object will have more pieces than the original source.
  ***********************************************************
  ******************************** 4/9/2008 ***** DGH *******
  Slow Performance of Copy Utility in certain situations.
  Users are advised that slower than expected performance may
  be seen with Image Copy utility when all of the following
  are true:
  1) SHRLEVEL CHANGE is specified.
  2) OPTIONS EVENT (ITEMERROR,SKIP) is specified.
  3) The environment is data sharing.
  4) SYSUTILX is Group Bufferpool Dependent.
  5) Copy is run on a very large list of objects.  (An exact
   number is not defined here but generally, the larger the
   list, the greater the impact.)
  6) Many of the objects on the list have a large number of
   pages to be copied.  (Neither an exact number of pages nor
   an exact number of objects in this category are defined
   here but generally, the larger the number of pages to be
   copied per object and the larger the number of objects
   in this category, the greater the impact.)
  ...............
    In this scenario the apparent poor performance is not
  due to a code error but is working as designed due to the
  way Copy utility works when the above conditions are true.
  If performance relief is required under these conditions,
  one or more of the following operational bypasses is
  recommended, depending on the user's needs:
  1) specify SHRLEVEL REFERENCE.
  2) specify OPTIONS EVENT (ITEMERROR,HALT).
  3) make SYSUTILX non-GBP dependent when Copy is run.
  4) decrease the size of the list of objects being copied.
  ***********************************************************
  ******************************** 3/14/2014 **** DGH *******
  Special information pertaining to MODIFY RECOVERY utility
  in DB2 9 for z/OS New Function Mode (NFM) or above:
  A DB2 user running in a highly specialized environment
  encountered a case in which MODIFY RECOVERY does not yield
  the results that are described in the DB2 documentation.
  For reference, the scenario is described here.
  The user ran MODIFY RECOVERY utility with an AGE or DATE
  specification for which no SYSCOPY records met the
  deletion criteria but some SYSLGRNX records did.  DB2
  documentation suggests that the SYSLGRNX records older
  than the AGE or DATE specified on the MODIFY RECOVERY
  statement will be deleted.  In this user's case they were
  not deleted because all of the records in SYSLGRNX were
  created prior to migration to DB2 9 NFM, and the MODIFY
  was run after such a migration, and no updates, hence no
  new SYSLGRNX records, were made after the migration up
  until the time of the MODIFY job.  The user environment
  was non-data sharing, and in non-data sharing SYSLGRNX
  records created prior to V9 NFM are interpreted by DB2
  slightly differently from those created after.  While DB2
  generally supports transitional states in which both kinds
  of records exist in SYSLGRNX after a migration to or beyond
  V9 NFM, this scenario involving only pre-migration SYSLGRNX
  records, no image copies, post-migration MODIFY RECOVERY,
  in a non-DS enviroment, did not yield the expected results.
  Users in such a scenario who wish to delete older SYSLGRNX
  records must use an alternate means or alter their
  scenario.  As an example, you can use REPAIR LEVELID to
  create a new SYSLGRNX record, followed by MODIFY RECOVERY
  with DATE(*) or AGE(*) and a COPY FULL YES .
  ***********************************************************
  ******************************** 11/28/2014 **** DGOR******
  A user wanted to know the status of utilities by querying
  SYSIBM.SYSUTIL table; though he realized that the content of
  USUSTATU field was not correct all the times.
  With DB2 V10 and above the field USUSTATU is no longer
  maintained and its use is only internal to DB2.
  To know the status of the utility the user should issue a
  -DISPLAY UTILITY command or use ADMIN_COMMAND_DB2 Stored
  procedure with 'UT' value as processing-type .
  
  ===========================================================
  ******************************** 08/11/2016 **** DGOR******
  When reorganizing DSNDB06.SYSTSIPT using REORG SHRLEVEL
  NONE in DB2 V11 to convert it to extended lrsn, the utility
  gets an abend04E with RC00E400E4 in DSNUGTRF +1896.
  SYSIBM.SYSTSIPT is the catalog table space containing
  SYSIBM.SYSINDEXPART, which itself is updated when an index is
  converted between basic and extended page format.
  The failing job is a REORG TABLESPACE SHRLEVEL NONE, and the
  failing point is at the end of the RELOAD phase, when it tries
  to perform the catalog/obd
  updates.
  Because this is SHRLEVEL NONE, at the end of the RELOAD phase
  it has reformatted the target indexes (i.e. the index defined
  on SYSINDEXPART , DSNDRX01), but it has not rebuilt this index
  yet since the SORT/BUILD/SORTBLD phase has not happened.
  This is current design of REORG SHRLEVEL NONE .
  REORG SHRLEVEL NONE is not suited for reorganizing catalog
  objects as any failure would result in leaving the objects
  in RECP/RBDP which is not desirable for the catalog.
  IBM recommends to run REORG SHRLEVEL REFERENCE/CHANGE on the
  catalog objects to workaround this issue and to avoid leaving
  the catalog in a restricted state.
  =============================================================
  ******************************** 03/16/2021 **** DGOR******
  After migrating to Db2 12 FL509, REPAIR CATALOG users may
  receive the following message:
  DSNU674I - COMPRESSION USED FOR DBID=X'xxxx' PSID=X'xxxx'IN THE
  DB2 CATALOG IS UNKNOWN, BUT IN THE PAGE SET IS UNCOMPRESSED.
  The Db2 catalog column COMPRESS_USED in SYSIBM.SYSTABLEPART,
  represents the current compression used by the pageset.
  For pagesets created prior to FL509, this new catalog field is
  not set. When running REPAIR CATALOG at FL509 or higher, it
  would identify this mismatch (or more correctly, this
  unpopulated field with default null value) and report it as
  a mismatch by issuing DSNU674I, which is generally accompanied
  by RC4.
  Subsequent utility operations such as LOAD, REORG, RUNSTATS,
  RECOVER or REPAIR CATALOG would attempt to update this catalog
  column with the correct value with no other required
  parameters.
  ===============================================================
  

Local fix

Problem summary

Problem conclusion

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:

Fix information

Applicable component levels