Chuck,
Thanks for all the feedback.
I'm still mystified why the MCH3601 and MCH0601 disappeared on the 4/26 run. (what changed between 3/31 and 4/26)
Is it possible that these are two different issues, (CPF5009, CPF5026) and (MCH3601,MCH0601).
I IPL'd this weekend, applied all latest PTFs.
I will be running this process again on 5/28.
I agree with your statement on RCLSTG *DBXREF, also IBM no longer recommends this a possible resolution step.
APAR SE45470, PTF SI41617 is a V6R1 issue, I'm not finding this for V7R1.
IBM currently has a test PTF, SI53044, for a similar issue, but not the exactly the same. This is issue also involves IASP, which I do not have.
From IBM
"Test PTF SI53044 is available for the issue. The fix is to ensure both IASP and SYSBAS catalog files are updated correctly when processing the 'COMMENT ON' SQL statement for the stored procedures. If that is done correctly, other subsequent operations (like a DROP) will also function correctly. It does NOT fix the catalog once it is out of synch. Bright, will you apply this test PTF? I understand it's a production environment. If you have to wait for an approved PTF, would NetCracker be able to help test the PTF?
There are no plans to change the behavior of the DROP SPECIFIC PROCEDURE code. If the problem becomes more pervasive, development will look into a new tool or extend the existing QSQSQLCAT program to address this problem"
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, May 12, 2014 10:06 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPF5009 , CPF5026, SQL9015 , MCH3601, MCH0601
On 09-May-2014 06:35 -0500, rob@xxxxxxxxx wrote:
<<SNIP>>
My shoot from the hip answer is to run a RCLSTG *DBXREF
And per typical, [not you(rs) personally] bad advice; i.e. often implications that a Reclaim Storage will assist directly for this or that issue, are wrong. In this case, the System Database Cross-Reference does not maintain the SQL catalog TABLE SYSROUTINE; that is the domain entirely of the SQL. And besides, for lack of one /object/ existing per row of that TABLE, there is no ability to /refresh/ the data from the objects on the system, thus no such reclaim function could even assist generally; i.e. some routines that exist as rows with no corresponding object would have to remain as-is or all be purged as part of a refresh.
<<SNIP>>
Doing the *DBXREF isn't a long running process. You'll spend more time
getting the system down and back up again. On systems with even an 11
hour full RCLSTG the *DBXREF normally only takes 20 minutes.
While a generally accurate statement, there are conditions specific to each system which could make the request run much longer on one system versus another. The differences in number and types of objects from one system to the next can be extreme. For that reason alone, a caveat "YMMV" applies. The synchronous portion of the work may perform a /long time/ on some systems due to requirements to await feedback from some of the asynchronous work previously enqueued; most notably, processing cross-library dependencies for Referential Integrity (RI).
Time wasted in restricted state to perform the reclaim request [for naught], is still time wasted.
FWiW: The Reclaim Storage function should be avoided until either a data issue is noticed by a user, a notification of a data issue is made by the system, or IBM support\service has directed the request as a recovery action for a specific condition for which the recommended reclaim feature is intended to correct or provide some relief; note: the reclaim of the *DBXREF should almost never be included in a reclaim request whenever the *DBXREF feature is notifying of a functional problem, because the *DBXREF feature must be fully functional in order to process the enqueued work that would effect the refresh of the *DBXREF data.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
