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.
midrange.com
