On 22-Oct-2015 03:13 -0500, James Evans wrote:
I've been doing some more investigating and there are 2 views of
SYSTABLES - one in QSYS and the other in QSYS2 - both looking at the
same files Qsys/QADBXREF and Qsys/QADBXMQT. However the view in QSYS
shows nothing while QSYS2 shows the catalogue but unfortunately QSYS
is above QSYS2 in the system library list.
When I dspfd the 2 logicals there is an SQL statement that builds
them and they are just about identical apart from right at the end of
the QSYS view it has added the statement AND DBXLIB = 'HSUDTF ' .
Before any recovery actions are attempted, gather and retain the
DSPFD OUTPUT(*PRINT) for both files, and gather and retain DSPOBJD
information from both files, both DETAIL(*SERVICE) and DETAIL(*FULL) and
both OUTPUT(*PRINT); the owner and creator information, as well as the
creation date are the most imperative... and the change and restore
dates are possibly important too, but the last-changed might not be as
helpful.
The extra ANDed predicate is the effect of either:
• The SQL statement:
CREATE COLLECTION HSUDTF
-- or IIRC either of CREATE SCHEMA or CREATE DATABASE
-- Odd however, is the extra [apparent] blank character
-- embedded in the eighth byte of the 8-byte character
-- literal\constant.
• The API to generate the library-specific VIEWs was called:
CALL QSQXRLF (CRT 'HSUDTF')
-- that result would have the character-string constant
-- fully padded to 10-bytes, according to my test on V5R3
I have no idea yet if
1. There should be views in QSYS and QSYS2
Really seems unlikely there should be one in QSYS; never had been in
prior releases, and goes against all the [even newer] docs. My guess is
something had gone completely wrong... and finding out what, is probably
fairly important, so as to prevent any recurrence.
2. The SQL Statements in both libraries should be different
Well, if even there ever was supposed to be a SYSTABLES in QSYS; but
as alluded above, that seems /whacked/.
3. This is all a red herring and there is something else that needs
to be rebuilt.
If auditing is on, given the symptoms, the most likely origin of the
issue is that someone performed one of the following requests:
• MOVOBJ HSUDTF/SYSTABLES *FILE QSYS
• CRTDUPOBJ SYSTABLES HSUDTF *FILE QSYS
• RSTOBJ SYSTABLES HSUDTF RSTLIB(QSYS)
Only the last has specific\revealing Object Description information
about the action.
I've got our infrastructure team speaking to IBM so I will let you
know what I come across. Certainly the last change dates to
Systables were the same date as when the PTFs were applied.
Change date, on both? Regardless, as I noted early in my reply, the
creation information [owner, creator, date\time] might be more
revealing. And if object-level auditing is available, what action was
performed for the change and\or create and\or /management/ of the object
might be revealing.
After collecting\retaining the details about the SYSTABLES *FILE
object found in QSYS, the issue is easily resolved by issuing; leaving
the object on the system, but /debassing/ the change date\time
information for the object and member [as to why doc collection must be
performed before /recovery/ actions]:
MOVOBJ QSYS/SYSTABLES *FILE QRECOVERY
FWiW, my prior mention of the difference between /logically/ missing
data vs /physically/ missing data is pertinent in the described failing
scenario; i.e. the physical data could potentially all be there, but the
query of the VIEW with the faulty predicate would preclude finding the
desired data.
midrange.com
