Tape Socket

Tape socket defines a tape system across a network. This section is an introduction to the functionality of the tape over a network subsystem.

Documentation Structure

The tape system over a network documentation is divided into the following topics:

Tape Socket	Provides a general introduction about the tape over a network, its capabilities and the fundamental notions.
Network Save/Restore	Describes how to use the tape over a network utility to do a full save on one system, and a full restore on another simultaneously.
tape-socket Command	Provides a detailed reference of the tape-socket TCL command.

The objective is to establish a pipe between two systems through which tape blocks can be transferred: On the sender’s side, the tape process (for example, t-dump) writes the tape blocks into a pipe, and, on the receiver’s side, the associated process (for example, t-load), reads the blocks and processes them, as shown in the following figure:

However, it is not possible to send data directly from a pipe across a network. This is solved by creating servers on both the sender and receiver. These servers work closely together to establish a communication path and maintain it. This principle is represented by the following figure:

The principle is to have phantom processes on both the sending and the receiving systems establishing a network communication, and exchanging data with the tape processors through a UNIX pipe. On the receiver’s side, T is the process reading from tape, running a t-load, for example, and P is the phantom process handling the network reception.

On the sender’s side, T is the process writing to tape, running the t-dump, and P is the phantom process handling the network emission.

On each machine, a UNIX pipe is set up to allow data exchange between the phantom process and the tape process. This pipe must be set up in the D3 configuration file of each machine as a network device (type C).

Optionally, the system can be linked to the transaction log system, to automatically create a hot backup system where all updates to a main machines are sent over the network to a backup system, which is a mirror image of the main system, ready to take over the application in case of failure of the main system.

The network is accessed through the BSD socket library.

Servers

The phantom processes on each system act as a server for the other system. In the following, the phantom process is called the input server on the receiver’s side and the output server on the sender’s side. On each system, the servers are identified by a server name. The System Administrator defines all working parameters at install time, and whether the servers should be linked automatically to the transaction logger. On most configurations, there is only one server. Therefore, the System Administrator would use the default server name, which is used in the menus.

Features

Automatic startup of Servers.
Automatic reconnection of Servers in case of network failures.
Synchronization of clocks when Servers are started. The sender system executes a remote set-date and set-time on the remote system with its own time and date, to ensure they are in sync. This can be prevented using the s option of the tape-socket TCL command.
Optional tracing of all network traffic.
Optional automatic link to the Transaction Log subsystem to have an automatic startup of both systems.
Optional interface to the transaction logger to regularly test that the transaction logger is operating properly.
Optional notification to a designated D3 user of network and transaction logger incidents.
Remote commands can be sent from the Output Server to the remote Input Server. This allows some degree of remote system administration of the Input Server.
Automatic installation of the software the first time the command is used.
Simple menu interface for management of the default Server and TCL interface for use in macros.
Short, rotating, log file, for the most recent error messages, and separate permanent log for long term monitoring.

Automatic Startup

Once a Server has been set up, a simple TCL command starts it. This command can be inserted in the user-coldstart macro. If the Server has been linked with the transaction logger (see below), and if the Server is the Output Server, the transaction logger is also started, or restarted, automatically as a phantom process. If the Input Server is linked to the Transaction Logger, then a transaction restore is started automatically on the terminal by running the start command, in which case this command, if inserted in the user-coldstart macro, is the very last command.

Automatic Connection of Servers

By default, the Servers are trying to communicate with each other, so that the connection is established automatically. In case of network problem, the Output Server tries every 5 seconds to re-establish the communication. When the communication is broken, and cannot be re-established in less than 5 seconds, a message is sent to the System Administrator. After this, another message is sent when the communication is re-established. There is normally never a need to stop the Input Server. The Output Server can then be stopped and restarted.

Linking to the Transaction Logger Subsystem

This feature allows to completely control the transaction logger (sender) and the transaction restore (receiver) by the tape-socket Servers, in a hot backup configuration. Once the Input Server has been started on the backup system, all operations can be done from the main system. Starting the Output Server starts the transaction logger. Stopping the Output Server detaches the tape from the transaction logger, and sends a message to the Input Server, so that the transaction restore can be restarted automatically. The Transaction Log Test Polling feature allows detecting transaction logger incidents by notifying the System Administrator that the test item has been received in time by the backup system (see more on this below). Before starting or stopping the transaction logger, the Output Server makes several controls, to be sure the transaction logger is ready. If not, the process is cleaned up, and, if required, a new UNIX process is spawned.

It is important, once the Servers have been linked to the Transaction Log Subsystem, to start/stop the transaction logger and/or restore exclusively through the tape-socket server start/stop commands (or through the menus). Failure to do so generates error messages to the System Administrator who will have to do some manual intervention to correct the situation. The Transaction log menu can still be used to obtain the status of the transaction logger, but not to start, stop or detach the tape. If it is necessary to release the transaction log queue, and, to do so, use the transaction log menu, stop the Output Server first, or else, not only is the data lost, but the transaction restore is desynchronized and will have to be restarted manually.

Transaction Log Test Polling

