OA68039: HIGH CPU IN HZSPROC ASID DUE TO LOOP IN VSM HEALTH CHECKER MODULE IGVHCHK1 BETWEEN +X'34E4' AND +X'37BC'

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• VSM health checks VSM_SQA_THRESHOLD or VSM_CSA_THRESHOLD can
  cause high CPU consumption
  in the HZSPROC address space, resulting in system performance
  issues. The high CPU in HZSPROC ASID is the result of VSM health
  
  checker code IGVHCHK1 entering a loop between offset x'34E4' and
  
  x'37BC' when the current CAUB pointer in REG7 becomes 0.
  
  The issue occurs because the health check is running the unowned
  
  CAUB queue without serialization and lacks mechanism in place to
  
  handle situations when the current CAUB got "corrupted" (e.g.
  current CAUB is removed from the queue prior to fetching the
  next unowned CAUB; the CAUB being processed is freemained prior
  to accessing the next CAUB).
  

Local fix

• Remove the health check that is driving the high CPU consumption
  
  in HZSPROC via
  
  'F HZSPROC,DELETE,CHECK=(IBMVSM,VSM_SQA_THRESHOLD)'
  
  If unsure which particular check is consuming a lot of CPU,
  restart HZSPROC to relieve the symptom.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: Users of IBM Health Checker for z/OS         *
  *                 at HBB77D0 and up                            *
  ****************************************************************
  * PROBLEM DESCRIPTION: The VSM_CSA_THRESHOLD health check may  *
  *                      cause an infinite loop in IGVHCHK1.     *
  ****************************************************************
  The VSM_CSA_THRESHOLD health check may cause an infinite loop
  in IGVHCHK1.  Part of IGVHCHK1's processing requires finding
  the 5 highest consumers of distinct categories of common
  storage.  To that end, IGVHCHK1 iterates over the unowned
  CAUB linked list without any serialization.  It is possible
  that CAUB elements could be removed from the linked list and
  freed, causing processing in IGVHCHK1 to access memory that is
  not part of the unowned queue.
  

Problem conclusion

• IGVHCHK1 is changed so that when the unowned CAUB queue is
  processed, the elements are verified to ensure that they
  really are CAUB control blocks.
  
  HCHECKER/K
  

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:

  UJ98199 UJ98200 UJ98201

Modules/Macros

• IGVHCHK1
  

Fix information

• Fixed component name

  VSM - VIRT STOR

• Fixed component ID

  5752SC1CH

Applicable component levels

• R7D0 PSY UJ98199

     UP25/10/22 P F510 ¢

• R7E0 PSY UJ98200

     UP25/10/22 P F510 ¢

• R7F0 PSY UJ98201

     UP25/10/22 P F510 ¢

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.