ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

VMSECURE ADMIN PROFILE command slow

book

Article ID: 132589

calendar_today

Updated On:

Products

VM:Secure for z/VM

Issue/Introduction

We have a large PROFILE that has 11337 records of which 6108 are LINKs and 5229 are comments.
When using VMSECURE ADMIN PROFILE - the FILE process takes 5 minutes.
A dynamic rebuild occurs during this save. I see CPU utilization of up to 60% of one engine during the save.

Q ALLOC DRCT shows:

EXTENT EXTENT % VOLID RDEV START END TOTAL IN USE HIGH USED ------ ---- ---------- ----------
------ ------ ------ ---- xxxxxx hhhh 1 60 60 22 44 36% ACTIVE ------ ------ ---- SUMMARY 60 22 36% CKD


Do you have any suggestions on how to get ADMIN PROFILE to run faster?

Cause



 

Environment

CA VM:Secure (TM) Version 03.2 RSU-1801
z/VM Version 7 Release 1.0, service level 1801 running in LPAR on a 2965-N20 D02
(Two engines running about 75% CPU utilization each). LPAR has highest priority on box.

Resolution

When an ADMIN PROFILE is performed every directory entry that uses that profile is updated to the online directory.  Additionally, the product has to make sure the new PROFILE contents will work with all the users so there is some duplication of processing going on to make sure it all works in the end.

How many entries use that PROFILE in an INCLUDE?
VMXEXC257I gives the number of users being updated when ADMIN PROFILE is run.
Not only are all the entries rewritten to the object directory but there are control block updates that must be done internally as well.

We can't explain though why so much CPU is being used by the process.
What is your normal CPU usage and how high does it get during this process?  Can you specifically attribute the CPU usage to VMSECURE? 

We would be interested in seeing some INDICATE USER VMSECURE EXPANDED output of VMSECURE before you start the ADMIN PROFILE and during the process (before, during a couple times then again once the process completes). 

Also, are the source and object directory on different DASD?  If we are hammering on opposite ends of the same pack that could slow things down a bit.

Other than that, we are inclined to believe it is mostly the I/O causing the slow down but again, we'd like you to check other indications of system usage when this occurs and also make sure you know how much in use the system is before you start the process.
 

Additional Information

The customer later reported that their Storage guys changed how z/OS guests link t full volume minidisks therefore, they no longer
need the large MVSDASD profile.