PJ41484: ZRECP OFLMR DISPLAY IS INCORRECT IF THE SSU IS INCLUDED IN THE CA RECORD.

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

  • Customer has a local fix installed.
    

Problem summary

  • APAR NUMBER:  PJ41484
    PRODUCT:  z/TPF
    FUNCTIONAL AREA:  RECOUP
    SHIPPED IN PUT:  10
    ABSTRACT:
    With PJ31430, if the SSU name is included in pool release
    logging on a loosely coupled system, the in-core CA block is
    not copied correctly during recoup.
    PACKAGE CONTENTS:
    Source Segments:
    (C) base/cp/cceh.cpy
    
    Object Only Binaries:
    None.
    
    Configuration Independent Binaries:
    None.
    
    Support Files:
    None.
    
    OTHER BINARIES TO BUILD: YES
    (C) <sys>/obj/ccenbk.o
    (C) <sys>/load/CPS0.so
    
    COMMENTS:
    In TPF system that is genned with loosely coupled support,
    transfer vector BKP6 in segment BKP5 is called to switch FC33
    records at the start and end of recoup phase 1. Prior to each
    FC33 switch, BKP6 copies the in-core CA block and passes the
    copy to BLOG. BLOG files the copy of the CA block and chains it
    to the current FC33 record. When making a copy of the CA block,
    BKP6 only copies the portion of the CA block that contains
    valid data. It uses the item count in ICY4CNT or ICY4CNT2 to
    determine the number of valid return items in the block and the
    flags in ICY4IND or ICY4IND2 to determine the item size.
    APAR P31430 added a new flag (ICY4SSU) and increased the item
    size to accommodate the subsystem user (SSU) name in each item.
    BKP6 was not updated to test this new flag or use the new item
    size. When the SSU name is included in each pool release item,
    BKP6 uses 16 bytes for each item instead of 20 bytes and does
    not copy all of the pool release data from the in-core CA block.
    Because some of the pool release data is not copied from the
    in-core CA block, some pool addresses that were returned are
    lost and will be returned as lost by recoup. In addition, the
    count in the CA block still reflects the correct number of
    returns before the CA block was copied. However, one or more of
    those items in the copied CA block are binary zero which recoup
    will interpret as offline multiple releases and may be
    displayed as invalid pool addresses (X'FFFFFFFFFFFFFFFF') in
    the ZRECP OFLMR display.
    

Problem conclusion

Temporary fix

Comments

APAR Information

  • APAR number

    PJ41484

  • Reported component name

    Z/TPF

  • Reported component ID

    5748T1501

  • Reported release

    110

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-08-29

  • Closed date

    2013-09-23

  • Last modified date

    2013-10-07

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Modules/Macros

  •    None
    none
    

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 #:

PJ41484

Modified date:

2013-10-07

Translate my page

Machine Translation

Content navigation