Distributed Systems Network Management (DSNM) Subsystem Interface Development Guide

I Process Development Process

Distributed Systems Network Management (DSNM) Subsystem Interface Development

Guide—109759 3-3

I Process Program Structure Concepts

The following concepts are central to the I process program structure:

Frame

A frame is a set of compiled procedures supplied by Tandem into which user-written

subsystem-specific code is bound to produce an I process that conforms to DSNM

protocols. The frame carries out the following major functions:

•

Initialization and configuration

•

Thread management

•

Communication with the DSNM requester (usually the command server)

•

Communication with the subsystem CI (any gateway to the subsystem for control

purposes)

Thread

A thread is an independent instruction stream capable of being interleaved in execution

with other instruction streams (under the control of the frame). In this manual, an

executing instance of a command thread is called simply “a thread,” and the procedures

that compose it are called the “thread procedures.”

You use I process-development library services to write TAL procedures executed by the

frame as an independent thread, called the “command thread.” These procedures

collectively perform the following major functions:

•

Translation of DSNM commands into subsystem-specific commands

•

Construction of command buffers to be sent to the subsystem CI

•

Interpretation of response buffers returned by the subsystem CI

The frame handles the bulk of the complexity of the requester-to-I process and process-

to-CI interactions. Library services support frame and user-written operations such as

memory management and list processing.

Figure 3-2 illustrates the relationship between the I process program frame supplied by

Tandem and the user-written procedures _COMMAND^PROC, _STARTUP,

_STARTUP^MODE, and _COMMAND^TERMINATION^PROC.

See Table 3-1 for an overview of the defines, procedures, structure templates, and user-

written procedure identifiers referenced in this illustration and in code examples

throughout this section.

Caution. All $RECEIVE operations are done by the frame on behalf of the I process; the

frame does this by calling internal DSNM library procedures. Do not perform any NonStop

Kernel file operations that affect $RECEIVE, such as FILE_OPEN_ or

FILE_GETRECEIVEINFO_. Processes may fail or behave unpredictably if you attempt to open

$RECEIVE.