Re: QS36F file format error after migrating LPAR

On 06-Apr-2018 15:17 -0600, Jack Woehr wrote:

Have S36 applications throwing errors, e.g.:

// QRYRUN INTRST01,INS.QRY,INTRST,DISPLAY,,,,,,,,,RECSEL,DETAIL
QRYRUN procedure is running
Format INTRST01 not found in file INTRST in QS36F.

The file INTRST is there. What magic button have I forgotten to push
in restoring that this file has lost its connection with its format?

I do not recall the details for what was documented as the corrective
action for the above-described issue, whereby for the standard/old
RESTORE-21 data-migration that had included such files, some Data
Dictionaries (*DTADCT) would be restored *after* the files [per
alpha-ordered Library (*LIB) restore], for which no linkage would be
maintained; the restore of such files on the initial migration would have
logged a diagnostic [I think msg CPF2C2E], suggesting that the File
Definition could not be found [in the not-yet-restored Library (*LIB) of
the IDDU Dictionary], and thus the file was not linked upon this restore.
Perhaps the expected recovery, by performing the full restore a second
time; or just libraries [or specific files] for which the errors were
logged? As I recall, like with Journals, the typical action for
maintaining IDDU linkages in a full system restore, was preventive, so as
to avoid any recovery steps; i.e. ensuring the naming of the dictionaries
would precede, in alpha-collation, the name of the library of any linked
files being restored.

I'm not sure if, possibly [though doubtful, as I do not recall that
being included], for the database file objects that are not linked might be
supported as part of the "deferred restore" feature; i.e. with a Defer ID
(DFRID) being assigned for the *NONSYS restore, and Restore Deferred
Objects (RSTDFROBJ) enabling the completion of the restore.? A similar
issue for restore of Journal (*JRN) objects after the journaled object,
would be corrected using that feature. But I expect the GO RESTORE
option-21 probably was already updated long ago with that "deferred
restore" feature enabled.?

The non-restore method for re-"connection", would be effected with a/the
script for the IDDULINK requests [aka Link Data Definition (LNKDTADFN) CL
command] that would link each Database File (FILE) to the expected File
Definition (DFN). And…

I expect there is another and quicker means to re-link than another
restore, by using the historical data stored in the System Database Cross
Reference (DBXREF) Physical File named QADBXREF in QSYS [accessed via any
Logical File (LF) over that PF], but with the *assumption* that the stored
/historical/ information about the linkages should be re-applied for each
file not currently linked; could be, that not all unlinked files were
unintentionally so. Regardless, an example of the process: selection via
(DBXDIC<>'' and DBXATR='PF' and DBXLNK='' and DBXTYP='D' and DBXREL='N' and
DBXIDV<>0) to obtain a list of all such unlinked files, combined with
either the File Definition Name (PHFILN) [obtained from the Display File
Description (DSPFD) of each PF for the Type=Attribute-Information (*ATR)
for File Attribute of Physical (*PF)] or that the DFN would be determined
instead via an invocation of the Retrieve File Definition (QDBRTVFD) API;
either would provide the parameter value for the DFN of the LNKDTADFN
request on a request to perform OPTION(*LINK). Similarly, for the Data
Dictionary (DTADCT) and Creation Date (CRTDATE) parameters.

--
Regards, Chuck


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD