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.
midrange.com
