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)

So, if I currently have (names changed to protect the innocent, with
the specified target library in &LIBNAME):


and the only unique keys are on PHYSICAL and LOGICAL01, then


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 :-)

Return to Archive home page | Return to MIDRANGE.COM home page