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