PH55688: DFS3702I REASON CODE=04 ON PREOPEN AFTER WARM START WHEN DEDB AREA CI SIZE CHANGED TO BE LARGER THAN ANY PREVIOUS AREA

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Customer shuts down IMS and adds new DEDB with 24K CI size to
  active directory.  There were no DEDBs with this CI size or
  larger up to this point.
  The Areas for the DEDB are registered in DBRC as PREOPEN.
  Customer warms starts IMS.
  PREOPEN runs and DBFCMOC1 gets a work buffer for DBRC Authlist.
  It requests the largest size, passing zero for DMAC address, and
  buffer size.
  The logic in DBFBPNI0 to find largest buffer size looks at all
  DBFBPND9s, but checks BPND9_flag1,BPND9_f1_avail  to see if the
  subpool has actually been created ( buffers allocated ) to see
  if size should be considered.
  In a COLD start, DBFINI2R is called and will allocate buffers
  for all buffer sizes found in ACBLIB/Directory, but for WARM
  start, it is not called, and pools are built based on 4081 log
  records in the restart checkpoint.
  So the largest buffer pool actually built in this case is 8k,
  not 24K.
  This is all OK except DBFCMOC1 passes this buffer to DBFMLOP0 in
  in EPSTIOSV, and if present, DBFMLOP0 checks this buffer size vs
  Area CI size and if buffer size is smaller, issues DFS3702I
  RSN04 and stops the Area.
  DBFCMOC1 should not pass thebuffer it gets to DBFMLOP0 in
  EPSTIOSV. The code where CALLOPEN is called, saves DMHR from
  EPSTIOSV in R3 over call, and stores it back into EPSTIOSV upon
  return, but does not clear EPSTIOSV before CALLOPEN is called.
  clear EPSTIOSV before CALLOPEN is called.
  It does not matter that the original buffer is to small because
  it is used for AUTHLIST, not DMAC read, anyway. DBFMLOP0 has
  cod in MLOPGBUF that will get a new buffer if EPSTIOSV is zero
  and pass DMAC address on the call, which will result in
  DBFBPNI0 creating the new 24k subpool and passing back a correct
  size buffer.
  

Local fix

• COLD start after adding DEDB with new, larger, CI size, or
  don't register the new Area(s) as PREOPEN in DBRC.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * IMS V15 FP 64 bit buffer manager users                       *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * DFS3702I REASON CODE=04 ON PREOPEN AFTER WARM START WHEN     *
  * DEDB AREA CI SIZE CHANGED TO BE LARGER THAN ANY PREVIOUS     *
  * AREA                                                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * INSTALL CORRECTIVE SERVICE FOR APAR/PTF                      *
  ****************************************************************
  Customer shuts down IMS and adds new DEDB with 24K CI size to
  active directory.  There were no DEDBs with this CI size or
  larger up to this point.
  The Areas for the DEDB are registered in DBRC as PREOPEN.
  Customer warms starts IMS.
  PREOPEN runs and DBFCMOC1 gets a work buffer for DBRC Authlist.
  It requests the largest size, passing zero for DMAC address, and
  buffer size.
  The logic in DBFBPNI0 to find largest buffer size looks at all
  DBFBPND9s, but checks BPND9_flag1,BPND9_f1_avail  to see if the
  subpool has actually been created ( buffers allocated ) to see
  if size should be considered.
  In a COLD start, DBFINI25 is called and will allocate buffers
  for all buffer sizes found in ACBLIB/Directory, but for WARM
  start, it is not called, and pools are built based on 4081 log
  records in the restart checkpoint.
  So the largest buffer pool actually built in this case is 8k, no
  24K.
  This is all OK except DBFCMOC1 passes this buffer to DBFMLOP0 in
  EPSTIOSV, and if present, DBFMLOP0 checks this buffer size vs
  Area CI size and if buffer size is smaller, issues DFS3702I
  RSN04 and stops the Area.
  I think the fix for this is simple. DBFCMOC1 should not pass the
  buffer it gets to DBFMLOP0. The code where CALLOPEN is called,
  saves DMHR from EPSTIOSV in R3 over call, and stores it back
  into EPSTIOSV upon return, but does not
  clear EPSTIOSV before CALLOPEN is called.
  

Problem conclusion

• DBFMLOP0
  
  Added code to check incoming DMHRBLKL of DMHR and DMACBLKL and
  to get new DMHR of length DMACBLKL when the incoming DMHRBLKL is
  smaller than DMACBLKL.
  
  DBFNRST0
  
  Fixed NRSTDMHR routine to store length of DMHR in DMHRBLKL
  

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:

  UI95490

Modules/Macros

• DBFMLOP0 DBFNRST0
  

Fix information

• Fixed component name

  IMS V15

• Fixed component ID

  5635A0600

Applicable component levels

• R500 PSY UI95490

     UP24/02/02 P F402

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.