PH46071: DFSDDLT0 WITH PROCOPT=L GETS A U0255 SINCE Z/OS 2.5 UPGRADE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• We have recreated the U0255 abend using our DBDs , PSBs and JCL.
  We then changed PSB from PROCOPT=L to PROCOPT=A the LOAD works
  successfully.
  
  
  +DFS0730I UNABLE TO OPEN  DATA SET WITH DDNAME ........ FOR
  REASON I,20,
  
  The problem is triggered in DFSDOC10 when address 0 used to be
  X'000A0000' and now it's X'00000000' when upgrading to z/os 2.5.
  
  
  MSGDFS0730I ABENDU0255
  

Local fix

• As a workaround, please change PSB from PROCOPT=L to PROCOPT=A.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All IMS V15 users of z/OS 2.5 and HALDB with Secondary       *
  * Indexing and using PCBs with PROCOPT=L.                      *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * When migrating to z/OS 2.5, dependent region abend U0255 and *
  * message DFS0730I REASON I,20 will occur when loading a HALDB *
  * with Secondary Indexing and using a load PCB with PROCOPT=L. *
  *                                                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * INSTALL CORRECTIVE SERVICE FOR APAR/PTF                      *
  ****************************************************************
  A dependent region abends with U0255 and message DFS0730I REASON
  I,20 is returned in module DFSDOC10. An incorrect assumption is
  made in module DFSDOC10 after label PHIDMLD when an RPLI area
  address exists in field RPLAREA. When RPLAREA address exists in
  the RPLA control block the assumption is that storage area
  PHIDAMLD will exist, and the correct address is in field
  PSTOCRPL. This results in skipping a getmain call for area
  PHIDAMLD after label PHIDMGET but using field PSTOCRPL as the
  getmain'ed area address. This results in using a 0 value in
  field PSTOCRPL as an address. Using 0 as the address causes code
  after label PHIDMCON to access low core to obtain the length of
  the getmain area size. A compare is made after label PHIDMCON
  with the value from low core with the logical record length
  DMBPFPLR. If the low core value is less than DMBPFPLR then a
  freemain for area PHIDAMLD is issued after label PHIDMDEL. In
  the reported problem, low core value is x'FFFFFFFF' in R0 and is
  compared with DMBPFPLR. During freemain we attempt to free area
  PHIDAMLD with a size of x'FFFFFFFF' and IMODULE delete returns
  RC=8. Then branch to label PHIDAMERR and message DFS0730I REASON
  I,20 is returned. This problem surfaced when using z/OS 2.5 due
  to low core values that are different in prior versions of z/OS.
  This problem can also occur in prior versions of z/OS depending
  on values in low core.
  
  Additional keywords: ABENDU0255
  

Problem conclusion

• DFSDOC10
  Module DFSDOC10 is changed after label PHIDMLD to issue a
  getmain for area PHIDAMLD if RPLAREA address is zero or if
  PSTOCRPL is zero.
  

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:

  UI90489

Modules/Macros

• DFSDOC10
  

Fix information

• Fixed component name

  IMS V15

• Fixed component ID

  5635A0600

Applicable component levels

• R500 PSY UI90489

     UP23/02/11 P F302

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.