II12109: INFO ITEMS FOR IMS SYSTEMS. PRIOR II03290 NEXT II04971 *CLOSED*FOR FUTURE UPDATES SEE THE "HTTP://WWW.IBM.COM/IMS" SUPPORT PAGE

APAR status

• Closed as canceled.

Error description

• ******************** JANUARY 10, 2002 **************************
  RETAIN INFORMATION ITEMS WILL NO LONGER BE USED TO DOCUMENT
  COMMON USER ERROR INFORMATION.  THE NEW PROCESS WILL RELAY THIS
  INFORMATION VIA THE SUPPORT PAGE WITHIN THE IMS HOME WEBSITE AT
          "HTTP://WWW.IBM.COM/IMS"
  CLICK ON THE "SUPPORT" KEYWORD IN THE LEFT MENU AREA.
  ****************************************************************
   This apar is an extension of II02886, II04204, II05221,
  II05470, II07766, II08109, II08512, II08893, II09120, II09411,
  II09872, II10332, II10757, II11093, II11241, II11487, II03290,
  and II12109.  Purpose is to document common problems, diagnostic
  procedures, and/or solutions in the Systems area of IMS.
    When adding new entries, be sure to add an index item to
  briefly describe the problem symptom.  Include the description
  page number too.  When closing your description update, include
  your name and current date.  Common Search Arguments: IMSIISYS
  565515800 R600 R610
  569517609 569517611 R510 RA02 R100 R112 R012 R106 R116 R126
  568501201 568501202 568501301 R410 R102 R154 R164 R114 R122
  566540801 566540802 566540901 R310 R152 R162
  HMK6600 JMK6601 JMK6602 JMK6603 JMK6604 JMK6605
  HMK5100 JMK5102 JMK5106 JMK5164 JMK5114 JMK5112 JMK5116 JMK5126
  HMK4102 HMH4102 HMJ4102 JMH4112 JMJ4112 JMJ4122 JMK4162 JMK4152
  HMK3102 HMH3102 JMH3112 HMJ3102 JMK3112 JMK3162 JMK3152
  -----------------  PROBLEM INDEX  -----------------------------
  1. DFS1934E - DFSLOAD0 FAILED TO LOAD DFSTIME0               E1
  2. MSGASMA057E Undefined operation code for XPLDEF           E2
  3. STATUSCD ( CD ) when using CMD call                       E4
  4. Abend0c4 in DFSRLP00 after label LG4001G                  E5
  5. MSGDFS171A Security load failed RC0020                    E8
  6. /STO REG ABDUMP fails to bring down BMP                   E9
  7. msgCQS0242E CQS cqsname  FAILED STRUCTURE COPY/RECOVERY
     on an OS/390 release 2.8 system.                          E11
  8. IMS/DB2 connection broken but still shows CONN            E13
  9. CSA / ECSA still allocated after IMS shutdown             E14
  10.abendU0014 00000390 RC43000002 during CQS rebuild of MSGQ E15
  11.ABENDB78 in dependent region followed by abendU0113       E17
  12.DFSTRAG0 gets linkedited twice during stage 2 processing. E17
  13.ABENDU0390-1C at IMS startup caused by maint. mismatch    E17
  14.ABENDA78 RC(29) at IMS shutdown                           E18
  15.MSGDFS2030 with Omegamon release 500 Trace Facility       E19
  16. ABENDU3058 or ABEND0C4 due to SMB IPAGE overlay          E20
  17. VSICHAIN overlay containing DFSRTM00 address and length  E21
  18. SCDFRB flag SCDFRBAC overlay to x'00' on XRF system      E22
  19. MSGDFS2503W REASON CODE 35C with CMDSTART DB command     E23
  20. MSGDFS554A with no abend code                            E24
  21. DFSLOG42 date field description                          E25
  22. DFS2499W RC02 Multiple execution inside single job step  E27
  23. MPR may end with Return Code set to zero with TLIM=00.   E28
  XX. FUTURE UPDATES WILL BE MADE WITHIN THE IBM SUPPORT
      WEBSITE AT "WWW.IBM.COM/IMS".  THE SUPPORT OPTION IS ON
      THE LEFT MENU.  (January 10, 2002)
  

Local fix

