× 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.



On 22 Mar 2013 07:26, rob@xxxxxxxxx wrote:
On 22 Mar 2013 06:26, rob@xxxxxxxxx wrote:
So it can be applied immediate but ANYTHING which accesses the
system catalog may hang during the PTF apply? I suppose that
might include CRTPF, etc.

Presumably the apparent concern alluded above is with regard to the special instructions?

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.

Note that the issue is not the System Database Cross-Reference files, i.e. not the *DBXREF, but instead some SQL Catalog VIEWs that are being dropped and recreated. Thus what would be impacted are those jobs dependent upon /reading/ those VIEWs, such as ODBC, JDBC, and any other SQL that might depend on SQL catalog queries. And FWiW, I believe the only affected files are the various SQL VIEW objects that are built on the SQL Catalog TABLE objects [in QSYS2; ¿and? SYSIBM], rather than any of the VIEWs built on the *DBXREF physical files.

Regardless... Both CRTPF and CREATE TABLE would be unaffected by replacing any VIEWs; no matter when. The *DBXREF maintains tracks those create requests in the QADB* physical file in QSYS, over which some SQL Catalog VIEWs exist. But the *DBXREF does not have any dependency on the existence of those VIEWs; and in fact must not, lest there be a chicken\egg dilemma.

Similarly CREATE PROCEDURE, even DROP PROCEDURE [or FUNCTION, TYPE, etc.], for whatever is tracked by the SQL in QSYS2 [i.e. those not tracked by the DB2 in the *DBXREF] will also be unaffected for the same reason. Those VIEWs are there for inquiry, but not for use by the tracking feature itself, which uses the TABLEs [and some keyed logical files]. So as long as there are no jobs active that depend on inquiry of those SQL catalog VIEWs [that are built over the SQL catalog TABLEs in QSYS2], then the PTF should be able to apply immediately without any difficulties.

It was a very fast IPL. Didn't take long at all.

The work of the PTF "exit program processing" was deferred to the QDBSRVXR2 job, post-IPL, so the IPL just applied the PTF without doing any work in exit-program processing; i.e. no work other than a simple enqueue of the work-item to be done post-IPL. Per the PTF, one would expect [the terminating] errors for the QSQCCATV [SQL Create CATalog Views] would not be logged there [as they might have in the prior version of the PTF]; i.e. that the work of QSQCCATV transpired as expected, in the QDBSRVXR2 job after the IPL completed, without any failures.

DEFAULT INSTRUCTIONS :
----------------------
THIS PTF CAN BE APPLIED IMMEDIATE OR DELAYED.

So why IPL to apply the immediate-apply PTF? Restricted state should be good enough [with rare exceptions; e.g. if the prior defect had also left unexpected locks on any VIEWs in the active QDBSRVXR2 job].?

So given what was described... there may be little reason to perform an IPL to apply this immediate-apply PTF; even restricted-state is probably excessive for most. The biggest pain would be that, *if* the PTF exit-program fails [e.g. for an allocation error] and correctly notifies of the failure to the PTF apply processor, then the PTF would be marked damaged. And a damaged PTF would have to be re-loaded to try again after the failure; perhaps scheduled for a delayed apply, or trying again in restricted state after verifying the origin for a lock conflict would be resolved by ENDSYS [i.e. the conflicting lock is held by a user job, not a system job]. However.... *because* the work is done post-IPL [rather than during the IPL], the same potential issue exists for lock conflicts, albeit seriously reduced because the QDBSRVXR2 [unless it was buried by prior work; e.g. a RCLSTG SELECT(*DBXREF) just before IPL] will likely get started on the enqueued work long before anyone has a chance to perform any inquiries against the SQL Catalog VIEWs that are to be deleted and re-created.


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.