PJ40779: RELFC AND TPFCS ISSUES
Closed as program error.
See 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.
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
Reported component name
Reported component ID
NoSpecatt / Xsystem
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
Fixed component ID
Applicable component levels
Translate this page: