Re: Extracting data from the QSYS2.OBJECT_STATISTICS

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 08/03/2017
07:41:38 AM:

----- Message from Alan Shore <ashore@xxxxxxxx> on Thu, 3 Aug 2017
11:17:56 +0000 -----

To:

"midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>

Subject:

Extracting data from the QSYS2.OBJECT_STATISTICS

Hi everyone
Before I forget - we are on V7r1

I ran the following SQL command
SELECT *
FROM TABLE (QSYS2.OBJECT_STATISTICS('*ALLUSR','FILE'))
as X

on all of our systems with no problem - EXCEPT ONE (isn't that
always the case)
This one particular system needs to purge/delete/remove some files
as the amount of available disk space is becoming smaller

When I run the above query, I receive
Query cannot be run. See lower level messages.

So taking F1 on that message, and then the job log, I see
Attributes of field OBJSIZE format FILEATTRIB not valid.

Then taking F1 on that message, I see
Message ID . . . . . . : CPD4308
Cause . . . . . : The type, length, decimal digits, decimal precision,

CCSID

(Coded Character Set Identifier), date or time format, or date or time
separator of field OBJSIZE query format FILEATTRIB is not valid. See

the DDS

topic collection in the Programming category in the IBM i Information

Center

book, http://www.ibm.com/systems/i/infocenter/, for valid field

attributes.

I have googled CPD4308 - but theres nothing much out there - well -
unless you are looking for some safety courses

Does anyone have any idea the underlying cause is and how to rectify

this?

As always - any and all responses gratefully accepted

Alan Shore

We have a routine (pre-dating OBJECT_STATISTICS) which does a DSPFD on all
files in a selected set of libraries. This has failed a couple times. The
problem was that under certain circumstances, the object header got
damaged and couldn't report the number of records in the file nor the size
of the object correctly. I think we used a CHGPF to correct existing
damage and applied PTF SI62119 to prevent further issues. (We originally
reported this years ago and the solution was PTF SI57402 which through a
series of supersessions leads to SI62119.) I can't guarantee this is the
issue for you, but it sounds very similar.

To find the damaged file object(s), you can do a DSPFD to an OUTFILE. Then
figure out the file which should be after the last one to successfully be
added to the OUTFILE.

By the way, I don't believe the objects show as damaged--just a part of
the header information is and causes problems which DSPFD manifested. I
would think the same issue would apply to OBJECT_STATISTICS.

ymmv,
Michael Quigley
Computer Services
The Way International
www.TheWay.org