PI67585: U0852 U4031 ABENDS AND 02 SEGMENTS WITH BINARY ZEROES FOR DATA WITH PI07353 SPE DATA CAPTURE POSITIONING 16/09/13 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DFSDDLE0 called DFSDCAP0 for an ISRT DL/I call.
  ABENDU0852 abends issued following OEM U4031 application
  abends during compression of HDAM OSAM segments. With
  compression turned off, "ghost" records (type 02 dependent
  segments with binary zeroes for data are left in database.
  With compression on, U0852 and U4031 abends are issued.
  This is an OSAM HDAM database with two data set groups having
  DSG1 blocksize = 2,048 and DSG2 blocksize = 8,182.
  D, F, L, and blank commands are used on ISRT calls.
  A Data Capture Exit is specified on 01 root and 02 segments.
  The 02 segment has the following SEGM configuration:
  RULES=(PPP,HERE),PTR=(TWINBWD,,,,),
  EXIT=((*,LOG,KEY,DATA,NOPATH,NOCASCADE))
  Recreates at the customer site and later at SVL revealed
  the source of the errors is the following:
  DMBXT(I).DMBXTFL2.DMBXTIPO in DFSDCAP0 is intended to contain
  a value for new field DMBXTIPO at offset A in the DMBXT
  block, but the logic appears to be incorrectly coded as part of
  the SPE for Data Capture Positioning Enhancement introduced
  in V13.
  R14 has been loaded with x'C', and when added to R15 (DMBXT),
  points beyond the DMBXT control block to the FDB (Field
  Descriptor Block) for the Root. At the FDB location, value x'43'
  is found  and interpreted as DMBXTFL2:
  DMBXTFL2(I) = '01000011'B  (DMBXTIPO x'40' bit ON).
  This bit incorrectly implied parm INPOS had been
  specified as one of the EXIT parms.  Of course,
  INPOS was not specified.
  This APAR is being created to resolve this
  coding error introduced by SPE APAR PI07353
  in IMS V13.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V13 Change Data Capture users        *
  *                 with Data Capture Positioning Enhancement    *
  *                 APAR PI07353 / PTF UI20034 applied.          *
  ****************************************************************
  * PROBLEM DESCRIPTION: U0852 or U4031 abends, missing records, *
  *                      and records left with binary zeros for  *
  *                      data, can occur when processing unkeyed *
  *                      or non-unique dependent segments with   *
  *                      Data Capture Positioning Enhancement    *
  *                      APAR PI07353 / PTF UI20034 applied.     *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  Change Data Capture Positioning Enhancement was introduced in
  IMS V13 to capture subset pointer (twin data) updates or
  positioning information for inserts of non-unique segments.
  If keyword INPOS is specified in the EXIT parameter of the DBD
  or SEGM statement, data from the following twin is captured on
  ISRT calls of non-unique segments with RULES=HERE, if the next
  twin exists.
  
  In this case, 02 segments were unkeyed with the following SEGM
  statement in the DBD:
  
      RULES=(PPP,HERE),PTR=(TWINBWD,,,,),
      EXIT=((*,LOG,KEY,DATA,NOPATH,NOCASCADE))
  
  Since INPOS was not specified in the EXIT, Change Data Capture
  Positioning Enhancement code in DFSDCAP0 should not execute.
  However, when DFSDDLE0 called DFSDCAP0 during an ISRT call,
  the added code was executed and caused three major problems:
  
  1. ABENDU4031 / ABENDU0852 and database corruption
  2. Cannot process more than one exit per segment
  3. Incorrect data in IMS log and DL/I trace records
  
  Problem 1:
  ----------
  IMS U0852 abends were issued following OEM U4031 application
  abends during OEM compression of HDAM OSAM segments.  With
  compression turned off, "ghost" records (02 dependent segments
  with binary zeroes for data) were left in the database.
  With compression turned on, U0852 and U4031 abends were issued.
  
  This was an OSAM HDAM database with two data set groups having
  DSG1 blocksize = 2,048 and DSG2 blocksize = 8,182. Command
  codes D, F, L, and blank were used on the ISRT calls. A single
  Data Capture Exit was specified on 01 root and 02 segments.
  
  The abends and corrupted database were caused by the following:
  DMBXT(I).DMBXTFL2.DMBXTIPO in DFSDCAP0 is intended to represent
  new field DMBXTIPO at offset x'A' in the DMBXT block.
  The (I) variable represents the Data Capture exit number when
  more than one exit routine is specified on the SEGM statement.
  The routine was entered with a residual (I) value = 2 which
  caused Data Capture Positioning Enhancement logic to add an
  additional offset of x'C'. R14 was loaded with x'C', and when
  added to R15 (DMBXT), pointed beyond the DMBXT control block
  into the FDB (Field Descriptor Block) for the root. At the FDB
  location, a value of x'43' was found and interpreted as:
  
     DMBXTFL2 = '01000011'B  (DMBXTIPO x'40' bit ON).
  
  This bit incorrectly implied keyword INPOS was specified as one
  of the EXIT parms and Data Capture Positioning Enhancement code
  was executed to locate and capture TWIN-FWD DATA. The EXIT
  clearly showed the INPOS keyword was not specified for this
  segment. Therefore, Data Capture Positioning Enhancement code
  should not execute for this segment.
  
  Problem 2:
  ----------
  DMBXT(I) or DMBXT(J), along with DMBXNXIT (number of exits),
  is used within DO loops in DFSDCAP0 to process exit parms
  based on the number of exits defined for the segment.
  This added logic was not placed inside a DO loop, therefore
  DMBXT(I) will not correctly index into DMBXARRY for the
  respective DMBXT segment exit.
  
  Problem 3:
  ----------
  Incorrect data was written in IMS Log and Trace records
  with or without INPOS specified in the Data Capture EXIT.
  IMS uses buffer information in fields PSTDATA, PSTBYTNM,
  PSTBLKNM, and PSTOFFST for buffer handling processes
  involved with logging and tracing.
  
  Change Data Capture Positioning Enhancement logic issued a
  Buffer Handler Byte Locate call that changed buffer position
  from the current segment to its twin fwd segment. PSTDATA
  then pointed to the twin data and DFSDCAP0 returned to the
  caller with this changed positioning. As a result, any IMS log
  or DL/I trace records for this DL/I call were incorrectly
  written using twin data positioning instead of the current
  segment for which space was obtained prior to calling DFSDCAP0.
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  Code in module DFSDCAP0 has been added / modified as follows
  to correct the reported problem:
  
  Problems 1 and 2 have been resolved by moving most of the
  Change Data Capture Positioning Enhancement code from its
  prior position to within the following DO loop:
  
     DO I = 1 TO DMBXARRY(SAVE_SEGCODE).DMBXNXIT;
        IF (DMBXT(I).DMBXTFL2.DMBXTIPO) &
        .
        .
  This change will allow valid detection of whether INPOS is
  specified in the Data Capture segment exit and process the
  correct number of Data Capture exits defined for the segment.
  
  Problem 3 has been resolved by saving PSTBYTNM, PSTBLKNM,
  PSTDATA, and PSTOFFST on entry to DFSDCAP0 and restoring
  to these entry values after execution of the Change Data
  Capture Positioning Enhancement code.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  PI68888 UI41416

Modules/Macros

• DFSDCAP0
  

Fix information

• Fixed component name

  IMS V13

• Fixed component ID

  5635A0400

Applicable component levels

• R300 PSY UI41416

     UP16/10/12 P F610 «

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.