Re: V6R1 - Finding Missing storage

On Wed 05-May-2011 03:01 , Henrico, Pieter wrote:

<<SNIP>> The desktop utility showed file QA1ALI2 in QUSRBRM to have
a member size of 75GB big, and QA1ADI2 has a member size of 8GB. We
did a DSPFD, and the result showed 4.3GB for QA1ALI2 and 400MB for
QA1ADI2:

<<SNIP>>

Confused yet? I know I am. We have send all this information through
to IBM, and is still waiting on comment from them.

To sum up, here are my questions:

<<SNIP>> Why does
the PRTDSKINF not show 100%? What are we overlooking here?

I would concentrate on the RTVDSKINF apparently not retrieving the correct details, or PRTDSKINF not correctly summarizing the details. IBM support should have tools to force the RTVDSKINF to store more detail in the QAEZDISK output [or a similar file?] than is typical; to help expose issues with the feature. However a quick review for any negative size values might be a good first-pass of the existing data to find anything obviously illogical; query the QAEZDISK file for that condition.

I seem to recall at one time there was an issue with either a LIC object header or a LIC Database object size being reported incorrectly; some side effect from RGZPFM or CLRPFM as I recall, and IIRC improperly treated as signed versus unsigned integer values they would actually be negative thus subtracting from an aggregate calculation instead of adding. And since anomalies are already determined to be with some specific files, maybe consider just concentrating on those database *FILE objects first. The first thing I would review is for anything irregular in the size information in the output from the following two requests:

dmpsysobj 'QA1ALI2 *' QUSRBRM OD 50
dmpsysobj 'QA1ADI2 *' QUSRBRM 0D 50

FWiW: An example of a size reporting issue, but no mention of steps for recovery, that had a preventive on v6r1:
MA36013 - LIC-DB-INCORROUT OBJECT SIZE BECOMES INCORRECT
http://www-01.ibm.com/support/docview.wss?uid=nas24a2d5811c7d05c4c862573d90041ecbe

Regards, Chuck