Periodically, for example every 10 minutes, a test item test is written in a test file dm,ts.log,test, created automatically. This item contains unique information, and a time/date stamp. If the transaction logger and the restore are working properly, this test item is transferred into the same file, on the backup system where the arrival time and data are recorded in the item. Before updating the item, however, the Output Server sends a message to the Input Server to check whether the previous test item arrived correctly. If so, everything is fine, and the Output Server is able to calculate an approximate transfer time (which includes not only the actual transfer time, but also the time the test item stayed in the transaction log queue). If the item did not arrive, a message is sent to the System Administrator. Note that, especially if the polling period is short, it is possible for the test item to still be in the queue, and, therefore, make it appear that it was not transferred. If the queue is really large, it is possible that it may take a long time before the test time progresses to the top of the queue before being transmitted.

TCL Command

The tape-socket TCL command is used to create the Input or Output Server and control their activity.

System Setup

The details of the system setup can vary depending on the application (hot backup, network save/restore, and so on). These are general guidelines:

Establish a network between the two systems. This network must support TCP/IP (for example, Ethernet, Token Ring, and so on). The System Administrator must set the network names of both systems, even though only the receiver’s host name is used.
Determine a free TCP/IP port number. Use the netstat -a UNIX command to see what is currently in use. A value like 2000 or 3000 is usually safe.
Create UNIX pipes on both system, using mknod, and make sure they have appropriate permissions. Put these pipes as pseudo tapes in the D3 configuration files of both systems.
Set up the Servers on both systems.
Start the Input and Output Servers.

Server Setup

The tape-socket menu has a Server Setup option that asks for the necessary running parameters. Some basic elements have to be defined by the System Administrator for the system to operate. If values are already defined, they are displayed between brackets, and pressing ENTER leaves them unchanged.

Server Name	Using the other server submenu, you can manipulate more than one server. A server name is any alphanumeric string (periods (.) are not allowed), of up to 8 characters. The default is tserver.
Server Type	Required. Enter in for Input Server and out for Output Server.
Remote HOST name	Enter the network name of the system on which the Input Server resides. This parameter is required for the Output Server setup, to know on what piece of hardware the Input Server is started. The host name must be declared in the UNIX file /etc/hosts.
TCP/IP port number	Required. Select a valid (>1024, <32767), unused TCP port number. Use the netstat -a UNIX command to find out which ports are currently used on the system. Both Servers must agree on this value, or else they will not be able to communicate.
Protocol	Required. Currently, only inet (Internet Protocol) is supported.
UNIX pipe name	Select a valid UNIX pipe name (for example, /dev/tape). If it does not exist, it must be created and added in the D3 configuration file, using the TCL command config tape, for example. This value is required.
Number of trace messages to keep	Number of log entries (from 4-16) that are stored in a circular buffer. These can be displayed with the status option. All messages (except OK messages) are kept in the Permanent Log.
D3 user to notify in case of errors	Enter one or more D3 user-IDs, separated by commas. The system sends a message to, in case of error. If left empty, then dm or SYSPROG is notified. In case of repetitive errors, these messages can become a nuisance, and can be suppressed later. However, it is strongly advised to select at least one user who would always be logged on to the system so that errors do not go unnoticed. The whole system normally operates without much human intervention, and if notification is disabled, or if the user to notify is not logged on, communication can be interrupted for a very long time before an error is corrected. Errors are also logged to a file. To select all users on the system, enter an * (asterisk). To send a message to a line number, whether it is logged on or not, use an exclamation mark followed by the line number in decimal (for example, !0). To disable the notification, enter off.
Transaction Log test polling period	Enter the value in seconds, or in HH:MM:SS of the period with which the Output Server tests the operation of the transaction logger. If the transaction logger is not used, enter 0 to disable the polling. See Transaction Log Test Polling for a detailed discussion of this mechanism. An appropriate value would be between 00:01:00 (1 mn) to 01:00:00 (1 hr). A smaller period could create false alarms by long delays due to the size of the queue. A longer period means that an incident would go unnoticed for a long time. As a rule, if the normal data update rate is small, then the test period should be small too. In case of mass transfers, such as running a touch of an entire database, which would generate an enormous amount of data transfer, it is advised to temporarily increase the polling period to a large value (for example, 1 hr), so that the Output Server does not panic at not seeing its updates of the test item go through the network.
Start Transaction logger	Determines whether the Server is to be linked to the Transaction Log Sub-System, to set a hot backup configuration. Type on to establish the link, and off to disable it. When on, the Servers attempts to control the Transaction logger and restore. When selected, be sure to understand the relationship of the two subsystems as discussed in Linking to the Transaction Logger Subsystem. The most important rule is to control the transaction logger exclusively through the tape-socket menus or commands, to make sure the servers are aware of the states of the Transaction Log Sub-System.
Log (DL) files or ALL	Required only for the Output Server if it is linked to the Transaction Logger. It determines the options with which the Transaction Logger is started when the Output Server is itself started. Enter dl to log only the files for which the attribute 1 of the D-pointer has been changed to have an L code. Enter all to log all updates to all files. NOTE—Be careful with this second option, since updates to system files, such as the ABS, users, and so on are also logged.
Transaction Log queue period	Required only for the Output Server if it is linked to the transaction logger. It determines, in seconds, the time after which an update is actually transmitted to the remote system. Enter 0 for the default value (currently 30 seconds). When working with a fast network, a typical value would be 2 or 3 seconds. This parameter means that an update to a file would stay on the master system for 2 or 3 seconds, for example, before being sent to the remote system. In case of system crash, only these updates would be lost.