Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Operation of virtual hosts

&pagelevel(4)&pagelevel

Virtual hosts enable current operations to be transferred in part to another mainframe when a mainframe fails. When this happens, connections must be set up again. Detailed information on virtual hosts is provided in the section "Host redundancy". You must define the virtual host using the CREATE-VIRTUAL-HOST command. An example of this is provided in the section "Example of host redundancy". The switchover between the standard host and virtual hosts can take place manually or, more conveniently, automatically using HIPLEX AF.

CAUTION!

The main thing to bear in mind here is that a network address may only be active once in the network at any given time; otherwise, serious errors may occur throughout the entire network.

Configuration on a virtual host

After the mainframe has failed, the virtual host is started manually on another mainframe:

/BCACT HOST=VHOST1,ACT=ALL

Reconfiguration of a virtual host from the backup mainframe for the original mainframe

The first and most important step when reconfiguring after correcting an error is to take the virtual host on the backup mainframe out of service. Only then may you reactivate the virtual host working with the same network addresses on the backup mainframe:

/BCDAC HOST=VHOST1,DAC=ALL

The addresses of the virtual host must now be in the "invalid" status on the backup mainframe. You can check this with the following command:

/SHOW-OWN-ADDRESS HOST=VHOST1

Assignment of applications to virtual hosts

It is possible to assign NEA,ISO and SOCKET applications dynamically to virtual hosts and to change these assignments dynamically. The assignment only occurs at BCAM level in the application file (see section "Application file"), and no changes to the applications are necessary. The application file only contains the applications which are not intended to run on the default host., i.e. all the applications which do not have an entry in the application file are automatically started on the default host. However, if the application itself performs an assignment through the explicit specification of a host name, then this always has priority, i.e. the application file is not accessed. If the application file contains several entries for applications with identical names on different hosts, only the first entry is evaluated.

Host-Aliasing

If, when an application is accessed, it is not found at the specified network address, an additional check is performed to determine whether the application has been started at the default host. If this is the case, and provided that the application is not found at any other virtual host, then a connection to this host is established.

The following definitions/limitations apply:

  • Host aliasing can be prevented for specific applications by entering the keyword “-NOALIAS” as the host name in the configuration file.

  • Any mapping entries must be defined for each host.

  • Mapping is only performed for the host accessed via the network address.

  • Mapping is performed before host aliasing.

  • No host aliasing is performed for statically predefined applications.

  • No host aliasing is performed for UDP messages.