OSI/AS Management Programming Manual

Running an EMS Consumer Distributor
Communicating with the OSI/AS Processes
2–4 056785 Tandem Computers Incorporated
Your management application can then add PROCESS or other objects to the MIB, or
change existing MIB entries, by sending OSI/AS ADD and ALTER programmatic
commands.
Finally, your application must send START PROCESS commands, using the indirect-
process-name (described under ZCOM-OBJ-PROCESS in Section 4), to start the
configured TAPS and TSP processes in the OSI/AS environment. (The NSP processes
are started at cold-load time or by directing a START LINE command to the
underlying X25AM or TLAM subsystem; for details, refer to the management
programming manuals for those subsystems.) The OSI/AS subsystem is then ready to
accept incoming connection requests from communications applications.
If the OSI manager process stops, it is deleted and must be rerun. However, the TAPS
and TSP processes continue to run, and communication over existing connections is
not interrupted.
Closing and Stopping
OSI/AS Processes
Since your application does not open the OSI/AS processes directly, it does not need
to close them when it has finished. It need only close SCP, as described in the
Communications Management Programming Manual.
Your application can stop TSP and TAPS processes by sending OSI/AS STOP or
ABORT programmatic commands. You can also use these commands to stop the OSI
manager process. However, if you STOP or ABORT the OSI manager process, the
process is deleted; it must be rerun using a RUN command or a NEWPROCESS or
PROCESS_CREATE_ call, as described earlier, before it can be started again.
Normally, NSP processes run continuously once they are installed through SYSGEN.
You cannot stop NSP processes using OSI/AS commands. For more information
about NSP processes, refer to the X.25 Access Method (X25AM) Manual or the
Multilan/TLAM Management and Operations Manual.
Running an EMS
Consumer Distributor
Before your application can retrieve event messages generated by OSI/AS and other
subsystems, you must start an Event Management Service (EMS) consumer distributor
process, open this process for SPI communication, and specify the source of event
messages with a CONTROL command. The Communications Management Programming
Manual gives summary instructions for these steps, and the Event Management Service
(EMS) Manual provides full details.
To avoid receiving all event messages from all subsystems (something you will rarely
want to do), you must install a filter to select only those messages your application
intends to act upon. You install your filter when you start the consumer distributor.
Filters are written in the EMS filter language, which is described in the Event
Management Service (EMS) Manual.
Appendix C provides several examples of filters that you could use for events
generated by OSI/AS and related subsystems. This appendix also provides a sample
program that starts an EMS consumer distributor and performs the other steps
outlined above.