Problem summary

• 1. MSGDFS1934E - DFSLOAD0 FAILED TO LOAD DFSTIME0
     ERROR CODE=X'02000004'.  This can be caused if service
     for UQ27652 was not processed properly which contains
     ++hold reason(action) indicating IVP jobs
     IV_B340J and IV_B350J need to be re-file tailored.
     This is followed by ABENDU0071.
     If service for UQ27652 is process via accept bypass
     applycheck (as in IVP) module DFSTIME0 is not linked into
     reslib.  This can be accomplished by re-file tailoring
     and running IV_B340J and IV_B350J.
  =================== Butterweck 12/13/99 ==================
  2. MSGASMA057E Undefined operation code for XPLDEF. The
     following request for publication update has been
     submitted to address this:
  
     SRL and title of affected IMS manual:
     Open Transaction Manager Access Guide and Reference
     SC26-8743-00
     1. The XCF Group Edit Routine Sample:
        . Remove the line of code that contains the following:
       XPLDEF
     2. The Client XCF Group-Join Processing Sample:
        a. Delete the following two lines of code after label:
           XCF_SYSPLEX_QUERY:
             L  R8,XPL
             USING XPL,R8
        b. Add the following variables after block comments for
           EQUATES/DSECTS:
             XPL_RETCODE DC    A(0)
             XPL_RSNCODE DC    A(0)
             XPL_LEN     DC    A(0)
             XPL_AREA    DC    A(0)
             XPL_ALEN    DC    A(0)
        c. Delete the line of code for XPLDEF
       3. THE Client XCF Group Leave Routine Sampee:
          . Remove the line of code that contains the following:
            XPLDEF
  ======================= Butterweck 12/17/99 ===========
  3. STATUSCD when attempting to use the CMD call.  This
     indicates the CMD call violates security.  This can
     be caused when the transaction is not set up in SMU
     properly or TRANCMD=YES is not specified on the
     SECURITY macro in stage 1 (transcmds can also be specified
     on /nre or /ere).
  ===================== Butterweck 12/31/99 ==================
  4. An abend0c4 in module DFSRLP00 after label LG4001G on the
     ST  R8,X28TNPTR-X28TNTRY(,R14) instruction. Reg08 & reg14
     contain 24bit addresses. This comes about from the
     LA  R8,8(,R1) instruction while in 24bit mode addressing.
     We get to AMODE 24 from the call to DFSICV90 after label
     LG4001C. Within DFSICV90, BMC has frontended the call to
     DFSICVD0, and within their code have left us in 24bit
     addressing. The BMC problem number is 357072 and only occurs
     on a /ERE COLDCOMM command.
  -
     If the 24bit storage noted above is key7 storage an overlay
     of this storage will occur with the following pattern:
     XXXXXXXX: YYYYYYYYY ........ ........ ........ ........
     where YYYYYYYY=XXXXXXXX+4 and the following 4 words are not
     changed. This will repeat until the end of the above page of
     storage or will continue if the following page is also key7
     storage. This can cause any of the problems that we normally
     see with corrupted ipages, such as abend0c4 or abendu3058
     during storage compression or any abend0cx where we run the
     ipage chain. This can result in the failure of any IMS that
     is running under a single MVS image.
     It is a loop under label LG4001G initializing the DFSX28TB
     table that is doing the overlay.
  ==== Fred Wiegert 01/06/2000 ==== PMR 79431,278 ============
  5. MSGDFS171A Security load failed RC0020.  Indicates
  transaction security configuration inconsistent.  This
  can occur if the SMU gen. does not cause DFSISTTx (trancmds)
  to be genarated and the IMS sysgen security macro specifies
  TRANCMD=YES and an old version of DFSISTTx exists in the
  matrix dataset.  In this case the module is found but the
  smb counts don't match thus this problem.  Removing this
  old module from matrix causes msgdfs171a RC2000 indicating
  transaction command load failure which is the real problem.
  This can be corrected by either having the SMU gen contain
  statatements for transaction security (if desired), or
  by specifying TRANCMD=NO (which is the default) in STAGE1.
  This parm can also be overridden on the restart command
  /nre or /ere (trancmds or notrancmds).
  ================ Butterweck 2/2/00 ====================
  6. User attempted to bring down a BMP with the /STO REG ABDUMP
     command. This failed and a subsequent CANCEL also failed.
     The user application (in this case P49044B  UMB201, an OEM
     product) had set up an ESTAE which had made a DL/I call.
     From the:
      IMS/ESA V6 Appl Pgm: Design Guide
      4.10 Use of STAE or ESTAE and SPIE in IMS Batch Programs
  The application program STAE/ESTAE exit routine must not
  issue DL/I calls because the original abend may have been
  caused by a problem between the application and IMS. This
  would result in recursive entry to STAE/ESTAE with
  potential loss of database integrity or in problems
  taking a checkpoint.
     The RB flow showed the BMP in DFSCPY00 in an IWAIT waiting
     for the abend processing to end. The CANCEL fails due to
     the BMP being in 'ABDUMP in progress'.
  Additional Keywords: /STOP REGION abendU0474
  ================  2/7/00  bracken ===========================
  7. msgCQS0242E CQS cqsname  FAILED STRUCTURE COPY / RECOVERY
     occurs on an OS/390 Release 2.8 system with a structure
     created on an OS/390 Release 2.6 system (RC43000002).
     OS390/r8 implements a new data structure called a PLEID.
     These datastructures are added to the structure when it
     is allocated by the R8 system.  The R6 system has a
     compatability APAR, OW37958, that will allow the r6 system
     to connect to the structure with the PLEID however it can
     not generate them.
     The PLEID is not specfically documented anywhere. It is an
     internal data structure. These items are typically not
     documented in apars. The datastructure is part of the
     system managed rebuild support. You might want to review
     the newly released CF sizer tool for help with estimating
     the size of the structures.  The tool is available on the
     parallel sysplex web page (http://www.s390.ibm.com/pso/).
       The customer came to the following:
  Conclusion: the space reserved for the PLEID is approximately
  1% of the defined SIZE of the structure.  If a full 2.6-built
  structure must be rebuilt or recovered in a 2.8 system, then
  first the CFRM policy must be redefined with a suitably larger
  structure.  If this is not done, the rebuild or recovery will
  abend, 'structure full'.
  ===================  2/8/00 bracken ==========================
  8. When a DB2/IMS connection is broken with the OPERTUNE
  product from BMC, it still shows a status of CONN in IMS.
  IMS was actually never informed that the connection had
  been severed.  The only way to end the connection is to
  STOP it from the IMS side.  Please contact BMC for details.
  =================== 2/15/00 Plaskett ==========================
  9. After IMS shutdown, CSA / ECSA is left stranded.  The storage
  is in x'40' and x'1000' byte allocations with eyecatchers
  SPD and BSOP.  MSGDFS627I was receiving indicating cleanup was
  complete.  The orphaned storage was owned by BMC UltraOpt.
  BMC explained that although the storage was obtained under IMS,
  it will not be freed until UltraOpt is shutdown.
  /CHE CMDCHE orphan ABEND878
  ===================== 02/15/00 Ostdiek 16452,111 ===============
  10. AbendU0014-00000390 RC 43000002 can occur with a rebuild
      of the Message Queue structure under the following condi-
      tions:
      1. The INITSIZE defined for the structure is a smaller per-
         cent of SIZE than the OVFLWMAX parameter.
      2. The structure has filled beyond the INITSIZE.
      3. CQS is down when the structure fails.
      The problem is that when CQS comes back up and attempts to
      rebuild the structure, it only allocates the INITSIZE for
      the rebuild. If CQS is active when the structure fails, its
      size is stored in CQS and the failure will not occur.
      Dynamic expansion is not done during rebuild processing.
  Additional Keywords: msgCQS0242E rc07020002 07020002
  ====================  03/03/00  Bracken  ======================
  11. This item is very similar to II10757 #19.  An abendB78
  occurred in a dependent region followed by abendU0113.
  R15 at abend contains 00004B2C which IMS may show as
  B78 USER 0000-B2C.  The return code from MVS is actually 2C
  (RC2C) which means the issuer of the STORAGE macro was holding
  incorrect MVS locks.  In this case we could not determine the
  issuer of the STORAGE macro, but reg12 points to EP of IBBGFR.
  Reg4 points to eyecatcher IMFSPAB.  The savearea flow at time
  of abend is DFSDLA00, IMEOPCL9.  BMC has provided fix BPI7667.
  ==================== 03/17/00 Plaskett =========================
  12.DFSTRAG0 gets linkedited twice during stage 2 processing.
  This does not cause any problems.  This occurs for releases 5.1
  and 6.1.  It will not occur in release 7.1
  ------------------03/21/2000 Tori Johnson----------------------
  13. ABENDU0390 rc1c 0000001c at IMS startup caused by
  maintenance mismatch. The fix for APAR PQ25321 was on in some
  modules, but missing in others.
  ------------------3/21/2000 Tori Johnson-----------------------
  14.ABENDA78 rc29 on IMS shutdown due to ECSA ( CSA ) storage
     being freed.  The length of the storage being freed is
     x'600' bytes.  The storage is actually freed by dfsmodu0
     when running the CDE chain and freeing associated storage.
     The cde being freed is for DPIDAVE that has a major name
     DPIMSISB.  This is a known problem with BMC's datapacker
     and is addressed by P361867 - this is corrected in base
     code for 2.4.04 and above.
     The results of this are not predectable and we have seen
     this cause abend0c4 abend378 in DB2 as a result of this
     storage being freed.
  ----------------- Butterweck 4/4/00 ----------------------------
  15. MSGDFS2030 MONITOR ALREADY ACTIVE when /TRA SET ON MONITOR
  ALL is entered.  MSGDFS2032 MONITOR NOT ACTIVE when /TRA SET
  OFF MONITOR ALL is entered.  The problem is with Omegamon
  release 500 Trace Facility.  Candle told the customer that
  the Trace Facility cannot coexist with the IMS Monitor in that
  release.  The resolution was to go back to release 400 of
  Omegamon, which did resolve this customer's problem.
  ==========================Weed 4/7/2000=========================
  16. At restart, ABENDU3058 RC0C after IMODULE DELETE at label
  FREE00 got a non-zero rc because R3 is not a valid page.  Also
  ABEND0C4 in DFSBCB60 after label COMP200 where R3 is bad.  R3
  may be 00080000 or an invalid SMB ipage address page the
  00080000 flag has been turned on (for example, 04021000 becomes
  040A1000).  The next page pointer in the ipage prefix, PRENP
  has been overlaid / overlayed.  The overlay is caused by BMC's
  Delta IMS.  The Delta 6.0.0.7 zap is 310765.
  ======================== Ostdiek 4/24/00 pmr 20241,111 =========
  17. VSAM VSI chain has been overlaid with the epa of IMS module
  DFSRTM00 and the module length 000014F8.  The overlay is
  preceded by a GXL control block with a length of x'100' bytes.
  The GXL should be x'1A0' bytes.  This bad GXL length is
  suspected of causing the VSICHAIN overlay.  The GXL was obtained
  by BMC's LOADPLUS utility.  BMC's fix tracking number is 343314.
  keywords: ABEND0C4 IDA0192A ABEND730 Load Plus
  ===================== Ostdiek 5/12/00 pmr 67646,370 ============
  18. When /SWI SYSTEM FORCE ACTIVE is entered, MSGAVM006E does
  not appear and takeover does not complete.  The LOG TCB is
  waiting out of IGC0013I to complete a CLOSE SVC14 issued from
  DFSRTM00.  There was also an active savearea flow with
  DFSCMTI0 - DFSICLC0 - DFSICA20 - DFSFLLG0 (returned).  When
  XRF is active, flag SCDFRBAC should be on and DFSFDLF0 will
  issue a CMTIAVM macro which results in a LEAVERSE to AVM.
  In this case, SCDFRBAC had been turned off so no LEAVERSE was
  done.  SCDFRB flag SCDFRBAC had been set to 00 rather than 80
  by BMC's QManager product during CMDSWI SYSTEM ACTIVE FORCE
  processing.  BMC has a fix for this problem.
  ===================== Ostdiek 5/12/00 pmr 18273,487 ===========
  19.MSGDFS2503W REASON CODE 35C may result from START DB command
  if two DBDs are in the ACBLIB which use the same DDNAME.  When
  the second database is started the DDNAME will be found to be
  allocated (by the first DBD).  Dynamic Allocation will treat
  the second allocation as a JCL allocation in this case.  If a
  DBR command is done on the second database a DYNB block will be
  built which contains the DDNAME and DSNAME of the first DBD
  to allocate the DDNAME and the second DBD name.  After the
  ACBLIB is fixed (each DBD using its own DDNAME), IMS will have
  to be re-started to clear the DYNB block before dynamic
  allocation will work as expected.
  ADDITIONAL KEYWORDS: DFS2503W RC35C DYA DSNAME
  ========== Ryan 5/23/00 pmr 18273,487 and 20259,278 ===========
  20. MSGDFS554A with no apparent abend code.  This can occur
  if we are in term thread and lcre4dli is set.  This indicates
  that term thread was entered with a prior sync point (commit)
  being done. Some modules involved are dfsdast0 dfsdsc00.
  Objectstar has a zap to correct this.
  ========= Buterweck 5/24/00 pmr 45028,999 ===============
  21. The following is a description of they high byte/bit
      in the date fields of the x'42' log record:
  In the 5.1 system BCPID:
  **   - X'00' - CHECKPOINT ISSUED ON A NON-XRF SYSTEM
  **   - X'F1' - CHECKPOINT ISSUED ON A XRF SYSTEM WITH HOTID=1
  **   - X'F2' - CHECKPOINT ISSUED ON A XRF SYSTEM WITH HOTID=2
  **  THIS CHECKPOINT INFORMATION SECTION (BCPCHKPS--->BCPCHKPE)
  **  IS LOGGED IN THE X'42' LOG RECORD AT LOCATION ATREAL
  *
  *
  In the 6.1 and above systems (BCPID):
  **  THE HI-BIT IN THE HI_BYTE OF THE CHECKPOINT-IDS BELOW MEAN:
  **     - OFF   - CHECKPOINT ISSUED ON A NON-XRF SYSTEM, OR AN
  **                    XRF SYSTEM WITH HOTID 2
  **     - ON    - CHECKPOINT ISSUED ON A XRF SYSTEM WITH HOTID 1
  **  THIS CHECKPOINT INFORMATION SECTION (BCPCHKPS--->BCPCHKPE)
  **  IS LOGGED IN THE X'42' LOG RECORD AT LOCATION ATREAL
  In all systems (DFSLOG42):
       **  REFER TO THE BCPID MACRO FOR A DESCRIPTION OF THE DATA
       **  AT LOCATION ATREAL.
  --------- Butterweck 5/31/00   pmr 03881,487,000 -------
  22. The customer runs multiple executions of an DFSBBO00
  inside a single MVS Job Step (using Batch TSO-IKJEFT01).
  Subsequent executions of DFSBBO00 were receiving message
  DFS2499W RC02 (Mixed JCL/Dynamic Allocation) when trying
  to backout multiple dataset databases.  This environment
  is not supported by IMS.  The customer was able to solve
  the problem by setting a high value for JCL Parm DYNAMNBR.
  The problem occurs as the system may automatically de-
  allocate 'not-in-use' datasets when the number of
  allocations exceeds the value set for DYNAMNBR.  If one
  dataset of a multiple dataset database is de-allocated,
  message DFS2499W RC02 will result.
  == PMR 81510 & 81511 B001 C866  C. Ryan  06/08/2000 =====
  A Message Porcessing Region (MPR) may end with Return Code ZERO
  even when termination was not expected.  This may occur in the
  following situations:
    1.  An ABEND occurs while the MPR is being initialized.
           ( RCSCHD = 'INIT' )
    2.  An ABEND which occurs when the MPR is being reinitialized
        after some transaction ABEND. ( DFSPCC20 ESTAEXIT sets
        PCENDFL FLAG x'08' in PCECB if bit RCPC1ST (X'10') is not
        set in RCFLAG, showing re-initialization.  RCPC1ST is set
        when initialization is complete. )
    NOTE: In this PMR an ABEND306-30 occured during preload.
  Under the current design, a Return Code will only be available
  in the case of an IFP Region which will show the application
  Return Code at termination.
  ======================== Ryan  07/11/2000 ====================
  

Problem conclusion

Temporary fix

Comments

• Information APAR
  

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