Re: CPF5090 happening with annoying frequency

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) OPTION(*INP) ACCPTH(*FILE)