Re: TCP Problem with DR system

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.