Re: Restoring DDM files from tape

On 20-Nov-2015 15:57 -0600, Jerry Draper wrote:

On 10/29/2015 10:52 AM, CRPence wrote:

On 29-Oct-2015 12:35 -0500, Jerry Draper wrote:

In a recent DR simulation we restored some libraries with lots
of DDM files.

The target system of the DDM files was NOT on the network as
this was a simulation.

The restore operation of each file failed after a timeout of 315
seconds.

There are many, many DDM files so at 12/hour we weren't getting
anywhere fast.

There are no break messages so you only find out after wondering
why the restore is taking so long.

How can this be managed so we can restore the files and NOT
validate the remote system?

What is the actual information from a spooled joblog? Just a SWAG,
that [the messaging in the joblog will reveal that] the timeout is
nothing to do with contacting a remote system, and instead is a
functional issue with the *DBXREF.

Working theory on this one is that it is a LIC incompatibility
issue.

The DR machine was IPLed from an iBASE DVD at refresh level B and
then the system was "restored" from a tape with refresh level M.

We will test this on 12/10/15. I'll let you know.

Very unlikely that the mismatch is being directly manifest as the dequeue timeout; the direct origin of the issue is most likely some error(s) manifest in the *DBXREF, for which that feature is rendered non-functional. Almost surely, the dequeue timeout is the _expected_ side effect of the system job QDBSRVXR being unable to feedback the response to temporary queue of job of the requester; the internal queue upon which the code waits for that feedback, apparently for ~315 seconds.

Without verification that the non-functional *DBXREF was the origin, a conclusion that the /correction/ of that mismatch was the resolution, would only be a valid conclusion, having recognized that there is that level of indirection.

If the information from those errors [in the QDBSRVXR job and the history log] are gathered and recorded somewhere on the web, then those errors recorded as symptoms could be located and a reader see the explanation of the origin along with the recovery. As it stands now, there is only my speculation based on little actual evidence beyond the msgMCH5801 conditions that are logged for an internal temporary queue, which merely approaches certainty as being a side effect of a non-functional QDBSRVXR job.