Re: V6R1 - Finding Missing storage

[CRPence <CRPbottle@xxxxxxxxx>]

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