IBM Support

VM66418: PEVM66332 SHUTDOWN WITH REIPL TAKES TOO LONG 22/05/18 PTF PECHANGE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Completion of the CP SHUTDOWN command with the REIPL option is
    taking longer than it did previously.
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of z/VM SHUTDOWN REIPL command     *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    ****************************************************************
    * RECOMMENDATION: APPLY PTF                                    *
    ****************************************************************
    After applying Apar VM66332, the SHUTDOWN REIPL process takes
    longer.  The customer observed that during a SHUTDOWN with
    REIPL, after the display of message:  "HCPWRP963I SHUTDOWN STEP
    MTORS - RESET THE CONFIGURATION", the system experiences
    delays of varying length.  Usually, the delay is unnoticeable.
    In some cases a delay of 1 to 2 minutes occurs and delays of
    3 to 5 minutes have been seen.  With prior versions of zVM,
    the delay was only a few seconds.
    
    After doing some problem analysis, we determined that code
    added to HCPBOU and HCPLOD by VM66332 was the cause of the
    delay.  Prior to VM66332, these modules determined the size of
    storage below 2 GB by issuing an ISKE instruction to every page
    until the ISKE failed or 2 GB was reached.  Apar VM66332
    changed the code to use a load (L) instruction in order not to
    use an instruction that references the storage key of each
    page.  But the change causes each page under 2 GB to be
    referenced, which puts a storage demand on the CEC, which
    causes the delay.
    

Problem conclusion

  • PEVM66332 - HCPBOU, HCPLOD and HCPSAL have been changed so the
    loop will look at the last page of each megabyte, up to 2 GB,
    and use that to determine the highest storage address that
    they will use.  This change results in the loop executing once
    for each megabyte, instead of 256 times.
    

Temporary fix

  • FOR RELEASE VM/ESACP/ESAR710 :
    PREREQ: VM66332
    CO-REQ: NONE
    IF-REQ: NONE
    FOR RELEASE VM/ESA CP/ESA R720 :
    PREREQ: NONE
    CO-REQ: NONE
    IF-REQ: NONE
    

Comments

APAR Information

  • APAR number

    VM66418

  • Reported component name

    VM CP

  • Reported component ID

    568411202

  • Reported release

    720

  • Status

    CLOSED PER

  • PE

    YesPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-07-23

  • Closed date

    2022-06-07

  • Last modified date

    2023-07-12

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

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

    UM35981 UM35982

Modules/Macros

  • HCPBOU   HCPLOD   HCPSAL
    

Fix information

  • Fixed component name

    VM CP

  • Fixed component ID

    568411202

Applicable component levels

  • R710 PSY UM35981

       UP22/06/15 P 2201 {

  • R720 PSY UM35982

       UP22/06/15 P 2301 {

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.

[{"Business Unit":{"code":"BU011","label":"Systems - zSystems software"},"Product":{"code":"SG27M"},"Platform":[{"code":"PF054","label":"z Systems"}],"Version":"720"}]

Document Information

Modified date:
12 July 2023