× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



FWiW, an origin of that issue is related to the fact that there is no such thing as an *IMMED-only PTF. Anytime a PTF that requires work to be done outside of an IPL must be provided, an alternate process must be utilized outside the PTF process to ensure that work gets done, if that PTF was applied delayed instead of immediate. There is no QPTFAPY system job that, in post-IPL, that will process IPL-time enqueued work, work which would have been enqueued during IPL-time by a PTF-exit processing; there should be such a job integrated into the PTF apply processing feature, to prevent the QDBSRVXR2 job from being used to service those requests. If soon after an IPL on which such a PTF was installed, a request is made to reclaim the *DBXREF, the request will be lost; i.e. the PTF would not have applied its changes that were provided by the PTF-exit, although the status of the PTF had already changed to "applied" during the IPL, during the "delayed" PTF-apply processing.

The QSQCCATV processing minimally should have sent, or caused the *DBXREF to have sent, a "help me I've fallen and I can't get up" message in the case described; i.e. there should be a termination handler for abnormal terminations, which would send a clear indication that its work was incomplete, including a message in the range of the pre-coded DSPLOG request from the GO INSTALL which shows messages about failed PTF application activity. If the only indication of the failure was some messages in the QDBSRVXR2 joblog [or perhaps some missing or problematic catalog objects eventually getting noticed], then that is another defect that should be corrected... in the next iteration of a fix that does the same type of processing. I realize this is not a proper venue to suggest that, but anyone who cares and has a support contract [and was affected], might be interested to pursue.

Regards, Chuck

On 22 Mar 2013 06:22, Jeff Crosby wrote:
5770SS1-SI49730 was the only PTF downloaded
<<SNIP>>
DESCRIPTION OF PROBLEM FIXED FOR APAR SE55225 :
-----------------------------------------------
Under some conditions, the application of DB2 for i PTFs over
an IPL fails repeatedly in the QDBSRVXR2 job with MSGMCH0601
exceptions within QSQCCATV procedure CRTSCV at Statement
13745.
<<SNIP>>
SPECIAL INSTRUCTIONS FOR SUPERSEDED PTF SI41819 :
=================================================
When applying this PTF in immediate mode will result in exit
program processing that will drop and recreate DB2 for i supplied
objects in QSYS2, SYSIBM and several other system libraries. The
exit program may not complete quickly. It is recommended that
when this PTF is applied in immediate mode, that application
which rely upon DB2 for i supplied objects are quiesced.
DEFAULT INSTRUCTIONS :
----------------------
THIS PTF CAN BE APPLIED IMMEDIATE OR DELAYED.
<<SNIP>>

On Fri, Mar 22, 2013 at 8:27 AM,<rob@xxxxxxxxx> wrote:

You're only telling us group 23, not "(The PTF that fixes
everything)". So, I'll have to download group 23 and look
at every PTF that's not applied to try to figure it out?
<<SNIP>>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.