PJ40779: RELFC AND TPFCS ISSUES

APAR status

• Closed as program error.

Error description

• See Problem Summary.
  

Local fix

• na
  

Problem summary

• APAR NUMBER:  PJ40779
  PRODUCT:  z/TPF
  FUNCTIONAL AREA:  POOLS
  SHIPPED IN PUT:  10
  
  ABSTRACT:
  When one ECB does multiple RELFC requests, LODIC may report
  that the system is low in available ECB resources due to
  PJ32792.
  
  PACKAGE CONTENTS:
  Source Segments:
  (C) base/cp/chsz.cpy
  (C) base/cp/cicr.cpy
  (C) base/cp/cics.cpy
  (C) base/rt/cj523.cpy
  (C) base/rt/cj723.cpy
  
  Object Only Binaries:
  None.
  
  Configuration Independent Binaries:
  (C) base/lib/libCJ00.so
  (C) base/load/CJ00.so
  (C) base/obj/cj004.o
  (C) base/obj/cj007.o
  
  Support Files:
  base/lst/cj004.lst
  base/lst/cj007.lst
  base/lst/CJ00.map
  
  OTHER BINARIES TO BUILD: YES
  (C) <sys>/load/CPS0.so
  (C) <sys>/obj/ccnucl.o
  
  COMMENTS:
  When a RELFC is done, processing goes to program CMR1 in order
  to do multiple release detection (MRD). If the RELFC default
  action for MRD is asynchronous handling, CMR1 will pass control
  of this RELFC request to a separate ECB that is in program
  CMR3. If a CMR3 ECB is already running, a buffer should be
  allocated and CMR1 added the RELFC request the buffer. The
  buffer can hold 196 RELFC requests. However, if a CMR3 ECB is
  not running, CMR1 will execute a CREEC to start a new CMR3 ECB.
  
  If one ECB is executing RELFC in a loop without giving up
  control and a CMR3 ECB is not active, every RELFC will execute
  a CREEC to CMR3. Once the first CMR3 ECB is created, a buffer
  is allocated. When the next 196 CREECs create an ECB and enter
  CMR3, the RELFC information will be added to the buffer and the
  ECB will exit. If more than 196 CREECs have been executed, the
  197th CREEC to CMR3 will allocate a separate buffer where
  subsequent CREECs to CMR3 will add their RELFC information.
  
  Two possible issues exist with this scenario. First, a process
  that does a large number of RELFCs without giving up control
  may generate a large number of CMR3 ECBs. This process should
  use a LODIC to control the number of CMR3 ECBs that are
  created. Collections support is an example of a process that
  may do a large number of RELFCs. Currently, Collections does
  execute a LODIC in the RELFC loop. However, the LODIC excludes
  checking of available ECBs. In cj523.cpy releaseRecordObject
  and in cj723.cpy releaseRecordObject "XMTHC lodic" is executed.
  This excludes checks for available ECBs.
  
  Second, when LODIC checks for available ECBs, it includes a
  count of pending ECBs. These are ECB creates (CREMC, CREEC,
  SWISC CREATE) that put their request on the ready list. If an
  ECB is in a loop doing RELFC without giving up control and a
  large number of CREECs to CMR3 are executed, the count of
  pending ECBs will be large. As a result, LODIC may report that
  the system resources are low for ECBs. However, because most
  CREECs to CMR3 will simply add to the buffer and exit, they
  should not be counted as a pending ECB. These ECBs will not
  give up control.
  
  The same issue exists with RLCHA processing. However, the
  blocking factor in RLCHA programs RLCH and CLC8 are different
  than in CMR3. In RLCH and CLC8, the buffer holds 254 entries.
  

Problem conclusion

• SOLUTION:
  Collections support has been updated. In cj523.cpy
  releaseRecordObject and in cj723.cpy releaseRecordObject,
  "XMTHC lodic" is replaced with "XMTHC lodicECB". The lodicECB
  calls includes the same checks as the previous lodic call and
  lodicECB also includes a check for ECBs. Both lodicECB and
  lodic are in cj341.cpy and both use LODIC CLASS=IBMHI. As a
  result, if releaseRecordObject determines that the number of
  ECBs is to low for LODIC CLASS=IBMHI, then releaseRecordObject
  will stop the release and return to the caller.
  
  ECB create processing and LODIC support have been updated. When
  a create is done that is scheduled to the ready list and that
  is going to program CMR3, a count of pending CMR3 ECBs is
  incremented. When the request is dispatched from the ready
  list, the count of pending CMR3 ECBs is decremented. Because
  CMR3 processing is I-stream unique, the count of pending CMR3
  ECBs is also I-stream unique.
  
  Because RLCHA processing has a similar issue, there is similar
  logic for creates that are going to programs RLCH and CLC8. A
  separate count of pending ECBs exists for RLCHA processing.
  Because RLCH and CLC8 have the same number if items in a
  buffer, there is only count of pending ECBs for RLCHA.
  
  Lastly, LODIC processing for the ECB resource has been updated.
  If LODIC determines that the ECB resource is in shutdown for
  the requested class, newly added logic adjusts the count of
  pending ECBs. The adjustment looks at the number of pending
  CMR3 ECBs on each I-stream. For each I-stream, the number of
  pending CMR3 ECBs is subtracted from the count of pending ECBs.
  Then, the number of pending CMR3 ECBs is divided by the size of
  the CMR3 buffer (196) and one is added to the quotient to get
  an adjusted number of pending CMR3 ECBs for this I-stream. This
  result is added back to the pending ECBs count. Similar logic
  is done for RLCHA pending ECBs. After the pending ECB count is
  adjusted, the LODIC check of ECB resources is executed again.
  
  The intent is to remove the CMR3 and RLCHA pending ECBs that do
  not give up control from LODIC processing of ECB resources.
  This provides a more accurate view of the current and pending
  use of ECB resources.
  
  COREQS: NO
  None.
  
  MIGRATION CONSIDERATIONS: NO
  None.
  
  BUILD COMMANDS AND INSTRUCTIONS: YES
  #maketpf commands for linux
  maketpf -f CJ00 cj004.o cj007.o
  maketpf -f CPS0 ccnucl.o
  maketpf CJ00 link TPF_VERIFY_LINK_REFS=NO
  maketpf CPS0 link
  maketpf CJ00 link
  
  UPDATED INFORMATION UNITS: NO
  None.
  
  See your IBM representative if you need additional information.
  
  DOWNLOAD INSTRUCTIONS:
  http://www.ibm.com/software/htp/tpf/maint/maintztpf.html
  
  APAR URL:
  http://www.ibm.com/software/htp/tpf/ztpfmaint/put10/PJ40779.htm
  

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

• Fixed component name

  Z/TPF

• Fixed component ID

  5748T1501

Applicable component levels

• R110 PSY

     UP