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

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:

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.

See Also

file-save Command

Hot Backup

Network Save/Restore

set-device Command

set-dptr Command

startlog Command

stoplog Command

t-det Command

tape-socket Command

tlog-restore Command

touch Command

txlog Command

txlog-off Command

txlog-on Command