On 21-Jul-2014 17:53 -0500, James H. H. Lampert wrote:
Paul Nelson wrote:
Have you thought about submitting the restore and repopulate jobs into a
single-threaded job queue?
Part of it was that I discovered, rather belatedly, that the PF wasn't
empty at the time of the save (it SHOULD have been).
The definition of ACCPTH(*YES) is vitiated by /empty/ because in that
scenario [for what IMO was a near inexcusable subjugation by one
particular customer], the access paths are not saved, and they are
rebuilt synchronously during the restore; i.e. the ACCPTH(*YES) is in
effect, ACCPTH(*MAYBE) or more aptly: ACCPTH(*ONLY_IF_DATA). I suppose
*YES could be argued as already not being entirely accurate, because any
invalid access paths are not saved and no warning is ever logged,
however at least that effect was clearly documented somewhere, whereas
the lack of data was originally part of a PTF maintenance [not a new
release] and was left undocumented [and may remain so].
And "restore" and "populate" are *not* separate jobs. A CL program first
restores the PF and LFs (and a few other things in the same save file),
then immediately (i.e., the very next statement) calls an RPG program
that populates it.
As I noted in another reply [though sometimes I wonder if anyone ever
sees or reads any of my replies; or, I suppose, people are just too
time-constrained to read stream-of-consciousness replies over some
simplistic bullet-point memos that must only *solve* their dilemma
instead of including any edification per various related details
offered, or worse, dismissing any reply that inquires more about their
particular scenario to clarify some details], 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)