Re: TCP Problem with DR system

Chuck:
I'm not where I can see what was actually done by the vendor so I'll
have to find out what they did. I suspect you are correct in that QUSRSYS
was somehow replaced either in whole or piecemeal. QGPL as well.
I would have assumed that whatever restore they had in mind should
not have included those specific system objects that could compromise
the outcome.
As I have thought through this I'm now of the opinion that the vendor
did something he didn't intend to do and that I'll have to build the
system
again.
I'll take your advice to heart, Chuck. I think piecemeal is a bad idea.

Bill

"CONFIDENTIALITY NOTICE: This e-mail transmission (and/or the attachments
accompanying it) contain confidential information belonging to the sender.
The information is intended only for the use of the intended recipient.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or the taking of any action in reliance
on the contents of the information is strictly prohibited. Any
unauthorized interception of this transmission is illegal under the law.
If you have received this transmission in error, please promptly notify
the sender by reply e-mail, and then destroy all copies of the
transmission."






From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 12/12/2014 04:07 PM
Subject: Re: TCP Problem with DR system
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



On 12-Dec-2014 14:42 -0600, broehmer@xxxxxxxxxxxxxxx wrote:

I have a question that maybe, if I'm lucky, can be answered by
someone who has had this happen to them before I have to recreate the
DR system from scratch.
On a disaster recovery box TCP hostservers don't show up after
restoring from the production box. The DR system was a complete
working system before the restore

Presumably [a SWAG], a restore-over of the quasi-user\quasi-system
library QUSRSYS was requested\performed, having specified an Allow
Object Differences (ALWOBJDIF) specification of *ALL. A DR restore-over
done to an already active and functional system should use the special
value *COMPATIBLE rather than *ALL to avoid the database restore feature
from renaming the database file.member objects; a DR restore that should
not impact the current configuration should ensure to restore only /new/
files and members rather than effecting a restore-over of the [config]
data.

If that type of restore was not done, then ignore the remainder of my
reply, which applies only to that as the posited scenario.

and now, while one can ping from the DR box to the Production box no
hostservers are shown and none can be started and client access does
not work.

From a followup reply, the issue seems to be with the TCP/IP Servers
as provided by TCP/IP that would be started with Start TCP/IP (STRTCP)
and\or Start TCP/IP Server xxx (STRTCPxxx) and Start TCP/IP Interface
(STRTCPIFC), not the optimized Host Server Daemons that would be started
with the Start Host Servers (STRHOSTSVR) command.?

Given that something is terribly wrong with the restore, how can one
reinstall TCP hostservers or is this even worth trying?

A piecemeal recovery performed for the effective user-data that
defines the configuration of the various features often is a poor
choice; often a wholesale replacement of the contents of the libraries
that contain the files and data defining the configurations is a better
option because after correction of any one specific set of files leaves
each of the other remaining features that were also corrupted by the
improper restore to be encountered and recovered over time. In this
case, the identified issue is likely with a set of files is likely a
subset of the database files named QAT* in QUSRSYS.

The quasi-system libraries [at least the QSYS2, QUSRSYS, and QGPL]
can be reverted to the prior functional\working state, reflecting the
operation of the DR system without any effects from the configurations
on the production system, by clearing the libraries and then restoring
the backup taken on the DR system prior to the restore from the save of
the production system. Note: Deleting objects of a specific level of
maintenance after which a restore from a backup is done, is best
followed by re-application of the current or a later level of maintenance.