On 21-Jul-2014 18:47 -0500, James H. H. Lampert wrote:
On 21-Jul-2014 18:13 -0500, CRPence wrote:
<<SNIP>> if the Unique AccPth of the LFM is required to be valid,
then just like the CPF5090 suggests in the "Recovery" section,
first *OPEN* that LFM with keyed access *before* opening the PFM
with an UPDate capability; e.g. OPNDBF &7/&6 MBR(&8) OPTION(*INP)
ACCPTH(*FILE)
So, if I currently have (names changed to protect the innocent, with
the specified target library in &LIBNAME):
> RSTOBJ OBJ(*ALL) SAVLIB(APPLIB) DEV(*SAVF) +
> OBJTYPE(*PGM *FILE) SAVF(UPDSAVF) +
> RSTLIB(&LIBNAME)
> CALL POPULATE
and the only unique keys are on PHYSICAL and LOGICAL01, then
inserting
> OPNDBF FILE(&LIBNAME/PHYSICAL) OPTION(*INP)
> CLOF OPNID(PHYSICAL)
> OPNDBF FILE(&LIBNAME/LOGICAL01) OPTION(*INP)
> CLOF OPNID(LOGICAL01)
between the RSTOBJ and the CALL POPULATE will solve my problem?
Essentially, that, and probably alone, should prevent the issue. Yet...
Only *if* both the ACCPTH(*FILE) is sure to be the default and the
default member name MBR(*FIRST) is both expected for the scenario and
sure to be the default on the system on which the code runs. The Access
Path (ACCPTH) specification and the specific Member name [or a special
value] should be explicitly specified to prevent any failed assumptions
with regard to the default parameter value specifications.
While unlikely to be an issue, I would also prefer to explicitly name
an Open Identifier (OPNID) reserved for use by that CL in which the Open
Database File Member (OPNDBF) request is embedded. That is mostly
because if the job might already have an OPNID with either of the names
PHYSICAL or LOGICAL01, from unrelated work or a prior failed invocation
of this same work, then the CLP could fail with the msg CPF4174.
Further details\expounding, that may be of some value [or provide
impetus for more research or testing]:
Any requirement to rebuild a physical unique access path should be
rare; almost exclusively, such an occurrence will have an origin with
either a defect or object [physical or logical damage; as types of
object damage, the concept although similar to the conceptual naming for
database data, is unrelated to the naming of physical vs logical
database file definitions]. The open of the PFM should be able to be
omitted [with almost no\never any ill-effect].
I do not recall what happens if one of the QDBSRV## runpty-52 jobs
already has started the rebuild activity prior to the OPNDBF request
getting started, with regard to any possible requirement to also ensure
a Wait File (WAITFILE) time in the job that would open the file with the
Unique Access Path. I think maybe there is _no concern_ for conflict
with just an OPNDBF request. Though, without actually testing a
scenario, probably the best bet is to also include either an Allocate
Object (ALCOBJ) request before the open or issue a request to OVRDBF
WAITFILE(time_limit) before the open; i.e. if the background work
conflicts according to what a WaitFile allocation enables, then
specifying a timeout on a lock request or the wait-time for the open
might be worthwhile. I honestly can not recall, but I think the open
requester may either fall into an indefinite LIC seize-wait or even an
effectively indefinite lock wait [irrespective of a Wait File timeout]
that avoids a diagnosed conflict with the async rebuild activity, and
thus there is no reason to ensure a Wait File time other than *IMMED [or
any non-immediate value already associated with the member per the
attribute of the database file]. I do know that if a synchronous
request to OPNDBF obtains a conflicting lock that prevents the async
work from obtaining its lock [and FWiW there is a technique to ensure
that occurs; IIRC to lock the library and\or pre-restore without data
(members) followed by an allocation followed by an additional\separate
restore with the data], then the asynchronous AccPth rebuild will be
re-enqueued in the background to try to obtain the lock. If the access
path is already valid then that since-completed request to perform the
same\duplicate work will be discarded by the system job. Note: each
CPF5090 [or at least the first for any one job] will effect another
background rebuild event being signaled, added to the event queue
processed in the QDBSRV01 system job.
While unlikely... Of course if a prior invocation of the program in
the same job had failed without having processed an invocation exit to
effect the required Close File (CLOF) request(s), then a prior failed
invocation could have left a duplicate Open Identifier such that the
error msg CPF4174 might occur; although unlikely, good to know, and
possibly worth pre-populating a KB\support record to help find a
matching incident and its resolution [i.e. to perform the Reclaim
Resources (RCLRSC), or for a CLLE instead a Reclaim Activation Group
(RCLACTGRP)]. A presumed-failure coding method could include the
explicit CLOF request [with a MONMSG and EXEC to remove the likely
effect of msg CPF4520 following the close request] issued prior to the
Open DBF\DBM request; such coding might be considered somewhat an unduly
protective coding style, or even deprecated by some people as pedantic
coding by the author :-)
midrange.com
