Telserv Manual

Starting the Telserv Process
Telserv Manual—427174-009
3-15
Fault Tolerance
which you want Telserv to service connections. Use the DEFINE and PARAM
commands to perform this task.
For example, the following command sequence starts a Telserv process on a default
logical network partition and another on an indexed logical network partition:
Default LNP:
>PARAM TCPIP^PROCESS^NAME $ZSAM1
>PARAM ZTNT^TRANSPORT^PROCESS^NAME $ZSAM1
>TELSERV/TERM $ZHOME, OUT $ZHOME, NAME $ZTN1,&
CPU 0, NOWAIT, PRI 170/ -BACKUPCPU -1
Indexed LNP:
>PARAM TCPIP^PROCESS^NAME $ZB019
>PARAM ZTNT^TRANSPORT^PROCESS^NAME $ZB019
TELSERV/TERM $ZHOME, OUT $ZHOME, NAME $ZT019, &
CPU 0, NOWAIT, PRI 170/ -BACKUPCPU 1
In CIP, network partitions are created through the SCF PROVIDER object. Similarly to
NonStop TCP/IPv6, you must run a Telserv process for each PROVIDER through
which you want Telserv to service connections. Use the same DEFINE and PARAM
command for PROVIDERs as you use for LNPs. The TCP/IP process name shown in
the example for LNPs, $ZSAM1 and $ZB019 would be the CIP TPNAMEs associated
with the SCF PROVIDER object instead of the NonStop TCP/IPv6 socket access
method processes. Both the TCP/IP processes configured for LNP in NonStop
TCP/IPv6 and the TPNAME of the PROVIDER object configured in CIP are TCP/IP
transport service providers that have been configured to be restricted to particular IP
addresses.
For complete information on logical network partitions, see the TCP/IPv6 Configuration
and Management Manual. For information about configuring PROVIDERs, see the
Cluster I/O Protocols (CIP) Configuration and Management Manual.
Fault Tolerance
When you specify the -BACKUPCU option, the Telserv process runs as a NonStop
process pair. Failure of the primary process terminates all connections to Telserv, and
all current users must reconnect. The backup process takes over and becomes the
primary process. As the new primary process, it attempts to create a new backup for
itself.
If the takeover was due to process failure, this new primary process creates its backup
in the CPU in which the failed process was running.
If the takeover was due to CPU failure, the new primary process does not select the
next available CPU to launch its backup, but rather creates its backup when the failed
CPU is reloaded.