OSI/TS Configuration and Management Manual

Configuring the OSI/TS Subsystem

OSI/TS Configuration and Management Manual—424831-001

3-22

Creating Configuration Command Files

You can develop a configuration command EDIT file by making a log file of your

interactive commands while they are executing. After executing the necessary

configuration commands, edit the log file, deleting any messages or command output

that was returned. Use the resulting file as your configuration command file.

By changing command files that already exist, you can create new configuration

command files to perform tasks for your installation. If the command sequence of an

existing command file closely follows the sequence of tasks you need to perform, you

can save time by using that files basic structure. Unless you invoke the new file,

however, the system will not implement the changes.

When using command files, you might want to use the SCF DELAY command to

suspend activity for a short time to allow a command to complete. This is most likely to

be needed when a command that is time-consuming—such as a command that uses a

wild-card name to abort many subdevices—is followed by commands that depend on

the completion of the first command. The DELAY command is also more likely to be

needed when the CPU in which the TSP process runs is heavily loaded.

For example, the command following an ABORT command in a command file could

conceivably complete before the object aborts. Issuing a DELAY command allows an

ABORT command to complete before execution of the next command begins. In

addition, the SCF ALLOW command with the ALL option allows a command file to

complete despite the occurrence of errors that might otherwise cause the execution of

the command file to terminate.

Because it slows down the execution of command files, the DELAY command should

not be overused.

Command File for Configuring OSI/TS Over an

X.25 Network

This is an example of a command file to configure a generic (no SNDCF) loopback test

over an X.25 Telenet network. In this configuration, there are two TSP processes on the

same system that connect via an X.25 network (in other words, data goes from one

process, out through the X.25 network, and back to the same system, to the responding

process). $tsp1 is the local process (the initiator) and $tsp2 is the remote process (the

responder). Each TSP process is configured with three subdevices, as follows:

•

Subdevices a and b are configured using NSAP addresses

•

Subdevice c is configured using X.25 addresses

Connections can be made between the following subdevices:

#251a and #252a

#251b and #252b

#251c and #252c