PJ40779: RELFC AND TPFCS ISSUES

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

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 number

    PJ40779

  • Reported component name

    Z/TPF

  • Reported component ID

    5748T1501

  • Reported release

    110

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-12-05

  • Closed date

    2013-02-15

  • Last modified date

    2013-02-15

  • 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



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

TPF
z/TPF

Software version:

110

Reference #:

PJ40779

Modified date:

2013-02-15

Translate my page

Machine Translation

Content navigation