× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Chuck --

Perhaps the expected recovery, by performing the full restore a second time;


The restore from the 21 save I did ... I installed 7.1 first (being unable
to boot from tape) and I think the farthest I dared was *NONSYS.

Are you saying that if I did a *NONSYS again, it might fix itself?

On Sun, Apr 15, 2018 at 8:23 PM, Jack Woehr <jwoehr@xxxxxxxxxxxxxxxxxxxxxxxx
wrote:

Thank you. I'll have to look through that in depth before I reply!

On Sun, Apr 15, 2018 at 6:58 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

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




--
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021

NON-DISCLOSURE NOTICE: This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information. If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited. If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.