VCCVT56W msgs generated, more than 1K; how to debug/confirm root-cause

book

Article ID: 195556

calendar_today

Updated On:

Products

CA MICS Resource Management

Issue/Introduction

Reviewing the MICS VCC prod-job output, we see more than 1000 VCCVT56W messages generated, which seems a bit high.  So, before blindly suggesting Storage Mgmt rebuild all the VTOC INDEXes, we are interested to understand whether this condition is being accurately detected.

And also asking for guidance with how to diagnose with confidence that what VCC is "calculating" is even correct logic, with current z/OS V2R3 & V2R4 mixed environment. Please provide some insight with this detected condition.




Environment

Release : 14.2

Component : CA MICS

Resolution

VCC reads VTOC DSCBs and stops doing it when all used DSCBs were read.

If VTOC indexed properly, VCC stops reading if the counter of used DSCBs reached the number of calculated used DSCBs.
The calculation is based on information from the VTOC index.

If VTOC index has an issue, VCC reads the entire VTOC which uses more EXCP resources.

Ran VCC scans for 87 volumes and found 10 volumes that produced the message.
Then the indexes had been rebuilt on them, 
Reran the scans and now there are no VCCVT56W messages, and it used 10 times less EXCP's for some volumes.
 

So, you can do nothing and the scan will continue to run fine, or, you can rebuild the indexes and save some percentage of EXCP resources.
The number of EXCPs can be an indicator of wrong VTOC index for the volumes with the messages.

 

Another option is to set up a second VCC scan job to just scan a subset of the volumes.

The VCCVT56 message identifies the volume name that triggered it.  So, you could set up a separate scan job to scan any 10 volumes.  Then have the Storage Admins rebuild the indexes on those 10, and then rerun that scan and see if the message still appears.

 

 

 

Additional Information

Also want to show actual EXCP use on two of our volumes, BEFORE and AFTER reindexing:

EXCPS   BEFORE   AFTER

TSU116   66647        7140
TSU122   66587        6980
 

So, there is a non-trivial performance improvement by dealing with these volumes.

 
 
 
 
Also want to share the ICKDSF utility jobstream the customer used to rebuild VTOCIX using the VCCVT56W message text along with the JCL example below, It was quite easy to simply filter on the message number, delete the excluded lines, then COPY/PASTE the resulting volume-list directly into the JCL skeleton, overlaying the VOL=<volser> symbolic on the EXEC statement.

Also, we did see some reduced EXCPs for the VCC scan job, especially evident for the hourly-scan (VTOC/volume/SMS-pool only - DATAINFO=N specified).

 

//**************************************************************
//* REFESH VTOCIX (INDEX VTOC)
//**************************************************************
//         EXPORT SYMLIST=(VOL)
//* */
//BLIXVTOC PROC VOL= 
//JSTEP1   EXEC PGM=ICKDSF,PARM=NOREPLYU 
//*             ** REBUILD VTOC INDEX - JCL-SYMBOL SPECIFIED **/ 
//SYSPRINT DD   SYSOUT=*
//VOLDD    DD   DISP=SHR,UNIT=3390,VOL=SER=&VOL 
//SYSIN    DD   *,SYMBOLS=JCLONLY 
 REFORMAT DDNAME(VOLDD) VERIFY(&VOL) REFVTOC
//* */ 
//         PEND
//PSTEP    EXEC BLIXVTOC,VOL=xxxxx1
//PSTEP    EXEC BLIXVTOC,VOL=xxxxx2
//PSTEP    EXEC BLIXVTOC,VOL=xxxxx3