Network Control Operations Guide

NET24-XPNET™

Version 4.1, September 2021

Table of Contents
About this publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
What’s new in this publication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction to network control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
The XPNET system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
The XPNET process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Overview of the XPNET components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Process descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
XPNET file descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Pathway configuration and control file descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
XPMON configuration and control file descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Internal destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
XPNET network control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Operator interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Event message logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Network audit facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Network control utility programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. XPNET components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
The XPNET system name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Standard subvolumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
The control subvolume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
The XPNET system data subvolume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
The application data subvolume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The configuration journal subvolumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The network overload management subvolumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
XPNET file naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Network environment file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Network map file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Logical network configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
PPD naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
PATHMON or XPMON process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
XPNET process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
NCPI server process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
NCP server process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Example of XPNET system file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
XPNET object naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Stations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
 Dests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
States and network operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
States and object availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
State transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3. Network control facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Network control point communications utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
NCPCOM utility environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Using the NCPCOM utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Network control supervisor screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Function keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Using the NCS screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Entering commands from the NCS screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Using obey files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Uses for obey files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Example obey file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Network control security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Open Network Control Facility (ONCF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ONCF Functional overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
System assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
General processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ONCF security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
NCP lexicon message format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Variable token structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4. Aspects of network control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
XPNET licensing scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
License filename and location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Determining the license in use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Loading a new license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Verifying a license. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Renaming the license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Primary and backup XPNET processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Shutdown and startup procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Shutdown procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Startup procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Changing the system time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Message routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Destination string routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Service-based routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Broadcast messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Destination table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Queue management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Monitoring message queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
 Viewing queued messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Managing message queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Network overload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Event message content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Auditing message traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Designating stations, processes, and specific messages to be audited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Internal audit process and audit files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
External audit process and audit files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Audit file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5. Configuring an XPNET system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Overview of configuration procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Defining the NCP and NCPI server processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
NCP server process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
NCPI server process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Emergency assigns and params for the NCPI server process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Defining and adding objects to an XPNET system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Displaying current values for attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Resetting attributes in the working set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using configuration input files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Guidelines for defining and adding objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Node definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Process definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Link definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Line, device, and station definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Dest definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Making changes to the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Moving objects from one XPNET node to another . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Deleting objects from an XPNET system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Generating a command file for the current configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Managing the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Marking a stable configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Rolling back changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Managing the configuration journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Managing a contingency configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Configuring disaster recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6. Utility programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
LIVERIFY utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
NETADRD and NETADRT utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Running the NETADRD utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Running the NETADRT utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Processing the audit file in real time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
NETADRD and NETADRT output examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
NETADRD filter processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
 NETDMPRD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Running the NETDMPRD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
NETCJRD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Running the NETCJRD utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
NETCJRD report example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
RELPROC macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Running the RELPROC macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
RPCGEN utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Running the RPCGEN utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
XNCGEN utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Running the XNCGEN utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Appendix A: Examples of XPNET obey files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Pathway environment obey files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Pathway configuration file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
PATHCOLD file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
PATHCOOL file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
PATHSTRT file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
SHUTDOWN file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
PATHSTOP file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
GOAFT file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
XPMON Environment Obey files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
GOXMON file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
GOXNCXP file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
XPCONF file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
PURGENET file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
STOPXMON file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Obey files for both environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
EMPSPLOCL file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
NEFLIST file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
GONCP file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
STRTLOG TACL Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
STOPLOG Obey file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Appendix B: Sample XPNET node configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Appendix C: Network control command security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Network control commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Network control security profile file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Function keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Adding an NCSP record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Updating an existing NCSP record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Copying an NCSP record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Network control security specification file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Function keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Adding an NCSS record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
 Security errors and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
SET PASSWORD errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Other security errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Appendix D: X.25 Network Inquiry (XNI) screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
XNI screen description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Function keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
XNI operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Statistical responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Statistics request failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Appendix E: Unknown destinations (#DIAG-DEST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Appendix F: NET24-XPNET audit process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Internal audit process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
External audit process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Appendix G: OSS KILL Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Notices
ACI Worldwide

Offices in principal cities throughout the world.

[Link]

Americas +1 402 390 7600

Asia Pacific +65 6334 4843

Europe, Middle East, Africa +44 (0) 1923 816393

© Copyright ACI Worldwide, Inc. 2021

All information contained in this documentation, as well as the software described in it, is confidential and proprietary
to ACI Worldwide, Inc., or one of its subsidiaries, is subject to a license agreement, and may be used or copied only
in accordance with the terms of such license. Except as permitted by such license, no part of this documentation
may be reproduced, stored in a retrieval system, or transmitted in any form or by electronic, mechanical, recording,
or any other means, without the prior written permission of ACI Worldwide, Inc., or one of its subsidiaries.

ACI, ACI Worldwide, the ACI logo, ACI Universal Payments, UP, the UP logo and all ACI product/solution names are
trademarks or registered trademarks of ACI Worldwide, Inc., or one of its subsidiaries, in the United States, other
countries or both. Other parties' trademarks referenced are the property of their respective owners.

1
About this publication
This publication describes the NET24-XPNET™ network control functions. It provides descriptions of the various
functions used in configuring, monitoring, and controlling an XPNET system.

Audience
This publication assists network operators and system managers to configure and operate an XPNET system.

Hardware-specific variations
NET24-XPNET publications contain some references to products and utilities that vary depending on which HP
platform is in use. This section explains how references to products and utilities that vary by HP platform are
documented.

References to Inspect imply platform-specific versions of the Inspect product, such as eInspect on the HP NonStop
NS-series platform, which is required for debugging TNS/E processes.

The ACI Sudoterm virtual hometerm utility is discontinued for the HP NonStop NS-series platform. Customers should
use the HP Virtual Hometerm Subsystem (VHS) product instead of the Sudoterm utility on the NS-series platform.
The Sudoterm utility is still available for use on earlier platforms (for example, NonStop S-series).

On the HP NonStop NS-series platform, the HP Object Code Accelerator (OCA) utility is used to accelerate
nonnative objects. On earlier platforms (for example, NonStop S-series), the HP AXCEL utility is used to perform this
function.

Syntax notation
Syntax descriptions in this publication use several symbols and conventions to denote how commands and naming
conventions should be entered. These conventions are described in the table below.

Notation Meaning
UPPERCASE LETTERS Indicate key words and literals that you must enter exactly as shown.

lowercase italics Identify variables that you must provide.

Brackets [ ] Enclose optional syntax items that you can enter in the command.

Braces { } Enclose a group of items from which you are required to choose one
item. The items are separated within the braces by a vertical bar (|).

Vertical bar | Separates alternatives in a list of items.

Ellipsis … Indicates the immediately preceding syntactical item can occur one or
more times.

2
Notation Meaning
Punctuation Must be entered as shown. This includes parentheses, commas,
semicolons, and other symbols not previously described.

Spaces Are required as delimiters wherever it would be otherwise impossible to

discriminate between adjacent words or symbols. You can insert
additional spaces between any adjacent words or symbols, but not
within a word or multiple character symbol.

bƀ The ƀ b character is used to show a space where the number of spaces

is critical. For example, a field can have a valid value of a letter 'x',
three spaces, and then the letter 'y'. The valid value is represented as
"xƀƀƀy".
"xbbby".

Indented lines Indicates a continuation of the preceding line of syntax. If the syntax of
a command is too long to fit on a single line, each continuation line is
indented.

Field descriptions
Each field appearing on a file maintenance screen or report is listed by name and then described. Field descriptions
briefly summarize the contents, purpose, and permissible values, as shown in the following example taken from the
description for the NCS screen.

Example

USER

The name that uniquely identifies you as an operator. Depending on how your system security is set up, this can be
the same name that you entered on the Logon screen, or it can be a different name specifically for use in executing
network control commands.

Each time you issue a command from this screen, your user name and password are sent with the command. These
fields are used to verify your access to each command.

Field Length: 1-16 alphanumeric characters

Required Field: Yes

Default Value: The user name previously entered.

Explanation

Each field description is completed by one or more of the following items of information:

3
Item Description
Field Length Specifies the size of the field and the type of characters that can be entered. This
length refers to the field and valid values for the file maintenance screen, not the
field in the DDLs. Possible values are alphabetic, alphanumeric, hexadecimal,
and numeric. The term alphanumeric includes all alphabetic, numeric, and special
characters that can be entered from a keyboard without using a control sequence.
The term hexadecimal includes all numbers and the letters A through F.

When a field value cannot be modified by the operator, the field length is System-
protected.

Required Field Specifies whether a value has to be entered in the field. Possible values are Yes
and No. Some fields are required only under certain conditions. In this case, the
entry is Yes, followed by the conditions that determine when the field is required.

Default Value Specifies the value that is automatically placed in the field when the screen is first
displayed or when the F8 key is pressed to clear the screen.

What’s new in this publication

The following highlights the major changes that have been made in the most recent update to the NET24-XPNET
Network Control Operations Guide.

Release 4.1, September 2021

These changes update the publication to release 4.1.

Section Major changes

OSS KILL Adds OSS Kill Process appendix
Process

XPNET Updates the PREFIXDSTS attribute to use an "S" for stations and "L" for lines as the first letter
components when setting up the configuration for dynamic stations.

Configuring an
XPNET system

Configuring an Updates the TEMPLATE attribute to mention that RADDR must be spaces to use TEMPLATE.
XPNET system

Release 4.0, February 2020

4
Section Major changes
multiple Removed references to satengine from this publication.

multiple Added DRPRO (disaster recover) process

multiple Added NETADRT (external audit process over TCP-IP) utility information

4 XPNET license updated to include automatic shutdown if license is expired more than 180
days.

4 "Determining the status of services and service providers" now includes service information for
all providers

E Added #DIAG-DEST functionality to EAUDPRO

Release 3.4, December 2017

These changes update the publication to release 3.4.

Section Major changes

1 Updates the graphics in the topic "Overview of the XPNET components" to include the external
audit process.

3 Adds the topic "Open Network Control Facility (ONCF)" and subtopics. These topics were in the
NET24-XPNET ONCF Management Programming Guide in previous releases.

Clarifies in the topic "ONCF functional overview" how the Pathway process differs from XPMON
in accessing the NCP and NCPI processes.

4 Renames the topic "Audit files" to be "Internal audit process and audit files". Adds the topic
"External audit process and audit files".

5 Adds the new param DELIVER-NOMOVERRIDE to the topic "NCPI server process.

Adds the topic 'Reducing "Out of Memory" error'

Adds the following new Node attributes: EXTINCREMENT, EXTAUDPRI, EXTAUDBACK,

EXTAUDPAGES, EXTAUDSTATINT, EXTAUDIO, EXTAUDFILECDE, EXTAUDTCPIP,
EXTAUDRETDAYS, EXTAUDQAT, EXTAUDQMI, EXTAUDQMT, RTS

Adds the following new Process attribute: TCPRETRIES

Adds the following new Station attributes: SSLCPRAES128GCM, SSLCPRAES256GCM

5
Section Major changes
6 Adds a graphic to the topic "NETADRD utility" to illustrate the difference between internal and
external audit processes.

Appendix F Differentiates between the original audit process, which is now know as the "internal audit
process", and the new external audit process.

Release 3.3, December 2015

These changes update the publication to release 3.3.

Section Major changes

All The format has been modified, and minor changes have been made to headings and text to
conform to ACI standards.

2 Changed the naming convention for stations to include dynamically created stations.

4 Added example of new command BSISTATUS to the " Determining the status of services and
service providers" topic.

5 Changed the examples in the "Displaying current values for attributes" topic to reflect new
attributes.

5 Changed the "Estimating the number of extended memory pages" topic to include ACI’s latest
recommendations for large messages.

5 Added the following new Node attributes: HSMLOCALADDR, SBASTALETIMER,

SBASTALETIMEOUT, SBASTALEACTION, SSLRECSIZE, SSLSEGSIZE, SSLWRAP, XPMON

(also removed HSMCHECKDIGITS as it is currently not used).

5 Added the following new Process attributes: CONNTYPE, LOCALADDR, PROTOCOL,

REMOTEADDR1, REMOTEADDR2, REMOTEADDR3, REMOTEPORT1, REMOTEPORT2,
REMOTEPORT3, RTS, RTSINIT, SENDTIMER, TCPIPRO

5 Added the following new Link attribute: RTS

5 Added information about dynamically created stations. Added the following new Station
attributes: ENCRYPTTHENMAC, IGNORECONNID, INITDSTS, INTVALDSTS, LARGEMSG,
MAXDSTS, PREFIXDSTS, RTS, TEMPLATE, TCPLISTENLINE

5 Added the following new Dest attributes: RTS

6
Section Major changes
Appendix Moved the HP NonStop SVREAD libraries license terms to the NET24-XPNET Introduction
Manual.

Release 3.2, December 2013

These changes update the publication to release 3.2.

Section Major Changes

Preface Updates preface and other front matter to current ACI standards in new sections "About this
document" and "What’s New."

all Throughout this manual, adds a new environment called XPMON that provides communication
without Pathway. Pathway is no longer required to communicate with the XPNET system but is
still available; it is referred to as the Pathway environment.

Also throughout this manual, adds support for internal TCP/IP protocol.

1 Adds diagram showing the XPMON process in place of the Pathway process. In addition, the
XPMON process no longer uses the NCS screen to communicate with the system but relies on
the NCPCOM utility. Describes the new obey files and macros used by XPMON: GOXMON,
GOXNCXP, STOPXMON, and XPCONF.

2 Adds information about the file structure of the XPMON environment.

Adds literals for the internal TCP/IP protocol: TCPC, TCPSC, TCPSL

4 Updates to the "Primary and backup XPNET processes" topic to add the SBCPU attribute.

Updates to the "Shutdown and startup procedures" topic to describe the XPMON procedures.

5 Adds new attributes to the valid values for Dest, Device, Line, Link, Node, Process, and Station.

7 Adds examples of obey files for the XPMON environment: GOXMON, GOXNCNXP, XPCONF,
PURGENET, and STOPXMON

A-G Renames Appendices A through D with section numbers.

7
Chapter 1. Introduction to network control
Network control is a broad term encompassing all aspects of keeping an XPNET system operating efficiently
according to the policies and operating procedures of an organization. This includes functions such as monitoring
the general operation of the system, keeping the various lines up and stations running, starting and stopping
processes, and adding and reconfiguring destinations, nodes, processes, lines, links, and stations.

Since network control operators are responsible for the overall well-being of an XPNET system, it is important that
they have a basic understanding of the various processes in the system and how these processes interact with each
other and with the various files in the system. Having an understanding of the system helps in isolating problems and
determining what portions of the system can be affected.

This section provides an introduction to an XPNET system and to network control functions.

The XPNET system

The fundamental element of an XPNET system is an XPNET node. An XPNET node consists of an XPNET process,
application processes, communications lines, and stations. An XPNET system can contain one or several XPNET
nodes. The individual XPNET nodes can be replicas of each other or they can provide unique processing functions
and communications connections.

The XPNET process

The XPNET process is the hub of the XPNET node. It acts as the main controller, and most processes and stations
interface with each other through the XPNET process.

The XPNET process is responsible for the following functions:

• Driving the data communications lines

• Controlling all lines, stations, and processes in the XPNET node
• Routing messages
• Managing message queues
• Running system audits
• Communicating with other XPNET processes in the system
• Monitoring the performance of the system
• Enabling continuous processing

Overview of the XPNET components

An XPNET system is a structured network of XPNET nodes, lines, links, stations, processes, and devices. A
production system can contain several XPNET nodes spanning two or more HP NonStop systems.

Nodes, processes, lines, links, stations, dests, and devices are objects contained in an XPNET system. An object is
a component of an XPNET system that is identified by a symbolic name and that you define and control using
XPNET network control commands. On each node, these objects are defined in a special control file called the
Network Environment File (NEF), which contains attributes for controlling the individual objects including attributes

8
for the node itself.

For object management or inquiry commands, use the symbolic name of the object to identify the line, station,
process, node, link, dest, or device on which the command is to act.

All XPNET systems are configured with a common set of procedures whether a system is a single XPNET node, or
many XPNET nodes spanning geographically distributed HP NonStop systems. Objects are configured with SET
commands and then added to the system with ADD commands. Individual object attributes can be changed using
the ALTER command. Procedures for adding objects and for setting and changing object attributes are described in
Configuring an XPNET system. The syntax for these commands is described in the NET24-XPNET Network Control
Command Reference Manual.

You may need to add objects or make changes to your processing environment. You can make online changes using
object management commands. These changes are immediate and can be used to reconfigure the system in real
time.

The following diagram shows the components of one XPNET node, using the Pathway environment. Pathway is
software from Hewlett Packard that manages various processes.

The second diagram shows the components of one XPNET node, using the XPMON environment (without
Pathway). The XPMON environment, starting in Release 3.2, is designed to provide functionality previously provided
in Pathway so that a separate Pathway license is not required. Pathway and its associated processes are still
available for those customers who have the Pathway license and want to continue to use them.

9
10
Process descriptions
The following are brief descriptions of the processes found in all XPNET systems. The names given are not the

11
actual process names, but generic names representing the type of function those processes are performing. These
processes are defined in alphabetical order. Note that the XPNET process was described previously.

Process Description
Application processes Processes associated with whatever applications your XPNET system is running

Controller/Access method The hardware and operating system software used for data communications. For
example, this might represent the HP NonStop 6100 Communications Subsystem
(CSS) and EnvoyACP software.

DRPRO process Process that supports the DR (disaster recovery) replication functionality to
automatically replicate network environment file (NEF) changes to a DR site. See
Configuring disaster recovery.

LIVERIFY utility Utility program that searches for the most recent XPNET license file on the
XPNET subvolume, verifies the license, and displays information about the
license, including the systems it is valid for and the XPNET product modules that
have been licensed. This utility is described in Liverify utility.

NCP Server process Network Control Point Server process that routes command and control
messages to the appropriate NCPI Server process

NCPCOM utility Network Control Point Communications utility—Command interface for entering
network control commands

NCPI Server process Network Control Point Interface Server process that validates network control
commands for correct syntax and checks operator command security. This
process serves as an interface between the XPNET process and the NCP Server
process.

NCS Server process Server process that interprets network control commands coming from the
Network Control Supervisor (NCS) screen (Pathway environment only)

NCSP Server process or Server process that edits, formats, and interprets information coming from the
XPNCSP Server process Network Control Security Profile File (NCSP) maintenance screens through the
Pathway Terminal Control process (TCP). The XPMON environment refers to this
as the XPNCSP Server process.

NCSS Server process or Server process that edits, formats, and interprets information coming from the
XPNCSS Server process Network Control Security Specification File (NCSS) maintenance screens through
the Pathway Terminal Control process (TCP). The XPMON environment refers to
this as the XPNCSS Server process.

12
Process Description
NETADRD utility Utility program that reads records from audit files. These files contain records of
messages coming from and going to the XPNET process. The audit files can be
created and opened through network control commands. This utility is described
in NETADRD and NETADRT utilities.

NETADRT utility Utility program that reads audit records from TCP/IP. These files contain records
of messages coming from and going to the XPNET process. This utility is
described in NETADRD and NETADRT utilities.

NETCJRD utility Utility program that reads records in the configuration journal and creates a report
containing information about configuration changes. This utility is described in
NETCJRD utility.

NETDMPRD utility Utility program that writes queued messages from an XPNET process saveabend
file to an audit file. This program is not shown on the diagram in Overview of the
XPNET components. The NETDMPRD utility is described in NETDMPRD utility.

Pathway TCP The HP NonStop Terminal Control process, which controls the physical input and
output from the various XPNET control terminals. It forwards internal messages
from these terminals to their respective server processes.

RPCGEN utility Utility program that is used to read the XML source for configuring XPNET
message routing profiles and generate a compiled extended segment output file
that can be read by the XPNET process.

RTS process Real Time Statistics (RTS) presents internal XPNET Station, Process and DEST
information VIA a TCP/IP Client to an external entity. See the Real-Time Statistics
Implementation manual for more information.

XNCGEN utility Utility program used to read the XML source for configuring an application
process and generate a compiled extended segment output file that can be read
by the XPNET process.

XPMON process Controls the physical input and output from the various XPNET control terminals.
It forwards internal messages from these terminals to their respective server
processes.

XPNET file descriptions

The following are brief descriptions of the major files found in XPNET systems. The names given may not be the
actual file names, but generic names representing the type of information stored in the file. These files are defined in
alphabetical order.

13
File Description
Audit Contains records of messages coming from or going to the XPNET process for
audit purposes. For more information on the audit file, see Aspects of network
control.

Configuration journal Contains information about changes to the XPNET configuration. All ADD,
ALTER, DELETE, ENABLE, and DISABLE commands as well as CONTROL
NODE commands with the COMMIT and ROLLBACK directives are recorded in
the configuration journal. See Managing the configuration for more information
about the configuration journal.

NCSP Network Control Security Profile File—Contains profile records that define
command security for one or more operators. For more information on the NCSP,
see Network control command security.

NCSS Network Control Security Specification File—Assigns a command profile to an

XPNET operator. For more information on the NCSS, see Network control
command security.

NEF Network Environment File—Contains a set of control attributes and identifiers for
each station, line, process, link, device, and dest in an XPNET node as well as
attributes for the node itself.

Network overload management Contains messages saved during network overload management actions. For
more information on network overload management files, see Network overload
management.

NMAP Network Map File—Contains information about all XPNET nodes in this XPNET
system.

QWRITE Contains records of specified messages written to disk in audit file format by a
CONTROL command with the QWRITE directive or by running the NETADRD
utility. For more information on QWRITE files, see the NET24-XPNET Network
Control Command Reference Manual. For more information on the NETADRD
utility, see NETADRD and NETADRT utilities.

Pathway configuration and control file descriptions

The following table provides a brief description of files used in the configuration and control of the Pathway
subsystem. See Examples of XPNET obey files for examples of these files.

14
File Description
PATHCOLD Brings up the Pathway subsystem and builds a new Pathway Control File
(PATHCTL) from the Pathway Configuration File (PATHCONF). PATHCOLD must
be used whenever changes have been made to the PATHCONF.

PATHCOOL Brings up the Pathway subsystem without reading the PATHCONF or building a
new PATHCTL.

SHUTDOWN Brings down the Pathway subsystem in an orderly manner, stopping all terminals,
TCPs, and server processes.

PATHCONF Pathway Configuration File—Contains PATHCOM commands to be run in a

noninteractive mode. This file is used when the Pathway subsystem is started
cold (that is, when a new PATHCTL must be built).

XPMON configuration and control file descriptions

The following table provides a brief description of files used in the configuration and control of the XPMON
subsystem. Section 7 provides examples of these files.

File Description
GOXMON TACL obey file for starting XPMON.

GOXNCXP TACL file used to start XNCGEN which uses the XPCONF file to configure
XPMON.

STOPXMON Brings down the XPMON subsystem in an orderly manner, stopping all terminals
and server processes.

XPCONF XPMON Configuration File—Contains commands to be run in a noninteractive

mode. This file is used when the XPMON subsystem is started cold (that is, when
a new XPCTL must be built).

Internal destinations
There are a number of XPNET internal symbolic destinations to which messages can be routed to perform specific
functions within the network. The following table details the internal destinations which user applications can use.

Destination Description
"#DELIVERRESPONSE" This destination is used by an application to return a command response to
ONCF when a DELIVER,WAIT command is performed at NCS/NCPCOM.

15
Destination Description
"#DIAG-DEST" XPNET holds an internal queue of the last five messages sent to this destination.
Invalid messages that are otherwise dropped are written to this destination by
XPNET where they can be audited (if auditing is enabled and NODE SBIT 15, 17,
or 18 is set) or extracted from the queue using other methods. Messages routed
to this destination are also forwarded to the DIAG-DEST service or process, if one
is configured (see NET24-XPNET audit process on how to use the NET24-
XPNET Audit Process to provide the DIAG-DEST service). User applications can
also be designed to send messages to this destination for diagnostic purposes.
See NET24-XPNET audit process for more information.

"#DUMP-DEST" Messages sent to this destination are audited (if auditing is enabled and NODE
SBIT 14 or 15 is set) and then dropped.

"#NOMNOTIFYOFF" Applications can send a message to this destination to disable NOM notification
for a specific destination.

"#NOMNOTIFYON" Applications that must be notified when the Network Overload Management
(NOM) state changes for a specific destination can send a message to this
destination. The 16-byte symbolic name of the destination in question must be
specified in the message text area. The specified destination must reside on the
same node as the requesting application. A 9555 NOM-message is sent to the
application to notify it when the specified destination has changed to the NOM
state. A 9556 NOM-message is sent to the application to notify it when the
specified destination is no longer in the NOM state. As soon as XPNET receives
this message, it sends an initial 9555 or 9556 message to the source application
to inform it of the current state of the requested destination.

"#NOTIFYOFF" Applications can send a message to this destination to disable notification for
available or unavailable status of a specific service.

"#NOTIFYON" Applications that must be notified when a specific service becomes available or
unavailable can send a message to this destination. The 16-byte symbolic name
of the service in question must be specified in the message text area. A 9550
message is sent to the application to notify it when the specified service is
available (that is, a service provider is available to process messages for the
service). A 9551 message is sent to the application to notify it when the specified
service is no longer available (that is, no service providers are available to
process messages for the service).

"#QATNOTIFYOFF" Applications can send a message to this destination to disable QAT notification
for a specific destination.

16
Destination Description
"#QATNOTIFYON" Applications that must be notified when the Queue Alert Threshold (QAT) state
changes for a specific destination can send a message to this destination. The
16-byte symbolic name of the destination in question must be specified in the
message text area. The specified destination must reside on the same node as
the requesting application. A 9557 QAT-message is sent to the application to
notify it when the specified destination’s queue has exceeded its configured QAT.
A 9558 QAT-message is sent to the application to notify it when the specified
destination’s queue no longer exceeds its configured QAT. As soon as XPNET
receives this message, it sends an initial 9557 or 9558 message to the source
application to inform it of the current state of the requested destination.

"#REGISTER" Applications that must register themselves as providing a specific service can
send a message to this internal destination, specifying the name of the service in
the text area of the message. An application must send one message to XPNET
for each service for which it is a provider.

"#UNREGISTER" Applications that must unregister themselves from providing a specific service can
send a message to this internal destination, specifying the name of the service in
the text area of the message.

XPNET network control

The basic tools of network control consist of operator interfaces, event message logs, a network audit facility, and
three XPNET utility programs. These tools enable you to effectively monitor and make online modifications to the
XPNET system.

Operator interfaces
Three operator interfaces enable you to issue commands. An overview of these interfaces is provided next.

Network control facilities

The NET24-XPNET product includes two tools to control an XPNET system: The Network Control Supervisor (NCS)
screen and the Network Control Point Communications (NCPCOM) utility. The NCS screen is used in the Pathway
environment only. The NCPCOM utility is used in both the Pathway and XPMON environments. From these
interfaces, you can issue commands to the system while it is running. All XPNET system commands can be
executed from these interfaces.

You can also develop your own network management application using the management programming interface
provided by ACI. The NET24-XPNET Management Programming Manual provides information for management
application development.

X.25 network inquiry (XNI) subsystem screen

The XNI screen enables you to send supervisory inquiries into public data networks, such as the DATAPAC RAPID
service in Canada. The XNI screen is described in X.25 Network Inquiry (XNI) screen.

17
Event message logs
Another important facet of XPNET network control is provided by event message logs. These logs display internally
generated messages dealing with the operation of the network and are one of the principal tools for monitoring the
network.

The NET24-XPNET product uses the HP NonStop Event Management Service (EMS) to collect event messages.
ACI supplies template source files that provide information about each event message generated by network-level
processes. The following template source files are provided with the NET24-XPNET product:

• The NETTPLS file on the XPNET subvolume provides information about event messages that can be generated
by the XPNET process.
• The SNCPTPLS file on the XPNET subvolume provides information about event messages that can be
generated by the NCP Server process.
• The NCPTPLS file on the XPNET subvolume provides information about event messages that can be generated
by the NCPI Server process.
• The PATHTPLS file on the XPNET subvolume provides information about event messages that can be
generated by the PATH Server process.
• The CTSETPLS file on the XPNET subvolume provides information about event messages shared by all
implementations of the Common Transport System (CTS) protocol.
• The TCPMTPLS and TCPTPLS files on the XPNET subvolume provide information about event messages that
can be generated by the TCP/IP implementation of the CTS protocol.
• The PMONTPLS file on the APMSOBJ subvolume provides information about performance monitoring event
messages. This file is present only if you have installed the optional Performance Monitoring subsystem.
• The SSRVTPLS file on the APMSOBJ subvolume provides information about event messages that can be
generated by the Performance Monitoring Status Server process. This file is present only if you have installed
the optional Performance Monitoring subsystem.
• The AUDPTPLS file on the XPNET subvolume provides information about event messages that can be
generated by the NET24-XPNET Audit Process. See NET24-XPNET audit process for a description of the Audit
Process.
• The MQSITPLS file on the XPNET subvolume provides information about event messages that can be
generated by the MQSI (MQ Interface) implementation of the CTS protocol.
• The QFITPLS file on the XPNET subvolume provides information about event messages that can be generated
by the QFI (Queue File Interface) implementation of the CTS protocol.
• The UDPTPLS file on the XPNET subvolume provides information about event messages that can be generated
by the UDP/IP implementation of the CTS protocol.
• The SMPLTPLS file on the XPNET subvolume generated by XNLIB sample programs.
• The DRTPLS file on the XPNET subvolume provides information about event messages that can be generated
by the NET24-XPNET DR Clone (DRPRO) process.

For more information on the XPNET implementation of EMS, see the NET24-XPNET Event Management Manual.

Network audit facility

The NET24-XPNET product supports an audit facility that is used by systems analysts to trace communications
traffic within an XPNET system. If a system is experiencing problems, the network control operator can be called

18
upon to perform an audit so that communications traffic can be analyzed.

This function traces communications traffic between designated stations and processes and the XPNET process.
That is, it copies all messages between designated stations or processes and the XPNET process to an audit file for
subsequent analysis.

Application processes can also mark individual messages for auditing. For more information on performing an audit,
see Auditing message traffic.

Network control utility programs

The last aspect of network control consists of six utility programs: LIVERIFY, NETADRD, NETDMPRD, NETCJRD,
RPCGEN, and XNCGEN.

The LIVERIFY utility is used to verify the XPNET license before it is used in an XPNET network. LIVERIFY finds the
license just as XPNET does and lists the valid HP NonStop systems, licensed modules, and the license expiration
date.

The NETADRD utility is used to create output from an audit file. During an audit, messages are written to an audit
file. You can create a listing of an audit file for analysis or optionally create a disk file in QWRITE format to which
specified messages from the audit file have been written. Messages written to disk in QWRITE format by the
NETADRD utility can be reintroduced to the XPNET system using the CONTROL NODE command with the QREAD
directive.

The NETADRT utility is similar to NETADRD, however it uses TCP/IP as input instead of a disk file. In addition, it can
support TLS to protect the streaming transaction data. These two features add additional security protections for
sensitive trace data.

The NETDMPRD utility extracts any queued messages existing in an XPNET saveabend file and writes them out to
an audit file. The utility produces a report that contains a count of the messages written to the audit file.

The NETCJRD utility is used to create a report from the configuration journal, which contains information about any
changes made to the configuration of objects on the XPNET node.

The RPCGEN utility is used to read in XML source for configuring XPNET message routing profiles and generate a
compiled extended segment output file which can be read in by the XPNET process. Routing profile segments can
be used by the XPNET process to configure complex message routing schemes for messages originating at stations
and application processes within the network.

The XNCGEN utility is used to read in XML source for configuring an application process and generate a compiled
extended segment output file which can be read by the XPNET process. The XNC configuration is required by
XPNET in order to start processes in the OSS space on an HP NonStop system and for starting any process which
requires specific parameters to be sent to the application in the HP NonStop system startup message.

For more information on the LIVERIFY, NETADRD, NETADRT, NETDMPRD, NETCJRD, RPCGEN, and XNCGEN
utilities, see Utility programs.

19
Chapter 2. XPNET components
Each XPNET system differs based on the applications involved, operational requirements, and geographic needs.
However, each XPNET system has common system components and a common system architecture.

An XPNET system composed of one or more XPNET nodes must have all of its lines, links, stations, devices, and
processes uniquely identified. One exception is the dest object which can have the same name as the
corresponding process or station object on the same node. Besides the dest object, no object name can be used
more than once within a single XPNET node but can be duplicated in another XPNET node in the same XPNET
system. An XPNET node name must be unique on a particular HP NonStop system but can be duplicated on
another HP NonStop system. This unique identification is possible because the fully qualified symbolic name of the
XPNET node includes the HP NonStop system name. The fully qualified symbolic name of objects managed by the
XPNET process includes both the HP NonStop system name and the XPNET node name.

To facilitate the orderly development of large-scale networks, standard naming conventions should be adopted for all
objects in the NEF. These naming conventions allow for the replication of XPNET nodes and at the same time
maintain unique symbolic names for all lines, stations, and processes in an entire network configuration.

This section describes the standard subvolumes, files, and objects that are part of an XPNET system and provides
suggested naming conventions. This section also includes information about the states an object can be in. These
states are important to an operator because some commands can be executed only when an object is in a particular
state.

The XPNET system name

The XPNET system name is the name used to describe an entire XPNET configuration, regardless of the number of
XPNET nodes or HP NonStop systems in the configuration. This system name is integrated into various subvolume
and process names, as described throughout this section.

An XPNET system name should be a maximum of four alphanumeric characters, the first of which must be a letter
(for example, PROD, CERT). The first letter is significant and should be unique across all XPNET configurations
running on the same HP NonStop system. This first character is used in naming running processes (PPD names) to
ensure uniqueness when multiple XPNET systems are running on the same HP NonStop system.

A service provider frequently requires four or more concurrent XPNET systems. The following names are commonly
used:

CERT = Certification

DVLP = Development

PROD = Production

TEST = Test

The following example shows an XPNET system named PROD that spans two HP NonStop systems: \SYS1 and
\SYS2. The \SYS1 node contains three XPNET nodes named P1A^NODE, P1B^NODE, and P2A^NODE. The
\SYS2 node contains one XPNET node named P1A^NODE. Two of the XPNET nodes on the \SYS1 HP NonStop

20
system are grouped together into a logical network. A logical network is composed of one or more XPNET nodes
that access a common database. The logical network concept is optional and is generally specific to an application.

Standard subvolumes
The files in an XPNET system are located on a variety of subvolumes. To assist in maintaining consistency
throughout an XPNET system configuration, standard subvolumes have been established on which certain files
always reside. These subvolumes are described in the following table.

Subvolume Description
XPNET The subvolume named XPNET contains the files for the NETWORK object,
protocols, XPNET server processes, network control utilities, and the XPNET
templates for EMS as well as the network link files and the library files for
BASE24 applications.

21
Subvolume Description
Control One control subvolume exists per HP NonStop system per XPNET system. This
subvolume contains any command files used to create objects, and a number of
obey files used for bringing up the Pathway subsystem on the HP NonStop
system. If your application uses the logical network concept, this subvolume also
contains the Logical Network Configuration File (LCONF) and the obey file used
to start the LCONF entry program. The naming convention for this subvolume is
described below.

XPNET system data The XPNET system-level data subvolume contains the Network Environment
Files (NEFs) for the XPNET nodes on this HP NonStop system, the Network Map
File (NMAP), the Network Control Security Profile File (NCSP), and the Network
Control Security Specification File (NCSS). The naming convention for this
subvolume is described below.

Application data The application-level data subvolume contains your application data files. The
naming convention for this subvolume is described below.

XNLIB The subvolume named XNLIB contains library and utility files for NET24
applications.

Configuration journal The configuration journal subvolumes contain the configuration journal files, which
record information about any changes made to the XPNET configuration. For
more information on the configuration journal, see Managing the configuration.
The naming convention for these subvolumes is described below.

Network overload management The network overload management subvolumes contain the files that hold
messages saved during network overload management actions. For more
information on network overload management, see Queue management. The
naming convention for these subvolumes is described below.

SCRIBE The subvolume named SCRIBE contains the files used in the XPNET
implementation of EMS. For more information about this implementation, see the
NET24-XPNET Event Management Manual.

Spaces are not allowed within the subvolume names. The spaces shown in the naming
NOTE
conventions are included to clarify the components of the subvolume name.

The control subvolume

The control subvolume contains control files for the XPNET system, including the following files:

GOAFT GOENTL GONCP LCONF

22
PATHCOLD PATHCOOL SHUTDOWN STOPLOG

If you are in the XPMON environment, this subvolume contains the following additional files:

XPCONF GOXMON STOPXMON GOXNCXP

If you are in the Pathway environment, this subvolume also contains the following additional files:

PATHCONF PATHCTL PATHSTRT PATHSTOP

This subvolume can also contain any command files that you use to create objects in an XPNET system.

On each additional HP NonStop system in the network, there is a control subvolume. In each instance, these files
have the same file name and are in the same volume and subvolume.

The control subvolume is named using the format shown below.

Format

system-name CNTL

system-name - The XPNET system name. For more information on the XPNET system name, see The XPNET
system name.

Examples

DVLPCNTL
PRODCNTL

The XPNET system data subvolume

The XPNET system data subvolume contains data files used by the XPNET system. This subvolume contains the
following files:

NEFs NMAP NCSP NCSS

On each additional HP NonStop system in the network, there is an XPNET system data subvolume. In each
instance, these files have the same file name and are in the same volume and subvolume.

The XPNET system data subvolume is named using the format shown below.

Format

system-name DATA

system-name - The XPNET system name. For more information on the XPNET system name, see The XPNET

23
system name.

Example

PRODDATA

The application data subvolume

An application data subvolume exists for each application or for each logical network, if your application uses the
logical network concept. This subvolume contains your application data files. The subvolume is named using the
format shown below.

Format

mod-sys-name id DATA

mod-sys-name - The first three characters of the XPNET system name. For more information on the XPNET system
name, see The XPNET system name.

id - A one-character user-defined identifier that indicates the application.

If your application uses the logical network concept, this ID is the logical network identifier. The logical network
identifier is assigned sequentially from 1 through 9, A through Z.

Examples

PRO1DATA
PROMDATA

The configuration journal subvolumes

The configuration journal subvolumes contain files that record changes to the XPNET configuration. The XPNET
process assigns a file name of CJnnnnn, where nnnnn is a number from 00000 through 99999. This subvolume also
contains alternate key files with the naming convention of CJnnnnnA.

You can specify up to three subvolumes in one or more disk volumes. These volumes and subvolumes are set using
the CJA, CJB, and CJC attributes. For more information on the configuration journal, see Managing the
configuration.

Format

ppd-name CJ [#]

ppd-name - The three- or four-character PPD name of the XPNET process.

# - An optional one-character identifier. If you use the same disk volume for two or more configuration journal
subvolumes, you can use this identifier to differentiate the subvolumes.

Examples

P1ANCJ

24
PBNCJA

The network overload management subvolumes

The network overload management subvolumes contain files that hold messages saved during network overload
management actions. The XPNET process assigns a file name of NOMnnnnn, where nnnnn is a number from 00000
through 99999. You can specify up to three subvolumes in one or more disk volumes. These volumes and
subvolumes are set using the NOMA, NOMB, and NOMC attributes. For more information on network overload
management files, see Queue management.

These subvolumes are named using the format shown below.

Format

ppd-name NOM [#]

ppd-name - The three- or four-character PPD name of the XPNET process. Naming conventions for PPD names are
described later in this section.

# - An optional one-character identifier. If you use the same disk volume for two or more network overload
management subvolumes, you can use this identifier to differentiate the subvolumes.

Examples

P1ANNOM
PBNNOMA

XPNET file naming conventions

There are a number of files involved in the configuration of an XPNET system, three of which you create and name.
These user-named files and the naming conventions used to identify these files are described below.

Spaces are not allowed within the file names. The spaces shown in the naming conventions are
NOTE
included to clarify the components of the file name.

Network environment file

Nodes, processes, lines, links, stations, dests, and devices are defined in a special control file called the Network
Environment File (NEF). The NEF contains attributes for controlling the individual objects as well as attributes for the
node itself.

One copy of the NEF exists for each XPNET node and is unique to that XPNET node. The NEF resides on the
XPNET system data subvolume. You create the NEF using the NETDFUP file on the XPNET subvolume.

If you have set up the disaster recovery process (DRPRO), changes to the NEF can be kept in sync between the
primary and DR nodes. See Configuring disaster recovery for additional information.

The NEF is named using the format shown below.

Format

25
 N node-id NEF

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network in which the
XPNET node resides. The logical network identifier is assigned sequentially starting with 1 through 9, then
proceeding from A through Z. The second character identifies the XPNET node. This identifier is assigned
sequentially starting with A through Z, then proceeding from 1 through 9.

Examples

N1ANEF
NBNEF

Network map file

The Network Map File (NMAP) contains information about the XPNET nodes in this XPNET system on the local HP
NonStop system. This information includes the symbolic name of each XPNET process, the server class names of
the NCPI Server processes, the PPD name of the Pathmon process for the NCPI Server processes, the PPD names
of the NCPI Server processes, and the current state of the XPNET processes.

One NMAP exists for each XPNET system on each HP NonStop system. The NMAP resides in the XPNET system
data subvolume. You create the NMAP using the NCPDFUP file in the XPNET subvolume.

NMAP is named using the format shown below.

Format

NMAP

Logical network configuration file

The Logical Network Configuration File (LCONF) is an optional file that enables you to define file, process, and
spooler locations and to define processing parameters for an application. For information about how the LCONF is
used for BASE24 applications, see the BASE24 Logical Network Configuration File Manual.

One LCONF exists for each logical network in the XPNET system. The LCONF is named using the format shown
below.

Format

L # CONF

# — A one-character logical network identifier. The logical network identifier is assigned sequentially starting with 1
through 9, then proceeding from A through Z.

Example

26
L1CONF

PPD naming conventions

You specify PPD names during several processes. This subsection describes the suggested naming conventions for
those PPD names. ACI recommends that PPD names do not exceed four characters following the required literal
dollar sign ($). Note that you can use any meaningful naming convention when specifying PPD names for application
processes.

Spaces are not allowed within the PPD names. The spaces shown in the naming conventions are
NOTE
included to clarify the components of the PPD name.

PATHMON or XPMON process

For the Pathway environment, you assign the PPD name of the PATHMON process in the PATHCOLD and
PATHCOOL files. See Examples of XPNET obey files for examples of these files. This PPD name is used in the
PATH command and in the PATHMON node attribute in the Pathway environment. In the XPMON environment, you
assign the PPD in the GOXMON file, shown in Examples of XPNET obey files. This PPD name is used in the GATE
command and the XPMON node attribute.

For both environments, the PPD name is assigned using the format shown below.

Format

$ sys-nam-abbr PMN

sys-nam-abbr — Identifies the first letter of the XPNET system name.

PMN — A literal identifying this as the PPD name for a PATHMON or XPMON process.

Examples

$TPMN

This example illustrates the PPD name of the PATHMON or XPMON process for an XPNET test system (XPNET
system name begins with T).$PPMN

This examples illustrates the PPD name of the PATHMON or XPMON process for an XPNET production system
(XPNET system name begins with P).

XPNET process
The PPD name of the XPNET process is specified using the PPD attribute for the NODE object type. This PPD
name is a required attribute when you add a node and is displayed for INFO NODE and STATUS NODE commands.
The PPD name is assigned using the format shown below.

Format

$ sys-name-abbr node-id N

27
sys-nam-abbr — Identifies the first letter of the XPNET system name.

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network in which the
XPNET node resides. The logical network identifier is assigned sequentially starting with 1 through 9, then
proceeding from A through Z. The second character identifies the XPNET node. This identifier is assigned
sequentially starting with A through Z, then proceeding from 1 through 9.

N — A one-character literal that identifies this process as the XPNET process for this node.

Examples

$P1AN

This example illustrates the PPD name of the XPNET process for XPNET node A in logical network 1 on a
production system (XPNET system name begins with P).

$PAN

This example illustrates the PPD name of the XPNET process for XPNET node A on a production system (XPNET
system name begins with P).

The PPD attribute for the LINK object type must match the PPD name of the XPNET process for
NOTE the XPNET node with which the link is communicating. For example, the PPD attribute for a link
named P1ANODE.P1ALINK^P1B would be $P1BN.

NCPI server process

You set the PPD names of the NCPI Server processes in the PATHCONF or XPCONF using the SET SERVER
PROCESS parameter. There is one NCPI Server process for each XPNET node. The PPD name is assigned using
the format shown below.

Format

$ sys-name-abbr node-id U

sys-nam-abbr — Identifies the first letter of the XPNET system name.

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network in which the
XPNET node resides. The logical network identifier is assigned sequentially starting with 1 through 9, then
proceeding from A through Z. The second character identifies the XPNET node. This identifier is assigned
sequentially starting with A through Z, then proceeding from 1 through 9.

U — A one-character literal that identifies this process as the NCPI Server process, the user interface between the
XPNET process and the NCP Server process.

28
Examples

$P1AU

This example illustrates the PPD name for the NCPI Server process on node A in logical network 1 on an XPNET
production system (XPNET system name begins with P).$TAU

This example illustrates the PPD name for the NCPI Server process on node A in an XPNET test system (XPNET
system name begins with T).

NCP server process

You set the PPD names of the NCP Server processes in the PATHCONF or XPCONF using the SET SERVER
PROCESS parameter. The maximum number of NCP Server processes in each XPNET system is determined by
the value of the MAXSERVERS param in the PATHCONF or XPCONF. The PPD name is assigned using the format
shown below.

Format

$ sys-name-abbr NC number

sys-nam-abbr — Identifies the first letter of the XPNET system name.

NC — A two-character literal that identifies this process as the NCP Server process.

number — The number of the NCP Server process. The number uniquely identifies the NCP Server process when
there are multiple copies of the process running in the same XPNET system. Numbering should start with 1.

Examples

$PNC1

This example illustrates the PPD name for the first NCP Server process on the XPNET production system (XPNET
system name begins with P).

$PNC2

This example illustrates the PPD name for the second NCP Server process on the XPNET production system
(XPNET system name begins with P).

Example of XPNET system file structure

The XPNET system illustrated previously in this section showed four XPNET nodes across two HP NonStop
systems. The file structure for this XPNET system is illustrated next. The Pathway environment is shown first,
followed by the XPMON environment. The XPMON environment only shows those parts of the file structure that is
different from the Pathway environment.

29
Pathway Comments
Environment
\SYS1.$DATA PRODCNTL GOAFT Obey file to start Pathway session
PATHCOLD Obey file to cold start PATHMON
PATHCONF Pathway configuration file
PATHCOOL Obey file to warm start PATHMON
PATHCTL Pathway control file (internal version of
PATHCONF)
PATHSTOP Obey file that stops Pathway server
processes
PATHSTRT Obey file that starts Pathway server
processes
N1ACONF Obey file that contains commands to create
P1A^NODE
N1BCONF Obey file that contains commands to create
P1B^NODE
N2ACONF Obey file that contains commands to create
P2A^NODE
SHUTDOWN Obey file to stop Pathway
STRTLOG Obey file to start EMSperus utility
STOPLOG Obey file to stop EMSperus session
GONCP Obey file to start the NCPCOM utility
L1CONF LCONF for logical network 1
GOENTL Obey file to start the LCONF entry program

30
Pathway Comments
Environment
\SYS1.$DATA PRODDATA N1ANEF NEF for node P1A^NODE
N1BNEF NEF for node P1B^NODE
N2ANEF NEF for node P2A^NODE
NMAP NMAP for all XPNET nodes on \SYS1
NCSP Network Control Security Profile File
NCSS Network Control Security Specification File
XPNET DRPRO Object file for the DRPRO utility
LIyymmdd XPNET license file
LIVERIFY Utility to search for the most recent XPNET
license file
NETWORK Object file for the XPNET process
NCPCOM Object file for the NCPCOM utility
NETADRD Object file for the NETADRD utility
NETADRT Object file for the NETADRT utility
NETDMPRD Object file for the NETDMPRD utility
NETCJRD Object file for the NETCJRD utility
NCPDFUP Obey file to create NMAP
NETDFUP Obey file to create the NEF
NEFLIST Obey file to generate a listing of the current
configuration
NETB Network link files
RPCGEN Routing Profile Configuration generator
RTSPRO Object file for the RTSPRO utility
XNCGEN External Network Configuration generator
server process files Files for various server processes (generally
start with SV)
template files XPNET template files for EMS (end with
TPLS)
protocol files Files for various protocols
SKEL files Library files for BASE24 applications
NLIB files Library files for network APIs to BASE24
applications

31
Pathway Comments
Environment
\SYS1.$DATA XNLIB DxxLIB Library file for network APIs to NET24
applications
DDL files Data definition language files for message
header, network transport layer, logical
configuration, event buffer, and event logging
utilities
XND files Files relating to NET24 defined structures
and constants
SMPL files Files pertaining to sample programs
PRO1DATA application files Data files for application 1
P1ANCJA CJ00000 First configuration journal file for P1A^NODE
CJ00000A Alternate key file for CJ00000
CJ00001 Second configuration journal file for
P1A^NODE
CJ00001A Alternate key file for CJ00001
P1ANNOMA NOM00000 First network overload management file for
P1A^NODE
NOM00001 Second network overload management file
for P1A^NODE
P1BNCJA CJ00000 First configuration journal file for P1B^NODE
CJ00000A Alternate key file for CJ00000
CJ00001 Second configuration journal file for
P1B^NODE
CJ00001A Alternate key file for CJ00001
P1BNNOMA NOM00000 First network overload management file for
P1B^NODE

32
Pathway Comments
Environment
\SYS1.$DATA PRO2DATA application files Data files for application 2
P2ANCJA CJ00000 First configuration journal file for P2A^NODE
CJ00000A Alternate key file for CJ00000
CJ00001 Second configuration journal file for
P2A^NODE
CJ00001A Alternate key file for CJ00001
P2ANNOMA NOM00000 First network overload management file for
P2A^NODE

33
Pathway Comments
Environment
SYS1.$SYSTEM SCRIBE EMSPERUS Object file for the EMSperus utility
EMSDCOM Object file for the EMSdcom utility
LOGDATER Object file for the Logdater utility
EVENTCX Event detail file used by XPNET subsystem
CXUTIL Object file used to create the EVENTCX file
RES files XPNET EMS resident template files
NRES files XPNET EMS nonresident template files
DDL files XPNET EMS data definition language files
EBU Event Buffer utilities
ELU Event Log utilities
EMSPIN Input file for EMSperus display parameters
FILT files Sample EMS filter source files
FILTCOMP Obey file to compile an EMS filter
GOEMSD Obey file to start a distributor process
GOINST TACL macro that merges the RES and NRES
files
STRTLOGD Obey file that starts the Logdater utility
TMPLIN File that indicates the location of the template
object files
TMPLMAKE Obey file that merges the template object
files
EMSPERUS Object file for the EMSperus utility
EMSDCOM Object file for the EMSdcom utility

34
Pathway Comments
Environment
SYS1.$SYSTEM SCRIBE LOGDATER Object file for the Logdater utility
EVENTCX Event detail file used by XPNET subsystem
CXUTIL Object file used to create the EVENTCX file
RES files XPNET EMS resident template files
NRES files XPNET EMS nonresident template files
DDL files XPNET EMS data definition language files
EBU Event Buffer utilities
ELU Event Log utilities
EMSPIN Input file for EMSperus display parameters
FILT files Sample EMS filter source files
FILTCOMP Obey file to compile an EMS filter
GOEMSD Obey file to start a distributor process
GOINST TACL macro that merges the RES and NRES
files
STRTLOGD Obey file that starts the Logdater utility
TMPLIN File that indicates the location of the template
object files
TMPLMAKE Obey file that merges the template object
files

35
XPMON Environment Comments
SYS1.$DATA PRODCNTL GOXMON Obey file to start XPMON
session
GOXNCXP File used to start XNCGEN
to configure XPMON
XPCONF XPMON configuration file
PURGENET Macro to purge all files
created by N24SETUP
macro
GONCP Obey file to start the
NCPCOM utility
STOPXMON Obey file that stops
XPMON server processes
NODECONF Obey file to build NODEs,
LINKs, and PROCESSEes
N1ACONF Obey file that contains
commands to create
P1A^NODE
N1BCONF Obey file that contains
commands to create
P1B^NODE
N2ACONF Obey file that contains
commands to create
P2A^NODE
EMPSLOCL Filtering commands for
EMSperus to show XPNET
events
STRTLOG Obey file to start EMSperus
utility
STOPLOG Obey file to stop EMSperus
session
L1CONF LCONF for logical network
1

36
XPMON Environment Comments
SYS1.$DATA PRODDATA N1ANEF NEF for node P1A^NODE
N1BNEF NEF for node P1B^NODE
N2ANEF NEF for node P2A^NODE
NCSP Network Control Security
Profile File
NCSS Network Control Security
Specification File
NCSS0 Alternate key file for NCSS
NMAP NMAP for all XPNET nodes
on \SYS1
NMAP0 Alternate key for NMAP
NMAP1 Alternate key for NMAP
SBAP SBA service profile security
file
SBAS SBA service user security
PRODTPLT A140101X Online maintenance file
template
NEF Network Environment File
template
SBAP SBA service profile security
file
SBAS SBA service user security

NOTE The rest of the file structure is identical to Pathway environment shown previously.

37
Pathway Comments
Environment
\SYS2.$DATA PRODCNTL GOAFT Obey file to start Pathway session
PATHCOLD Obey file to cold start PATHMON
PATHCONF Pathway configuration file
PATHCOOL Obey file to warm start PATHMON
PATHCTL Pathway control file (internal version of
PATHCONF)
PATHSTOP Obey file that stops Pathway server
processes
PATHSTRT Obey file that starts Pathway server
processes
N1ACONF Obey file that contains commands to create
P1A^NODE
SHUTDOWN Obey file to stop Pathway
STRTLOG Obey file to start EMSperus utility
STOPLOG Obey file to stop EMSperus session
GONCP Obey file to start the NCPCOM utility
PRODDATA N1ANEF NEF for node P1A^NODE
NMAP NMAP for XPNET node on \SYS2
NCSP Network Control Security Profile File
NCSS Network Control Security Specification File

38
Pathway Comments
Environment
\SYS2.$DATA XPNET NETWORK Object file for the XPNET process
NCPCOM Object file for the NCPCOM utility
NETADRD Object file for the NETADRD utility
NETDMPRD Object file for the NETDMPRD utility
NETCJRD Object file for the NETCJRD utility
NCPDFUP Obey file to create NMAP
NETDFUP Obey file to create the NEF
NEFLIST Obey file to generate a listing of the current
configuration
NETB Network link files
server process files Files for various server processes (generally
start with SV)
template files XPNET template files for EMS (end with
TPLS)
protocol files Files for various protocols
SKEL files Library files for BASE24 applications
NLIB files Library files for network APIs to BASE24
applications
XNLIB DxxLIB Library file for network APIs to NET24
applications
DDL files Data definition language files for message
header, network transport layer, logical
configuration, event buffer, and event logging
utilities
XND files Files relating to NET24 defined structures
and constants
SMPL files Files pertaining to sample programs

39
Pathway Comments
Environment
\SYS2.$DATA P1ANCJA CJ00000 Initial configuration journal file for
P1A^NODE
CJ00000A Alternate key file for CJ00000
CJ00001 Second configuration journal file for
P1A^NODE
CJ00001A Alternate key file for CJ00001
P1ANNOMA NOM00000 First network overload management file for
P1A^NODE
NOM00001 Second network overload management file
for P1A^NODE

XPNET object naming conventions

Network control commands act on objects in an XPNET system. This subsection describes the following objects:

• Nodes
• Processes
• Links
• Devices
• Stations
• Lines
• Dests

In addition, this subsection provides suggested naming conventions for the symbolic name of each object. The
symbolic name is used in commands to tell the NCPI Server process which object is to be acted on.

Symbolic names can be up to 16 alphabetic and numeric characters. The name can start with either a letter or a
number. Embedded spaces are not allowed, but the name can contain circumflex (^) and hyphen (-) characters.

All objects in an XPNET system must be uniquely identified. The fully qualified symbolic name of the XPNET node
includes the name of the HP NonStop system on which it resides. The fully qualified symbolic name of each object
managed by the XPNET process includes both the HP NonStop system name and the XPNET node name.

Standard naming conventions should be adopted for all objects in the NEF. A standard nomenclature is important in
maintaining consistency across entities throughout each XPNET system. Suggested naming conventions for each
object are discussed on the following sections. These naming conventions allow for the replication of XPNET nodes
and at the same time maintain unique symbolic names for all objects in an entire XPNET system configuration.

Although the suggested naming conventions are optional, you are encouraged to use the suggested scheme if you
do not currently have a system for naming XPNET objects. If you already have a non-ACI system and are converting
to an ACI system, you are encouraged to retain your current naming conventions to facilitate operations training. In
this latter case, ACI suggests prefixing your current names with the appropriate letter (for example, P for processes)

40
as indicated in the naming conventions.

Spaces are not allowed within the object names. The spaces shown in the naming conventions are
NOTE
included to clarify the components of the object name.

Nodes
The XPNET node is the fundamental building block of an XPNET system. It consists of an XPNET process and the
dests. links, devices, stations, lines, and application processes that it controls.

XPNET nodes can be replicated and distributed as required to support processing and operational demands. Each
XPNET node has the ability to communicate with other XPNET nodes in an XPNET system. Therefore, each XPNET
node must have a unique name within an XPNET system. If your system is distributed across two or more HP
NonStop systems, you can duplicate a particular XPNET node name on each HP NonStop system because the
XPNET node name can be fully qualified with the HP NonStop system name, thus making the XPNET node name
unique.

The XPNET process is the controlling process for the XPNET node, managing a user-configured combination of
stations, dests, lines, processes, and links to other XPNET processes. The XPNET process also manages the
messages that pass between objects in the XPNET system. There is one copy of the XPNET process for each
XPNET node in the system.

The XPNET node naming convention closely follows process naming conventions. The following is the suggested
naming convention for XPNET node names.

Format

P node-id ^ name

P — A one-character literal identifying this as a process (that is, the XPNET process).

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network in which the
XPNET node resides. The logical network identifier is assigned sequentially starting with 1 through 9, then
proceeding from A through Z. The second character identifies the XPNET node. This identifier is assigned
sequentially starting with A through Z, then proceeding from 1 through 9.

^ — A separator to divide the parts of the node name.

name — The name of the XPNET node. This name is frequently NODE (for example, P1A^NODE). Another
suggested naming convention for the XPNET node is GATE (for example, P1B^GATE), because the XPNET process
serves as a gateway to external systems and to other parts of the XPNET system.

Examples

P1A^NODE
P1B^GATE
PB^NODE

41
Processes
A process is a running version of a software program that performs specific functions. Processes access a variety of
data files for information necessary to execute the software programs. Application processes perform application-
level functions.

Process names must be unique within an XPNET node. The following is the suggested naming convention for
symbolic process names.

Format

P node-id ^ name number

P — A one-character literal identifying this as a process.

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network in which the
process resides. The logical network identifier is assigned sequentially starting with 1 through 9, then proceeding
from A through Z. The second character identifies the XPNET node. This identifier is assigned sequentially starting
with A through Z, then proceeding from 1 through 9.

^ — A separator to divide the parts of the process name.

name — The name of the process. Typically, the name is taken from the disk file name of the process, although
some application processes are identified by function rather than by disk file name.

number — The number of the process. The number uniquely identifies the process when there are multiple copies of
the process running on the same XPNET node. Numbering should start with 1.

Examples

P1A^PROC1
P1A^PROC2
PB^HOST1

Links
Links identify the other XPNET nodes with which an XPNET node can communicate. The basic function of the link is
to provide a connecting path to the XPNET process for another XPNET node. Each XPNET process establishes and
maintains its link with the other XPNET processes.

A link typically includes the identifier of the XPNET node that contains the link as well as the identifier of the XPNET
node for which it serves as a link. The following is a suggested naming convention for links.

Format

P node-id ^ name ^ P node-id

P — A one-character literal identifying this as a link between two processes.

42
node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

The first occurrence of the node identifier indicates the XPNET node that contains the link. The second occurrence
identifies the node with which this link communicates.

If your application uses the logical network concept, the first character in each occurrence identifies the logical
network. The second character in each occurrence identifies the XPNET node.

^ — A separator to divide the parts of the link name.

name — The name of the link. Typically, the name variable is the literal LINK, but can be any user-defined name.

Examples

P1A^LINK^P2B

This link name indicates that this is a link in logical network 1, XPNET node A that communicates with logical
network 2, XPNET node [Link]^LINK^PC

This link name indicates that this is a link in XPNET node A that communicates with XPNET node C.

Devices
The device definition specifies logical attributes for a generic device type (that is, type of computer or terminal). A
device definition provides protocol-specific attributes for generic types of stations within a network. The XPNET
system definition must contain a device definition for each generic station type.

In each station definition, there is a DEVICENAME attribute that references a specific device definition by the
symbolic name assigned to the device. Through the DEVICENAME attribute, the station assumes the attributes of
the referenced device. This allows the protocol-specific attributes to be specified once, although they may be used
by numerous stations.

The following is the suggested naming convention for device names.

Format

D node-id ^ name number

D — A one-character literal identifying this as a device.

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network with which the
device is associated. The logical network identifier is assigned sequentially starting with 1 through 9, then
proceeding from A through Z. The second character identifies the XPNET node. This identifier is assigned
sequentially starting with A through Z, then proceeding from 1 through 9.

^ — A separator to divide the parts of the device name.

name — The name of the device. A common way of naming devices is to include the type of terminal (for example,

43
3270 for an IBM 3270 display terminal), the protocol used to communicate with the terminal (for example, SLU or
PLU), or the type of computer to which the terminal is connected (for example, HOST or ISO^HOST).

number — The number of the device. The number can be used to uniquely identify the device when there are
multiple device definitions for the same type of terminal. Numbering should start with 1.

Examples

D1A^DIEBOLD1
D1B^HOST
DB^SLU

Stations
A station is a physical point in the XPNET system that is designated to send and receive messages. Stations are
abstractions of external, independently addressable endpoints. Remote devices and configuration units on other
platforms are stations. Both station definitions and device definitions work together to define a terminal to the XPNET
process. Each station name must be unique within an XPNET node.

Stations that are created dynamically will be automatically assigned a name. You determine the first part of the name
by setting the PREFIXDSTS attribute. The system then appends a sequential number as dynamic stations are
created.

The following is the suggested naming convention for stations.

When setting up the configuration for dynamic stations, the first letter of the PREFIX will be
NOTE
changed to "S" when adding a station and "L" when adding a line.

Format

S node-id name number

S — A one-character literal identifying this as a station.

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network with which the
station is associated. The logical network identifier is assigned sequentially starting with 1 through 9, then
proceeding from A through Z. The second character identifies the XPNET node. This identifier is assigned
sequentially starting with A through Z, then proceeding from 1 through 9.

name — The name of the station. Station names typically incorporate the type of terminal (for example, 3270 for an
IBM 3270 display terminal), or the protocol used to communicate with the terminal (for example, SLU or PLU), or the
type of computer to which the terminal is connected (for example, HOST or ISO^HOST).

number — The number of the station. The number uniquely identifies the station when there are multiple stations
that use the same name. Numbering should start with 1.

Examples

44
S1A32701
S1A32702
S2ACRT1
SBSLUP1

If you do not currently have a system for naming your terminals, you are encouraged to use the preceding scheme. If
you already have a non-ACI system and are converting to an ACI system, you are encouraged to retain your current
naming conventions to facilitate operations training. In this latter case, the following format is recommended.

Format

S user-defined

user-defined — A station name unique among all stations in the XPNET node. The user-defined portion of the
station name can be up to 15 characters in length.

Lines
The XPNET process sends messages to stations throughout the system via communications lines. Messages
transmitted via communications lines are governed by line protocols used within the industry. Protocols ensure an
orderly exchange of data from one station to another by enforcing a standard format and procedures for transmitting
data.

The following is the naming convention for line names.

Format

L node-id ^ name number

L — A one-character literal identifying this as a line.

node-id — A one- or two-character node identifier. Generally, this identifier is assigned sequentially using letters or
numbers or a combination of both letters and numbers.

If your application uses the logical network concept, the first character identifies the logical network with which the
line is associated. The logical network identifier is assigned sequentially starting with 1 through 9, then proceeding
from A through Z. The second character identifies the XPNET node. This identifier is assigned sequentially starting
with A through Z, then proceeding from 1 through 9.

^ — A separator to divide the parts of the line name.

name — The name of the line. Line names typically incorporate the type of terminal or the protocol used to
communicate on the line. Below is a list of suggested line names based on the protocol being used on the line.

Literal Protocol Name and Description

AM3270 AM3270: a polled byte synchronous protocol commonly used for communications
with ATMs or interchanges.

45
Literal Protocol Name and Description
CBIPP CSS Bisync Point-to-Point Primary: a nonpolled byte synchronous protocol
commonly used for communications with hosts, interchanges, or other HP
NonStop systems. This protocol is based on the IBM BSC protocol.

CBIPS CSS Bisync Point-to-Point Secondary: a nonpolled byte synchronous protocol

commonly used for communications with hosts, interchanges, or other HP
NonStop systems. This protocol is based on the IBM BSC protocol.

CBIS CSS Bisync Multipoint Supervisor: a polled byte synchronous protocol commonly
used for communications with ATMs or interchanges. This protocol is based on
the IBM BSC protocol.

CBIT CSS Bisync Multipoint Tributary: a polled byte synchronous protocol commonly
used for communications with hosts or interchanges. This protocol is based on
the IBM BSC protocol.

CMPSB CSS Multipoint Supervisor Burroughs: a polled synchronous or asynchronous

protocol that can be configured to emulate a number of protocols, including
Burroughs Poll/Select, ARCOmatic, NCR 279, and NCR 270-2200.

CTS Common Transport System: an architecture that provides a standard XPNET

object management interface to an external protocol handler process. Protocols
developed using this architecture have two parts. The first part, Common
Transport System Internal, is common to all implementations and is bound into
the XPNET process. The second part, Common Transport System External, is
protocol-specific and is responsible for interfacing to HP NonStop operating
system data communications components, external applications, or networks.

LU6.2 LU 6.2: a bit synchronous protocol commonly used for communications with
external systems using the SNA LU 6.2 protocol.

OSI5 OSI: a protocol that supports communications with OSI networks.

PBULK Prestel-Bulk-Update: an asynchronous protocol providing host-end support for the

Prestel Bulk Update function.

PLU PLU: a bit synchronous protocol commonly used for communications with ATMs,
hosts, or interchanges.

SDLCXF SDLC XF Multipoint Supervisor: a polled byte synchronous protocol commonly

used for communications with ATMs.

SLU SLU: a bit synchronous protocol commonly used for communications with IBM
CICS applications.

46
Literal Protocol Name and Description
TCPC TCP Client: Internal TCP/IP protocol with one Line/Station pair per Client.

TCPSC TCP Server Connection Handler: Internal TCP/IP protocol, multiple TCPSC
Lines/Stations can point to the same TCPSL Line/Station.

TCPSL TCP Server Listener: Internal TCP/IP protocol, TCPSL Line/Station will be
configured for each line defined in the TCPLISTENPORT attribute.

TR3271 TR3271: a polled byte synchronous protocol commonly used for communications
with a 3271 controller.

TTY TTY: a conversational asynchronous protocol used to communicate with local or

remote terminals.

VISA VISA: a protocol that supports communications with VISA1, VISA2, and ACISTD
point-of-sale devices. The actual protocol used is determined when a device
identifies itself in the first message it sends in a transaction sequence. Entries in
the protocol table (specified with the PROTOCOLSTRING device attribute) are
used to identify the protocol from these messages.

WGI Web Gate Interface: a protocol that is used to communicate with ICE WebGate
for various implementations including XPNET "Web Applications Services" and
custom SOAP implementations.

X.21 X.21: a protocol that supports communications with X.21 networks.

X.25 X.25: a protocol that supports communications with X.25 networks.

Line names typically incorporate the type of terminal (for example, 3270 for an IBM 3270 display terminal) or the
protocol used to communicate on the line (for example, SLU or PLU). Line names must be unique within an XPNET
node.

number — The number of the line. The number uniquely identifies the line when there are multiple lines in an XPNET
node that use the same name. Numbering should start with 1.

Examples

L1A^CBIT1
L1A^CBIT2
L2A^BSMPS01
LB^BSPPP15

47
Dests
Dest objects allow additional configuration, inquiry, and control for station, process, and service destinations within
an XPNET network. Dest object names mimic the names of station and process objects and services already
configured, or to be configured, in the XPNET network. Therefore, dest object names have the same name as the
destination they represent.

For example, if process P1A^AUTH1 is configured to provide service AUTH, then a dest object can be added with
the name AUTH on the node P1A^NODE to provide additional configuration for the AUTH service destination.

If an application process on node P1A^NODE routes messages to process P1B^HISO on node P1B^NODE, then a
dest object named P1B^HISO can be added to node P1A^NODE to provide P1A^NODE with additional information
about the P1B^HISO destination.

States and network operations

Node, line, link, process, and station object types have a set of states associated with them. The state identifies the
condition of the object. The state of an object is important to a network operator for several reasons:

• Some commands can be executed only when the object is in a specific state. For example, the line must be in a
Stopped state before you can issue the ALTER LINE command with the PORT attribute to change the logical
device name associated with the line.
• Filters enable you to limit the objects impacted by a command based on the state of the object. For example,
you could issue a START STATION * command with the ABNORMAL filter to start all stations in the Abnormal
state.
• The XPNET subsystem can generate an event message every time an object changes from one state to another
as well as when other specified activities occur. You need to understand when and why state changes occur in
order to determine which event messages require operator action.

As processing occurs in the system, objects progress from one state to another state. However, an object can only
be in one state at any given time. The following table lists the set of states for each object type.

Object Type States

Node Abnormal, Disabled, Started, Starting, Stopped, Stopping

Line Abnormal, Disabled, Started, Starting, Stopped, Stopping

Link Abnormal, Disabled, Started, Starting, Stopped

Process Abnormal, Disabled, Started, Starting, Stopped, Stopping

Station Abnormal, Disabled, Started, Starting, Stopped, Stopping, Suspended

These states are defined as follows:

48
State Description
Abnormal An object is considered to be in an Abnormal state when its current state does not
match its logical state (that is, the state indicated by the last operator action). For
example, if the last operator action indicates the object should be started, but for
some reason the object did not start or failed after starting, the object is
considered to be in an Abnormal state. Nodes, lines, links, processes, and
stations can be in an Abnormal state.

Disabled An object is considered to be in a Disabled state when it has been the subject of a
DISABLE command or has been added to the system in the Disabled state.
Nodes, processes, lines, links, and stations can be in a Disabled state.

Started An object is considered to be in a Started state when it is available for normal

processing. Nodes, lines, links, processes, and stations can be in a Started state.

Starting An object is considered to be in a Starting state when it is going through its

initialization procedures. Nodes, lines, links, processes, and stations can be in a
Starting state.

Stopped An object is considered to be in a Stopped state if it has never been started or

when the object is unavailable for normal processing as a result of operator
action. Nodes, lines, links, processes, and stations can be in a Stopped state.

Stopping An object is considered to be in a Stopping state when it is going through its

shutdown procedures. Nodes, lines, processes, and stations can be in a Stopping
state.

Suspended An object is considered to be suspended when it has been made temporarily

unavailable due to errors. Only stations can be in a Suspended state. Stations
can be suspended when the number of communication errors associated with a
station exceeds the station retry count within a line error analysis interval.
Whether a station is suspended or marked down (that is, put in an Abnormal
state) depends on the error action specified for the station.

States and object availability

Depending on the state, the XPNET process considers the object to be available (it can supply the service for which
it was designed at any level of performance) or unavailable (it cannot supply the service for which it was designed).
An object is considered to be available when it is in the Started, Stopping, or Suspended state. An object is
considered to be unavailable when it is in the Abnormal, Disabled, Starting, or Stopped state.

State transitions
The following sections provide additional information about what causes an object to move from one state to
another.

49
Node transitions

Node objects have six possible states: Abnormal, Disabled, Started, Starting, Stopped, and Stopping. The typical
progression of a node through these states is Disabled, Stopped, Starting, Started, Stopping, and Stopped. The
Abnormal state occurs only if the node fails.

The following diagram illustrates these states. The shaded areas on the diagram indicate states in which the node is
considered available.

The table indicates how a node progresses from one state to another.

50
From State To State Cause of Transition
Abnormal Starting The XPNET process was successfully created by the
NCPI Server process.

Stopped A STOP command was issued for the node.

Disabled Stopped An ENABLE command was issued for the node or the
node was added to the XPNET system in the Enabled
configuration state.

Started Abnormal The node failed.

Stopping A STOP command was issued for the node.

Starting Abnormal An error occurred during processing.

Started The XPNET node was successfully started and, in turn,

started the appropriate processes, links, and stations.

Stopping A STOP command was issued during processing.

Stopped Abnormal XPNET process creation failed.

Disabled A DISABLE command was issued for the node.

Starting The XPNET process was successfully created by the

NCPI Server process.

Stopping Abnormal An error occurred during shutdown processing.

Stopped The node completed shutdown processing.

The following commands will create the XPNET process or recreate the XPNET process after a
STOP NODE command has been executed or the XPNET process has been abnormally
terminated:

ADD ALTER CONTROL

NOTE
DELETE DELIVER DISABLE

ENABLE INFO START

51
In addition, the LISTOBJECTS command used with any filter will create or recreate the XPNET process.

Line transitions

Line objects have six possible states: Abnormal, Disabled, Started, Starting, Stopped, and Stopping. The typical
progression of a line through these states is Disabled, Stopped, Starting, Started, Stopping, and Stopped. The
Abnormal state occurs only if there are problems with the line.

The following diagram illustrates these states. The shaded areas on the diagram indicate states in which the line is
considered available.

The table indicates how a line progresses from one state to another.

52
From State To State Cause of Transition
Abnormal Starting A START command was issued for the line or for one of
its stations.

Stopped A STOP command was issued for the line or for all of its
stations.

Disabled Stopped An ENABLE command was issued for the line or the line
was added to the node in the Enabled configuration
state.

Started Abnormal The line failed.

Stopping A STOP command was issued for the line or for all of its
stations.

Starting Abnormal The line failed to start.

Started The line started successfully.

Stopped A STOP command was issued for the line or for all of its
stations.

Stopped Disabled A DISABLE command was issued for the line.

Starting A START command was issued for the line or for one of
its stations.

Stopping Stopped The line completed its shutdown processing.

Link transitions

Link objects have five possible states: Abnormal, Disabled, Started, Starting, and Stopped. The typical progression
of a link through these states is Disabled, Stopped, Starting, Started, and Stopped. The Abnormal state occurs only
if there are problems with the link.

The following diagram illustrates these states. The shaded areas on the diagram indicate states in which the link is
considered available.

53
The table indicates how a link progresses from one state to another.

From State To State Cause of Transition

Abnormal Starting A START command was issued for the link.

Stopped A STOP command was issued for the link.

Disabled Stopped An ENABLE command was issued for the link or the link
was added to the node in the Enabled configuration
state.

54
From State To State Cause of Transition
Started Abnormal The link failed.

Starting The link was closed by another XPNET node (that is, the
XPNET node with the same PPD name as this link
stopped). This transition can occur automatically when
the other XPNET node fails, or as the result of a STOP
NODE command being issued for the other XPNET
node.

Stopped A STOP command was issued for the link.

Starting Abnormal The link failed to start because the other XPNET node
(that is, the XPNET node with the same PPD name as
this link) has not yet been started.

Started The link was successfully opened by another XPNET

node (that is, the XPNET node with the same PPD name
as this link). This transition occurs automatically when a
START command is issued for the other link.

Stopped A STOP command was issued for the link.

Stopped Disabled A DISABLE command was issued for the link.

Starting A START command was issued for the link.

Process transitions

Process objects have six possible states: Abnormal, Disabled, Started, Starting, Stopped, and Stopping. The typical
progression of a process through these states is Disabled, Stopped, Starting, Started, Stopping, and Stopped. The
Abnormal state occurs only if the process fails.

The following diagram illustrates these states. The shaded areas on the diagram indicate states in which the process
is considered available.

55
The table indicates how a process progresses from one state to another.

From State To State Cause of Transition

Abnormal Starting A START command was issued for the process.

Stopped A STOP command was issued for the process.

Disabled Stopped An ENABLE command was issued for the process or the
process was added to the node in the Enabled
configuration state.

56
From State To State Cause of Transition
Started Abnormal The process failed.

Stopping A STOP command was issued for the process.

Starting Abnormal The process failed to start.

Started The process started successfully.

Stopped A STOP command was issued for the process.

Stopped Disabled A DISABLE command was issued for the process.

Starting A START command was issued for the process.

Stopping Stopped The process completed its shutdown processing.

Station transitions

Station objects have seven possible states: Abnormal, Disabled, Started, Starting, Stopped, Stopping, and
Suspended. The typical progression of a station through these states is Disabled, Stopped, Starting, Started,
Stopping, and Stopped. The Abnormal and Suspended states occur only if there are problems with the station.

The following diagram illustrates these states. The shaded areas on the diagram indicate states in which the station
is considered available.

57
The table indicates how a station progresses from one state to another.

From State To State Cause of Transition

Abnormal Starting A START command was issued for the station.

Stopped A STOP command was issued for the station.

Disabled Stopped An ENABLE command was issued for the line that the
station is associated with or the line that the station is
associated with was added to the node in the Enabled
configuration state.

58
From State To State Cause of Transition
Started Abnormal The station was marked down because of errors.

Stopping A STOP command was issued for the station.

Starting The station session failed with a retriable error and the
protocol attempts to reopen the connection. This action
is applicable to only a subset of protocols (CTS, LU6.2,
PLU, and SLU).

Suspended The station was suspended because of errors.

Starting Abnormal The station failed to start.

Started The station started successfully.

Stopped A STOP command was issued for the station.

Stopped Disabled A DISABLE command was issued for the line with which
the station is associated.

Starting A START command was issued for the station.

Stopping Stopped The station completed its shutdown processing.

Suspended Started The station was reinstated.

Stopping A STOP command was issued for the station.

59
Chapter 3. Network control facilities
The NET24-XPNET product includes two tools to control an XPNET system: The Network Control Supervisor (NCS)
screen and the Network Control Point Communications (NCPCOM) utility. The NCS screen is used in the Pathway
environment only. The NCPCOM utility is used in both the Pathway and XPMON environments. From these
interfaces, you can issue commands to the system while it is running. All XPNET system commands can be
executed from these interfaces.

You can also develop your own network management application using the management programming interface
provided by ACI. The NET24-XPNET Management Programming Manual provides information for management
application development.

Network control point communications utility

The Network Control Point Communications (NCPCOM) utility provides an interactive prompt for entering network
control commands. The NCPCOM utility is used in both the XPMON and Pathway environments. The NCPCOM
utility is started by issuing a RUN command from the TACL prompt. The general syntax of the RUN command is
shown below:

Syntax
[ RUN ] [ location ] NCPCOM [ / run-option [ , run-option ] … / ] [ param-set ]

RUN — An optional keyword for the RUN command. If the keyword RUN is included in the command, the location
variable must also be included in the command. If the keyword RUN is not included in the command, the NCPCOM
utility must be located on a volume and subvolume that is included in the PMSEARCHLIST at your site or you must
start the utility from the subvolume in which the utility is located.

location — Specifies the volume and subvolume on which the NCPCOM utility is located. This variable is required if
the location of the NCPCOM utility is not included in the PMSEARCHLIST at your site and you are starting the utility
from a location other than the subvolume in which the utility is located. If this variable is included in the command,
the keyword RUN must also be included in the command.

run-option — Specifies a valid run option for the RUN command. The most commonly used run options for the
NCPCOM utility are IN file-name and OUT list-file.

The IN file-name option specifies an input file to be processed by the NCPCOM utility. Typically, this file contains a
list of network control commands. If this option is not included in the RUN command, input is accepted from your
home terminal, and commands are processed interactively. If an input file is specified in the command, the
NCPCOM utility processes the commands in the file and stops running. The input file must include the PATH
command as the first command (unless the PATHMON or XPMON process is identified in the param-set variable). If
security is enabled, the input file must include the SET USER command as the second command.

The OUT list-file option specifies the output location for the NCPCOM utility. If this option is not included in the
command, the output is sent to the output location for the TACL process from which the NCPCOM utility was started
(typically your home terminal). If this option is included in the command, all responses are sent to the location you
specify in the list-file variable. Responses are not echoed to your terminal if you include an output location in the
command.

For more information on run options, see the HP NonStop TACL Reference Manual.

60
param-set — The PPD name assigned to the XPMON or PATHMON process. This variable identifies the XPMON or
Pathway subsystem that contains the NCP Server process. Commands entered at the NCPCOM prompt are passed
through the NCP Server process and the NCPI Server process to the XPNET process. For the XPMON
environment, if this variable is included in the command, the GATE command is not required to establish
communications with the XPMON process. For the Pathway environment, if this variable is included in the
command, the PATH command is not required to establish communications with the PATHMON process.

Command examples
ncpcom $ppmn

run $[Link]

ncpcom/in turnover, out $S.#ncpout/$ppmn

A file named NCPCCSTM is automatically processed when the NCPCOM utility is started, if the file is present on
your current subvolume. This file is an optional, user-defined obey file that can contain the GATE, PATH, SET
PROMPT, and SET USER commands (if required) as well as other network control commands, such as ASSUME
commands.

When you issue the RUN command to run the NCPCOM utility interactively, the utility starts and the NCPCOM
prompt is displayed. Commands are entered at the prompt and are executed by pressing Enter. The NCPCOM
prompt includes the default object type and a number. The number indicates the number of commands entered
during the current session. An example NCPCOM prompt is:

NODE 8

The default prompt setting is to display the assumed object type in the prompt. The example prompt indicates that
the default object type is NODE and that seven commands have been entered previously. When a command is
executed from the prompt, it is the eighth command. If an object type is not included in the prompt, a default object
type is not assumed. You can use the ASSUME command to set the default object type. The SET PROMPT
command can be used to display the assumed object type, the type and name of the assumed object, only the
name, or no additional information other than the prompt characters. For more information on using the ASSUME
command, see the NET24-XPNET Network Control Command Reference Manual.

NCPCOM utility environment

The NCPCOM utility environment is an important factor in how network control commands are processed. The
environment includes your user name (operator alias) and password, the Pathway subsystem with which the
NCPCOM utility is communicating, a default HP NonStop system name, a default XPNET node name, a default
object type, and a default object name.

The NCPCOM utility environment is established as you execute commands. The first command that must be
executed in any NCPCOM utility session is the PATH command (unless the PPD name of the XPMON or PATHMON
process was included in the RUN command). This command establishes a connection to the XPMON or Pathway
subsystem that interfaces with the XPNET process.

Additionally, you may be required to enter the SET USER command as the second command. This command is
required if security is enabled. The SET USER command logs you on as a specific user. If you do not enter the
PATH and SET USER commands at the beginning of an NCPCOM utility session, all commands fail due to no
connection to a Pathway subsystem or a security error. For information on how to enable network control security,
see Network control command security.

61
The default HP NonStop system name, XPNET node name, object type, and object name specify the objects
impacted by a command if a HP NonStop system name, an XPNET node name, object type, or object name is not
explicitly included in the command.

For example, suppose you have issued ASSUME commands to set the default HP NonStop system to \SYS1, the
default XPNET node to P1B^NODE, the default object type to PROCESS, and the default object name to
P1B^PRO*. Subsequent commands that do not specify an HP NonStop system name (as part of the object name or
in the UNDER SYSNAME filter), an XPNET node name (as part of the object name or in the UNDER NODE filter),
an object type, or an object name use the assumed values for those variables. If you entered only the keyword INFO
at the prompt, summary information would be returned for all application processes on \SYS1 managed by
P1B^NODE with names beginning with P1B^PRO.

You can display information about the NCPCOM utility environment by issuing the ENV command. For more
information on the ENV command, see the NET24-XPNET Network Control Command Reference Manual.

Using the NCPCOM utility

Any inquiry or object management command can be entered from the NCPCOM prompt. Any environment
command, other than the DELAY command, can also be entered from the NCPCOM prompt. The following sections
contain information about entering commands at the prompt and viewing the results.

Entering commands from the NCPCOM utility

Commands are entered at the NCPCOM prompt and are executed by pressing Enter. Commands can be entered
from the NCPCOM prompt in one of three ways.

One way is to enter the whole command at the prompt. For example, assume you wanted to change the queue alert
threshold for all processes in XPNET node P1A^NODE on HP NonStop system \SYS1 to 100. The command could
be entered at the NCPCOM prompt as shown below:

3 > alter process \sys1.p1a^node.*, qat 100

You could also use filters to specify the HP NonStop system and XPNET node names, as shown below:

3 > alter process *, qat 100, under node p1a^node, under sysname \sys1

The third way to enter commands is to issue ASSUME commands to specify a default HP NonStop system name,
XPNET node name, object type, and object name before issuing the command. Then only the keyword and any
additional modifiers, attributes, directives, or filters are entered at the prompt. For example, assume you wanted to
change the queue alert threshold for all processes in XPNET node P1A^NODE on HP NonStop system \SYS1 to
100. The command could be entered using the following series of commands:

4 > assume sysname \sys1

SYSNAME 5 > assume node p1a^node
NODE 6 > assume process *
PROCESS 7 > alter ,qat 100

62
One advantage to using the third method is that the assumed values are retained until they are changed. If you are
executing multiple commands against the same object type or object name, these assumed values provide a
shortcut for entering the commands.

You can abbreviate commands as long as sufficient characters exist to identify the keyword being specified. For
example, the character N, entered as an object type, identifies the NODE object type. However, LINE and LINK have
to be entered completely to identify the object type.

Certain elements require different numbers of characters in different contexts. For example, the string C identifies
the CLASS attribute in an ALTER LINK command. However, an ALTER PROCESS command requires the string CL
to identify the CLASS attribute because processes have two attributes starting with C (CLASS and CPU).

NCPCOM utility response displays

The NCPCOM utility can display up to 21 lines of response information at one time, depending on the command
issued. The response lines can be one response, as in the case of an inquiry response, or multiple responses, as
when an object management command is issued against multiple objects.

When the response information for a single command exceeds 21 lines of information, the prompt changes to
indicate that more information is available. A sample continuation prompt is shown below.

MORE>>> 4 +

The command number shown in the prompt is incremented by one. Subsequent continuation prompts for the same
command retain this command number.

You can retrieve the next screen of information by pressing Enter. For inquiry commands, Enter displays the next
screen of information, either for the current object or for the next object in the command. For commands that display
multiple screens of information for each object, the NEXTOBJ keyword can be entered at the MOREprompt to skip
to the next object.

For object management commands, Enter executes the command against the next object or objects that are to be
affected by the command. When you execute a command that impacts multiple objects, the command is not fully
executed until all responses have been displayed.

For example, assume you have issued a command that starts 30 stations. When you press Enter the first time to
execute the command, the command is executed against the first group of stations that meet the command criteria.
A response, either positive or negative, is returned for each of these stations and is displayed on the screen.
Because there are more stations that meet the command criteria, the literal “MORE ” and the character + appear in
the prompt. When you press Enter to retrieve the next screen of responses, the command is executed against the
next group of stations and the responses for those stations are displayed.

Using the example, if you did not press Enter to display the second screen of response information, no attempt
would be made to start the last group of stations impacted by the command. If you want to complete execution of a
multiple-object command, you must view all of the responses before the command is fully executed. If you do not
want to complete execution of a multiple object command, you can enter a new command at any “MORE” prompt.
Execute the new command by pressing Enter.

Most object management commands support the optional modifier QUIET. When you include the QUIET modifier in
the command, the only responses displayed are error and warning responses. Responses that indicate the
command was successful are not displayed. The main benefit of the QUIET modifier is that it does not require you to

63
view a response for each object impacted by a command to fully execute the command. Using the START STATION
command to start 30 stations as an example, if you include the QUIET modifier in the command, the command is
executed against all 30 stations at once. See the description of each object management command in the NET24-
XPNET Network Control Command Reference Manual to verify whether the QUIET modifier can be used with the
specific command.

NCPCOM utility command buffer

The NCPCOM utility maintains a buffer of the last twenty commands. The buffer contains the command only;
responses are not included. Each command you issue, regardless of the number of objects impacted or number of
screens of response information, occupies one position in the buffer. The buffer can be displayed using the
HISTORY command.

You can re-execute any command in the command buffer by entering an exclamation point (!) and the command
number at the prompt. For example, to re-execute the twentieth command entered, type “!20” at the prompt. When
you reexecute a command, the command is added to the end of the buffer as if you had entered the command
again.

You can also use the command buffer to edit a previously entered command. Commands are edited using the FC
command. Again, when you execute the edited command, the command is added to the end of the buffer as if you
had reentered the command.

For more information on the HISTORY, !, and FC commands, see the NET24-XPNET Network Control Command
Reference Manual.

Network control supervisor screen

The NCS screen provides a formatted interface for entering network control commands in the Pathway environment.
Commands are entered by filling in the fields on the screen and pressing the F1 key.

64
USER
User is the name that uniquely identifies you as an operator. Depending on how your system security is set up,
this can be the same name that you entered on the Logon screen or it can be a different name specifically for use
in executing network control commands.

Each time you issue a command from this screen, your user name and password are used to verify your access
to the command.

Field Length: 1–16 alphanumeric characters

Required Field: Yes, if security is enabled
Default Value: The user name previously entered

(nnn)
When security is enabled and the user’s password is configured to expire after a certain number of days, the
number of days until password expiration is shown in this field. If security is not enabled or the user’s password is
not configured to expire, this field is not displayed.

Field Length: System protected

PASSWORD
The password is associated with the name entered in the USER field. The NET24-XPNET product requires each
user to select a confidential password to ensure that user names are not employed by unauthorized individuals.
Each user name and password combination must be unique within the system.

As you enter each character of your password, the cursor moves one position to the right; however, as a security
precaution, the characters you enter are not displayed on the screen. The password field is case-sensitive.

65
 Each time you issue a command from this screen, your user name and password are used to verify your access
to the command.

Field Length: 1–16 alphanumeric characters

Required Field: Yes, if security is enabled
Default Value: The password previously entered.

SYSNAME
Identifies the HP NonStop system for which the entered commands are to be carried out. The asterisk (*)
indicates that the command applies to all HP NonStop systems.

If this field contains a value other than an asterisk (*) at the time a command is issued, the HP NonStop system
name entered is used in an implied UNDER SYSNAME object-name filter, where object-name is the value from
this field.

If this field contains an asterisk (*) at the time a command is issued, the command applies to all HP NonStop
systems unless a limiting filter or object name is explicitly included in the command.

Field Length: 1–7 alphanumeric characters

Required Field: Yes
Default Value: No default value

NODE
Identifies the XPNET node for which the entered commands are to be carried out. The XPNET node name is the
object name specified when the node was added to the configuration. The asterisk (*) indicates that the
command applies to all XPNET nodes.

If this field contains a value other than an asterisk (*) at the time a command is issued, the XPNET node name
entered is used in an implied UNDER NODE object-name filter, where object-name is the value from this field.

If this field contains an asterisk (*) at the time a command is issued, the command applies to all XPNET nodes
unless a limiting filter or object name is explicitly included in the command.

Field Length: 1–16 alphanumeric characters

Required Field: Yes
Default Value: *

OBJECT
Specifies the type of object affected by the command. Valid object types are as follows:

DEST
DEVICE
EXTERNAL
LINE
LINK
NODE
PROCESS
STATION

The requestor process uses the value in this field as the object-type variable in the command if an object-type
variable is not included in the COMMAND field.

66
 Field Length: 1–16 alphanumeric characters
Required Field: No
Default Value: The object type previously entered.

NAME
Identifies the specific object or objects affected by the command. This field can contain the symbolic name of the
object, as configured in the Network Environment File (NEF).

The object name can also be entered using the wildcard characters question mark (?) or asterisk (*), where a
question mark can be substituted for any single character in the object name and an asterisk can be substituted
for zero or more characters in the object name. The following are examples of using wildcard characters:

• Entering an object name value of P1A^PROC? would return objects named P1A^PROC1, P1A^PROC2, and
P1A^PROC3.
• Entering an object name value of P1A^PROC* would return objects named P1A^PROC, P1A^PROC1,
P1A^PROC2, and P1A^PROC3 as well as P1A^PROC56 and P1A^PROC100.
• Entering an object name value of asterisk (*) would return all objects of the specified type.

Multiple wild cards can be used as needed. For example, entering an object name value of S??PLU* would
return objects with names starting with S followed by any two characters, the literal PLU, and zero or more
characters. The wildcard characters can be entered at any position in the object name.

Wildcard commands require more complex processing than fully qualified commands and
are to be avoided where possible in repetitive and automated operations. For example, the
NOTE
command START STATION\PROD.P1A^NODE.S1A^1234 is processed more efficiently
than either START STATION S1A^1234 or START STATION S*^1234.

The requestor process uses the value in this field as the object-name variable in the command if an object-
name variable is not included in the COMMAND field.

NOTE This field can also contain the PPD name of an external object.

Field Length: 1–16 alphanumeric characters

Required Field: No
Default Value: The object name previously entered.

COMMAND
This is the network control command to be performed. Network control commands are entered using command
keywords and variables in a predetermined order. Network control commands are described in detail in the
NET24-XPNET Network Control Command Reference Manual.

Field Length: 1–139 alphanumeric characters

Required Field: Yes
Default Value: No default value

Function keys
The function keys used on the XNI screen are described below. Throughout XPNET manuals, references to these
function keys include only XPNET function keys. Specific keyboards may require the use of a combination of keys to

67
achieve the functionality.

The first column of information below shows the XPNET key. The second column describes the functions that can be
performed using these function keys.

Key Description
F1 ENTER DATA — Checks the data entered on the screen for errors, and enters the
data into the system.

F3 PREVIOUS PAGE — Displays the previous page of the inquiry response.

F4 NEXT PAGE — Displays the next page of the inquiry response.

F10 PRINT SCREEN — Sends the screen currently being displayed to the spooler
location indicated on the Logon screen. The Logon screen is explained in the
BASE24 CRT Access Manual.

F12 HELP SCREEN — Displays the Help screen. The Help screen displayed depends
on the screen currently being viewed. The Help screen contains information about
XPNET function keys or menu options.

F16 EXIT — This key has several purposes. It exits the Pathway system or the file
currently being accessed. It also allows you to move between logical networks
and files. For more information on how to move between logical networks and
files, refer to the BASE24 CRT Access Manual. This function key is operable on
the Help screen for files to enable the operator to change files or logical networks.

Shift-F16 LOG OFF — Logs you off this Pathway system. When this function is used while
you are accessing a screen, a blank Logon screen is displayed. If the Logon
screen is displayed when this function is used, the Logon screen continues to be
displayed or a TACL prompt is displayed, depending on how the terminal is set
up.

Using the NCS screen

The NCS screen can be used to issue a subset of environment, inquiry, and object management commands. The
NCS screen is used in the Pathway environment. The following subsections list the commands that can be executed
from the NCS screen.

Environment commands

Some environment commands apply only to the NCPCOM utility environment and are not issued from the NCS
screen. The following four environment commands can be used from the NCS screen directly or from an obey file:

• GETVERSION
• HELP

68
 • OBEY (cannot use this command in an obey file)
• SET PASSWORD

If you issue the SET PASSWORD command, you must reset the PASSWORD field on the screen
NOTE
to the new password before issuing any subsequent commands.

The following additional environment commands can be used from the NCS screen only if they are issued from an
obey file:

• ALLOW
• ASSUME
• COMMENT
• DELAY
• ENV
• LOG
• PATH
• RESET
• SET, except for the SET PASSWORD command
• SHOW
• TIME

Inquiry commands

The following inquiry commands can be executed from the NCS screen directly or from an obey file:

• INFO
• LISTOBJECTS
• STATISTICS
• STATUS

Object management commands

The following object management commands are available from the NCS screen directly or from an obey file:

• ABORT
• ALTER
• CONTROL, except for the CONTROL NODE command with the following directives:
◦ COMMIT
◦ ROLLBACK
◦ LOCK
◦ UNLOCK

69
 ◦ DELETELOCK
• DELIVER
• DISABLE
• ENABLE
• KILL
• RESETSTATS
• START
• STOP
• SWITCH
• TELL
• TRACE

The following object management commands can be used from the NCS screen only if they are issued from an obey
file:

• ADD
• DELETE

The following sections contain information about how commands are processed, entering commands on the NCS
screen, and viewing the results.

NCS equivalent of the ASSUME command

Under the NCPCOM utility, you can issue an ASSUME command that sets a default object type and object name
used in subsequent commands. The NCS screen SYSNAME, NODE, OBJECT, and NAME fields provide an
equivalent function by retaining the last value entered. To set a new default HP NonStop system name, XPNET node
name, object type, and object name, enter new information in these fields. The default HP NonStop system name,
XPNET node name, object type and object name can be overridden for an individual command by including an HP
NonStop system name, an XPNET node name, an object type, an object name, or all four in the command.

Entering commands from the NCS screen

Commands are entered by filling in the fields on the screen and pressing F1. Commands can be entered from the
NCS screen in one of two ways.

One way is to enter the whole command in the COMMAND field. In this case, no entry is required in the SYSNAME,
NODE, OBJECT, or NAME fields.

For example, assume you want to change the queue alert threshold for all processes in XPNET node P1A^NODE on
\SYS1 to 100. The command could be entered on the NCS screen as shown:

70
The second way to enter commands is to enter the object type and object name in the OBJECT and NAME field,
respectively. If one is to be used, enter the XPNET node to use as a filter in the NODE field and the HP NonStop
system to use as a filter in the SYSNAME field. The keyword and any additional modifiers, attributes, directives, or
filters are entered in the command field.

For example, assume you wanted to change the queue alert threshold for all processes in XPNET node P1A^NODE
on HP NonStop system \SYS1 to 100. Using this method, the command would be entered on the NCS screen as
shown.

71
One advantage to using the second method is that the values in the SYSNAME, NODE, OBJECT, and NAME fields
are retained until they are changed. If you are executing multiple commands against the same HP NonStop system,
XPNET node, object type, or object name, these fields provide a shortcut for entering the commands.

You can abbreviate commands as long as sufficient characters exist to identify the keyword being specified. For
example, the character N, entered as an object type, identifies an XPNET node. However, LINE and LINK have to be
entered completely to identify the object type.

Certain elements require different numbers of characters in different contexts. For example, the string C identifies
the CLASS attribute in an ALTER LINK command. However, an ALTER PROCESS command requires the string CL
to identify the CLASS attribute because processes have two attributes starting with C (CLASS and CPU).

NCS response displays

The NCS screen displays up to 15 lines of response information at one time. The 15 lines may be one response, as
in the case of a detailed inquiry response, or multiple responses, as when an object management command is
issued against multiple objects.

When the response information for a single command exceeds (or is expected to exceed) 15 lines of information, the
literal “* MORE *” appears at the end of the second line of the COMMAND field. This indicates that more response
information is available for the command. You can retrieve the next screen of information using the F4 (next page)
key.

For inquiry commands, the F5 (next object) key displays the first screen of information for the next object in the
command. F4 also displays information about the next object if the last screen of information about the previous
object is currently displayed or if each object does not require multiple screens for display.

72
For object management commands, F4 executes the command against the next object or objects that are to be
affected by the command. When you execute a command that impacts multiple objects, the command is not fully
executed until all responses have been displayed.

For example, assume you have issued a command that starts 20 stations. When you press F1 to execute the
command, the command is executed against the first 15 stations that meet the command criteria. A response, either
positive or negative, is returned for each of these stations and is displayed on the screen. Because there are more
stations that meet the command criteria, the literal “* MORE *” appears at the end of the COMMAND field. When you
press F4 to retrieve the next screen of responses, the command is executed against the next group of stations and
the responses for those stations are displayed.

Using the example, if you did not press F4 to display the second screen of response information, no attempt would
be made to start the last 5 stations to be impacted by the command. If you want to complete execution of a multiple-
object command and you are displaying all responses, you must view all of the responses before the command is
fully executed. If you do not want to complete execution of a multiple-object command, you can enter a new
command at any point. The new command is executed by pressing F1.

Most object management commands support the optional modifier QUIET. When the QUIET modifier is included in
the command, the only responses displayed are error and warning responses. Responses that indicate the
command was successful are not displayed. The main benefit of the QUIET modifier is that it does not require you to
view a response for each object impacted by a command to fully execute the command. Using the START STATION
command to start 20 stations as an example, if you include the QUIET modifier in the command, the command is
executed against all 20 stations at once. See the description of each object management command in the NET24-
XPNET Network Control Command Reference Manual to verify whether the QUIET modifier can be used with the
specific command.

NCS command buffer

The NCS facility maintains a buffer of the last ten screens of commands and responses. Each screen of responses
displayed for a multiple-object command occupies one position in the command buffer. For example, if you start 20
stations, the first screen of responses displayed is one position in the command buffer. When you display the next
screen of responses, that screen is another position in the buffer. As another example, if a detailed INFO command
was requested for 4 processes, the responses would occupy 12 positions in the command buffer, because each
INFO PROCESS command requires three screens.

The number of screens of commands and responses stored in the buffer is indicated by the page number field that
appears in the upper right-hand corner of the screen. When the NCS screen is displayed for the first time during a
session, this field reads “01 OF 01.” As commands are executed and responses are displayed, the page number is
updated. For example, when the response is displayed to the second command, the page number field reads “02 OF
02.” This continues until the page number field reads “10 OF 10,” indicating that there are ten screens of commands
and responses in the buffer.

When F3 is used to move backwards through the command buffer, the first part of the page number is updated to
indicate the position within the command buffer of the command and response being displayed. The second part of
the page number is not updated when the previous page is displayed. For example, if F3 is pressed when the page
number field reads “08 OF 08”, the field is updated to read “07 OF 08.” You can use F3 to move backwards through
the buffer as long as both parts of the page number field contain a value greater than 01.

When the second part of the page number contains a larger value than the first part, F4 can be used to move
forward through the buffer. F4 can also be used to retrieve the next screen of responses to a multiple object
command.

73
You can reexecute any command in the command buffer by displaying the screen that contains the command and
pressing F1. When the command is re-executed, the command and its response are added to the end of the buffer
as if you had entered the command again.

You can also use the command buffer to edit a previously entered command. Again, when the edited command is
executed, the command and its response are added to the end of the buffer as if you had reentered the command.

NCS screen timeouts

The NCS screen times out after a period of no activity. The amount of time before the screen times out is
application-specific and depends on the Pathway subsystem in which the NCS screen is configured. For information
on how the screen timeout works with applications, see the appropriate application-specific documentation.

You can disable the NCS timeout by entering the following command in the COMMAND field on the NCS screen:

disable terminal timeout

The command must be entered in lowercase. Pressing F12 (the Help key) executes the command. If executed
successfully, the message “TERMINAL TIMEOUT DISABLED” is displayed on the NCS screen.

After this command has been executed, the timeout is disabled for the current session. The command must be
reentered each time the operator returns to the NCS screen after accessing a different screen.

You can re-enable the timeout by entering the following in the COMMAND field on the NCS screen:

enable terminal timeout

The command must be entered in lowercase. Pressing F12 (the Help key) executes the command. If executed
successfully, the message “TERMINAL TIMEOUT ENABLED” is displayed on the NCS screen.

NOTE User security can be configured to override the terminal timeout.

Using obey files

Obey files are edit files containing a set of commands that can be executed from the Network Control Supervisor
(NCS) screen or the Network Control Point Communications (NCPCOM) utility prompt using the OBEY command.
They are created using any text editor and can contain any network control command except an OBEY command.
The obey file can also contain comments. Comments are indicated by the COMMENT command. When the NCP
Server process encounters a comment in the edit file, it ignores the comment.

The OBEY command causes commands to be processed from the specified edit file until the end of the file is
reached or an EXIT command is encountered. At that time, control is returned to the NCS screen or the NCPCOM
prompt.

74
 ACI recommends that you include the LOG command as the first command in any obey file
executed from the NCS screen. This causes all requests from the obey file and responses to
NOTE commands in the obey file to be written to the specified log file. These requests and responses are
not available to the user without the use of the LOG command in an obey file executed from the
NCS screen.

Uses for obey files

Since obey files can be executed repeatedly, they have many potential uses. Any series of related commands can
be stored in an obey file, and then the obey file can be executed as needed. This saves the operator from having to
enter the same sequence of commands more than once.

Some potential uses for obey files are:

• Bringing up a series of stations or lines

• Taking down a series of stations or lines
• Performing a series of commands required at shift turnover

In order to issue any network control command, an operator must be granted security access
through the Security File (SEC), the Network Control Security Profile File (NCSP), and the Network
NOTE
Control Security Specification File (NCSS). For information on securing network control commands,
see Network control command security.

Example obey file

The following is an example of an obey file. When this obey file is executed, the commands and their responses are
written to a file named STATUS. The network control commands are executed in the order in which they appear in
the obey file.

LOG $[Link]
ASSUME SYSNAME \SYS1
ASSUME NODE P1A^NODE
INFO
STATUS STATION *, QUEUE
STATUS PROCESS *, QUEUE
RESETSTATSPROCESSP1A^AUTH1
INFOPROCESSP1A^AUTH1, DETAIL
RESETSTATSSTATIONS1A91005
INFOSTATIONS1A91005, DETAIL
STATUS STATION *, UNDER LINE L1A^327XS10
CONTROL , GENERATE
LOG

Network control security

Operator access to network control commands can be configured when security is enabled. Command access
limitations enable you to specify for each user whether the user has access to each network control command. A
system administrator can create Network Control Security Profile records that specify the individual commands that
a user, or group of users, can execute. In the Pathway environment, these records are called NCSP, while in the

75
XPMON environment they are called XPNCSP.

Each user is then assigned a command profile in the Network Control Security Specification record. In the Pathway
environment, these records are called NCSS, while in the XPMON environment they are called XPNCSS. Another
security measure, auditing of selected or all commands, creates an audit trail of network control command activity.
Command security is the same whether commands are issued from the NCS screen or the NCPCOM utility.

The key to your security record is your user name and password. Each time you issue a command, your user name
and password are sent with the command. The user name and password are verified and then are used to
determine command access as defined in the NCSP/XPNCSP and NCSS/XPNCSS records.

When you use the NCPCOM utility, your user name and password are specified when you log on using the SET
USER command and are maintained as part of the NCPCOM utility environment. When you use the NCS screen,
this information is maintained in the USER and PASSWORD fields.

For information on enabling security and on creating Network Control Security Profile records and Network Control
Security Specification record, see Network control command security.

Open Network Control Facility (ONCF)

The XPNET Open Network Control Facility (ONCF) defines the network control interface for an XPNET system. The
components are the Network Control Point process (NCP), the Network Control Point Interface process (NCPI), and
the Network Control Point Command Interpreter utility (NCPCOM). Together they provide a command set and
interface commonly used for network control of nodes, lines, stations, processes, and devices using the HP NonStop
Command Language Standard (CLS) format.

ONCF Functional overview

The XPNET process, application processes, and HP NonStop subsystems all generate Event Management Service
(EMS) event messages that can require operator action. In addition, custom Distributed Systems Management
Applications (DSMA) can be written to provide programmatic access to XPNET network control using the NCP
Server process.

Each XPNET node logs event messages to a single collector process. The EMS distributor processes distribute
event messages to the appropriate DSMA. The distributor process and DSMA relationship can be separated among
subsystems or specific event messages using EMS filters.

The DSMAs apply user-defined rules to cause specific action to be taken by the HP NonStop operating system or
the XPNET process. SVNCS, the NCPCOM utility, and SVPNA send NCP lexical requests to the appropriate NCP
server class. SVNCP issues a network control command to the XPNET process and replies to SVNCS and the
NCPCOM utility with the appropriate response. Replies are translated into documented return codes or responses
and returned to the initiating DSMA.

If using PATHWAY, then PATHSEND is used to transport the commands and responses to and from the NCP and
NCPI Server processes. The PATHSEND facility allows an HP NonStop application program to access a monitor
server class by the server class name rather than using normal HP NonStop operating system calls.

If using XPMON, IPC (inter-process communication via OPEN and WRITEREAD) is used to transport the
commands and responses to and from the NCP and NCPI processes. The IPC facility allows an HP NonStop
application program to access a monitor process by the PPD name using normal HP NonStop operating system
calls.

76
The NCPCOM utility also provides an interface to the HP NonStop NetBatch product or similar batch scheduling
processes and allows batch processing of network control commands or obey files.

System assumptions
The NCPI Server process performs user and command security checks based on the XPNET security files. These
files provide a definition of users and, optionally, command profiles. Because the NCPI Server process is a context-
free server, all requestor processes are required to send the user ID, a system name, a node, and a password in
each request. The NCPI Server process validates each request based on this information and, optionally, on the
command and command attribute.

Interactive interfaces (that is, the NCPCOM utility and the NCS UI) require the user to enter a user ID and password.
Programmatic interfaces (that is, custom DSMAs) supply the user ID and password with the request to SVNCP;
however, these DSMA processes are secured for execution access using normal HP NonStop operating system file
security or security products like the HP NonStop Safeguard product. Additional security measures can be
implemented using security components within HP NonStop products.

Other considerations
SERVER-NCPI is designed to discover the various XPNET destinations (objects and services) instead of using the
SPROUTE file. Use NCPCOM command DELIVER NODE destination, stopusingsproute. NCPCOM
CONTROL, DEST ADD, and DESTDISCOVER commands have been developed to override the automated
discovery of object destinations.

General processing
NCPI ASSIGN routing information is supplied only during phased migration from release 2.X by the SPROUTE file
using a DELIVER NODE xxxx command, discovered automatically (message destination contains foreign symbolic
name), discovered upon command (CONTROL DESTDISCOVER), or set using a CONTROL DESTADD /
DESTDELETE command.

All commands are processed by the XPNET process and NCPI. Network control procedures in the XPNET process
handle the request and generate the appropriate response. The response can be either positive, negative, or false
positive. If the XPNET process handles the command without any external activity, the response is a positive
response. The responses from ADD, ALTER, CONTROL (with the exception of the QREAD directive), DELETE,
DELIVER, DISABLE, ENABLE, INFO, RESETSTATS, STATUS, and STATISTICS commands are positive responses
if a valid command is accepted. If a command is rejected due to an invalid state or attribute, the response is
negative.

If the command requires initiating action external to the XPNET process, the response is considered a false positive.
Generally, these commands cause an event message to be logged when the command completes. The ABORT,
START, and STOP commands, and the CONTROL command with the QREAD directive generate false positive
responses.

ONCF security
Each ONCF request must contain the following information that allows the NCPI Server process to perform security
validation:

• Node - Identifies the XPNET node for the command. This can be blanks indicating that the command is not
limited to that node.

77
 • User ID - Alias for the user as defined in the security subsystem (SEC and NCSS).
• User Info User password as defined in the NCSS.
• Command The NCP literal value for the command (NCP-CMD-START).
• Obj-Type The NCP literal value for the object type (NCP-OBJ-PROCESS)
• Attributes The ALTER attributes or CONTROL directives that are represented by variable tokens in the NCP
lexicon buffer (or in the case of NCPCOM, syntactic elements in the command string such as PPD for
PROCESS objects).

The server process performs user validation on every request. The XPNET node, user ID, and password are
validated against the NCSS file. The absence of a record or a mismatch with the supplied password does not allow
the user from accessing objects on those nodes.

The exception to this is the default record that allows the system manager to configure a single NCSS entry that
provides a common level of access to all nodes. The key value that is placed in the NCSS record for the default
record is sixteen asterisks (**** **** **** ****). If a user has an NCSS record for a specific node in the NCSS, then the
profile supplied in that record is used; failing this, the default record is checked. If neither the specific node record
nor the default record are present in the NCSS, the user is not allowed to access objects on that node.

The NCPI Server process startup parameter XN-LOCK affects the type of error reporting that is returned to the
requester in the case where the user does not have access to the node. If XN-LOCK is set to ON (the default is
FALSE), a specific node is not specified in the request, the command affects multiple objects, and the user does not
receive a security violation when attempting to access secured nodes. However, these secured nodes and their
associated objects are not visible to the user performing commands that affect multiple objects.

If the user has assumed a node or is performing commands on individual objects, a security
violation error results. One effect of this is that if XN-LOCK is enabled, the user sees the Object Not
NOTE
Found error (NCP-ERR-OBJ-NOT-FOUND) in situations where the set of affected objects are on
secured nodes.

Command-based security is performed after the message has passed user security checks. The profile ID supplied
in the NCSS record is used as the key to the NCSP file. If no record is found for the profile ID, all commands are not
allowed. If a record is found, the command, object type, and command attribute or directive (for ALTER and
CONTROL) are checked in the NCSP record for the level of access. If the access flag for the is set to the value Y,
the command is allowed. If the access flag is set to the value A, the command is allowed and the execution of the
command is audited. If the access flag is set to the value N, the command is not allowed.

NCP lexicon message format

A common lexicon structure is used for requests and replies. The static section defines common and control
information. There are two length fields in the static section. The first is the total byte count of the lexicon structure
including the length word. The second, the dynamic area length, is the total byte count of the dynamic area but does
not include the length word.

The dynamic section contains one or more occurrences of variable tokens. The variable token is a structure that is
used for both request and response data and has two length fields, the token length and the data length. The token
length is the total byte count of the variable token including the length word. One exception is the "end token" which
denotes the end of the lexicon structure. It is a one word token with a value of zero (token total length = 0). The data
length is the total byte count of the variable data area of the token but does not include the length word.

78
A request buffer contains one lexical structure for a command. Likewise, a reply buffer contains one lexical structure
for a response. A basic command/response consists of a request for a single object command followed with its reply
with a single response. However, a request can generate multiple responses within the reply when multiple objects
are referenced in the command (that is, using a wildcard in the object). In this case, a variable token is present for
each object response. The requestor controls the maximum number of responses it will accept in a reply buffer by
setting the maximum responses field of the request buffer’s lexicon structure.

The actual number of responses returned in a reply depends on the size and number of variable tokens, and the
size of the reply buffer. It may not be possible to send all responses in one reply. When this happens, it is necessary
to indicate that there are more responses to send. This is accomplished by placing nonblank data (context) in the
context field of the reply buffer’s lexicon structure. To receive the next reply, the requestor sends the same request
with the context field copied from the reply. This exchange continues until all responses have been delivered (blanks
in the context field of the reply) or until the requestor terminates the exchange (blanks in the context field of the
request).

The following diagram illustrates the structure of the lexicon message:

[structure of lexicon message]

Requests use variable tokens to pass additional information required to process the command (that is, modifiers,
filters, and additional data entered with the command). Modifier and filter tokens do not require variable data. These
tokens have a token length of 6, a specific token type, and a data length of 0. A token with variable data is used for
additional command data. For example, the ALTER and CONTROL commands always have additional command
data. The format of the variable data area is command specific and is defined with each command.

Replies use variable tokens to return response data (that is, response code and response information). A single
command can generate a response with multiple variable tokens in the reply. Each variable token is a response for a
single object. The token type is always NCP-VTY-RESP-STRUCT and the response data is contained in the variable
data portion of the token. The following diagram illustrates this response structure.

The following diagram illustrates the response structure of the lexicon message:

[Response structure]

Variable token structure

VAR-TOKEN defines the format of the variable data pieces that are placed on the end of NCP requests and
responses. This variable information includes command modifiers and filters, structured request data, and any
additional command qualifiers.

Table 1. DEFINITION VAR-TOKEN

Level Field name Field description Data type
02 VAR-TTL-LGTH The total length of the token in bytes, TYPE BINARY 16
including this length word.

79
Level Field name Field description Data type
02 VAR-TYP Specifies the type of variable data. The TYPE BINARY 16
NCP-VTY literals are the valid values for
this field. An NCP-VTY literal value is
defined for each command modifier, filter,
and configurable or dynamic attribute. You
can find these literals in the NET24-
XPNET Network Control Command
Reference.

02 VAR-DATA-LGTH The length of the token data in bytes, not TYPE BINARY 16
including this length word.

02 VAR-DATA The token data area. TYPE BINARY 16,

OCCURS 1897 TIMES

02 VAR-DATA-S The token data area defined as a series of PIC X REDEFINES VAR-
bytes. DATA, OCCURS 0 TO
3794 TIMES, DEPENDING
ON VAR-DATA-LGTH

80
Chapter 4. Aspects of network control
This section discusses a number of network control topics, including the following:

• XPNET Licensing Scheme

• Primary and backup XPNET processes
• Startup and shutdown procedures
• Changing the system time
• Message routing
• Queue management
• Auditing message traffic

The topics in this section reference several XPNET network control commands, attributes, and directives. For more
information on these commands, attributes, and directives, see the NET24-XPNET Network Control Command
Reference Manual.

XPNET licensing scheme

The XPNET licensing scheme involves the generation of a digital signature-based license issued to each customer
that XPNET reads to define the systems where it can run, which protocol modules to use, and when it expires. The
licensing scheme has the following features.

• Customers are provided a licensing certificate to place on the subvolume that holds the XPNET object. The
certificate unlocks specific protocol modules, indicates which HP NonStop nodes XPNET can run on, and has an
expiration date. The customer can view the certificate to query or verify its contents.
• The XPNET licensing scheme provides the ability to deliver all internal XPNET protocol modules to all
customers. Customers can link in as many protocols as they anticipate using, whether the protocols are
currently licensed or not. New protocols can then be licensed, or the use of existing products can be extended,
without bringing down the XPNET node.
• New license certificates can be emailed to the customer and applied while the network is running. An Open
Network Control Facility (ONCF) command is provided to check and install the new certificate. If there is a
problem with a new certificate, XPNET will not fail, but will continue to use the previous certificate.
• XPNET has been designed to log events for all foreseen licensing-related problems. The customer is notified in
advance when a license approaches expiration. If the license expires, an event is logged several times each day
to indicate that a new license must be ordered. If a new license is not in place within 180 days after the
expiration date, the XPNET node will log event 6480 and stop itself. Once this happens, a new valid license file
will need to be installed to be able to restart the node(s).

License filename and location

License files are released to customers with a filename format of LI yymmdd and are to be placed on the XPNET
subvolume where the NETWORK object file is located. The yymmdd date of the license is the date the license was
generated by ACI. The license file is an unstructured file (not an edit file) and must not be modified by the user in
any way. Modifications to the file invalidate the license. If the file is moved (for example, with FTP) from a PC to the
HP NonStop, it must be moved as a binary file (not as an ASCII text file).

81
When an XPNET node is started, it searches for the most recent LI yymmdd license file on the subvolume where the
NETWORK object is located (usually this is the XPNET subvolume). The license is read, verified, and loaded. If the
node determines that the license is not valid, one or more EMS events are logged to indicate the nature of the
licensing problem. If the license verification is successful, the node proceeds with startup and keeps the license file
open as an indication that the license file is being used by the XPNET network.

Determining the license in use

The STATUS NODE command with the DETAIL modifier denotes the current license being used by the XPNET
node. The license file name and expiration date are shown on the second screen of the detailed response.

Loading a new license

If a new license needs to be loaded into a running XPNET system, the license must first be placed on the subvolume
where the NETWORK object file for the node is located. The CONTROL NODE command,LICENSELOAD directive
can then be performed from an ONCF terminal (NCS or NCPCOM) to initiate the load sequence. Each node for
which the command was requested searches for the most recent LIyymmdd file based on the yymmdd date within
the file name.

If the new license is valid, the parameters contained in the new license go into effect and the node keeps the new
license file open. The node closes the previous license. If the new license is not valid, the previous license is
retained. If the LICENSELOAD fails, EMS events are logged giving a detailed description of the problem.

Verifying a license
A license verification utility is present on the XPNET subvolume to enable users to verify a license before loading it
into a running system. This utility has the file name LIVERIFY. LIVERIFY can be run from the XPNET subvolume
without any parameters and searches for the most recent license file just as XPNET does. When it finds the most
recent file, it opens and reads it in the same manner XPNET reads the license file. LIVERIFY gives detailed output
including the following:

• The name of the license file

• The customer for whom the license was created
• The HP NonStop systems for which the license is valid
• A list of XPNET-related product IDs for which the customer is licensed
• The expiration date of the license (including the number of days left until expiration)
• A final indication of whether the license is valid on the system where LIVERIFY is being run

In order to verify licenses which are not located on the XPNET subvolume, move to the subvolume where the license
file is located and run the LIVERIFY utility, specifying the path to the XPNET subvolume where the utility is located. If
a license file other than the most recent LIyymmdd license is to be verified, add an _ACI_LICENSE_FILE assign for
that license before running the LIVERIFY utility. The GOLIVERI license verification obey file on the XPNET
subvolume is provided to enable users to easily verify licenses with non-standard names.

Renaming the license

You can choose a different name for your XPNET license. Rather than use the default LIyymmdd file name, the
license file can be renamed to a file name of your own choosing. If this is done, then the _ACI_LICENSE_FILE

82
assign must be added to each SERVER-NCPI-nn configuration defined for each node in the Pathway configuration
file (PATHCONF) or XPMON configuration file (XPCONF) for each XPNET network configured.

On the XPNET subvolume, a GOLIVERI obey file exists in case the license file to be verified has a name other than
LIyymmdd. Edit the file and change the _ACI_LICENSE_FILE assign to the name of the license file you wish to
verify.

To install a new license in a running XPNET system in this case, rename the old license before installing the new
license on the XPNET subvolume with the same name as defined in the _ACI_LICENSE_FILE assign. When you
install the new license with the appropriate file name, you can perform the CONTROL NODE command with the
LICENSELOAD directive.

Primary and backup XPNET processes

The primary XPNET process is started in the CPU specified by the SET NODE command with the CPU attribute. The
NCPI Server process creates the XPNET process and sends it a startup message and an ADD NODE message that
contains all the SET NODE commands. The XPNET process then processes the startup message and tries to read
the data record in the NEF. Note that at the time the XPNET process is first started, the NEF has not yet been
opened. Because there is no data record for the XPNET process in the NEF, the XPNET process then processes the
ADD NODE message containing all the SET NODE commands.

The primary XPNET process attempts to create a backup process for itself at the following times:

• At initiation, if an appropriate setting has been specified for the BCPU (backup CPU) attribute
• Upon receipt of a CPU up or CPU down system message
• Whenever an ALTER NODE command with the BCPU attribute is executed that changes the CPU setting for the
backup XPNET process
• Whenever a SWITCH NODE command is executed

You can use one of two types of settings for the CPU and BCPU attributes for the node. You can either indicate a
specific CPU in the range of 0–15, or you can specify a value of -1. A value of -1 for the CPU attribute specifies that
the NCPI Server process is to use an algorithm to select the least busy CPU in which to start the XPNET process.
When a value of -1 is specified for the CPU attribute, no backup XPNET process is started regardless of the setting
for the BCPU attribute.

If you specify a value of -1 for the BCPU attribute, no backup XPNET process is started regardless of the setting for
the CPU attribute.

ACI recommends that you do not use values of -1 for the node CPU and BCPU attributes on your production
system. If you do not want a backup XPNET process, you can set the CPU and BCPU attributes to the same value.

If a backup XPNET process is running and an ALTER NODE command is issued setting the value of the BCPU
attribute equal to the configured CPU attribute, the backup XPNET process is stopped. This is the only approved
way to stop the backup XPNET process.

The SWITCH NODE command causes the backup XPNET process to take over as the primary XPNET process. If a
backup process is not running, this command is rejected.

If you need to create a backup XPNET process when no backup process is running, use the ALTER NODE command
to set the BCPU attribute to the CPU where you want the backup XPNET process to run.

83
If a CPU fails and a takeover occurs (that is, the backup XPNET process becomes the primary XPNET process), the
value of the BCPU is replaced with the value of the SBCPU (secondary backup CPU) attribute.

Shutdown and startup procedures

Occasionally, changes are made to the HP NonStop system or hardware configuration that require the XPNET
system to be shut down and restarted. When necessary, the operator must be able to perform shutdown and startup
procedures.

Shutdown procedures
To shut down the XPNET system, perform these steps:

Only authorized personnel should perform these steps. Shutting down the XPNET system results in
NOTE shutting down production. This requires careful planning and should be done only by authorized
personnel.

1. Log on to the HP NonStop operating system as the owner of the XPNET system.
2. Verify that the correct logon was used by issuing the following command from the TACL prompt:

STATUS *, USER

If the correct logon was used, all of the XPNET processes are listed. If the XPNET processes are not listed,
determine the correct logon and return to step 1.

3. Move to the control subvolume by executing the following command, where xxxx is the XPNET system name
(for example, PROD):

VOLUME $[Link]

4. From a network control facility, perform the following steps for each XPNET node:
a. Perform an orderly shutdown of communications traffic using the procedures defined for your site. Your
procedures should include issuing STOP LINE commands to stop all of your data communications stations
and lines. Your procedures can also include issuing application-specific commands to send status
information to EMS before processes and lines are stopped.
b. Verify that all stations have been stopped by entering the following command:

INFO STATION *, STARTED

This command displays any stations that are still running. If stations are still running, stop them by repeating
the previous step used to stop stations.

c. Execute a STOP NODE command twice to stop the node.

5. Exit from the network control facility. The TACL prompt is displayed.
6. Verify that all XPNET processes and their application processes have stopped by entering the following

84
 command at the TACL prompt. (XPMON or Pathway will still be running.)

STATUS *, USER

If any XPNET processes or application processes are still running, repeat steps 4 through 6 as required.

7. Shut down the environment:

a. For the Pathway environment, enter the following command at the TACL prompt: O SHUTDOWN
b. For the XPMON environment, enter the following command at the TACL prompt: O STOPXMON
8. Verify that Pathway or XPMON has shut down by executing the following command from the TACL prompt,
where $ppmn is the PPD name of the PATHMON or XPMON process:`PPD $ppmn`
9. Verify that the TACL process is the only process still running by executing the following command from the TACL
prompt:

STATUS *, USER

If only the TACL process is displayed in the status information reported, the XPNET system is shut down.

Startup procedures
XPNET node startups are governed by the startup logic specified for the node as well as the AUTO and WARM
modifiers used with the START NODE command. Node startups can occur as part of a larger system startup
procedure. Node startups can also occur in response to an operator-initiated XPNET node termination or an
abnormal XPNET node termination. Each of these startups results in different processing, as described in the
following paragraphs.

Automatic node startup logic

The automatic startup logic for the node object specifies that the NCPI Server process is to start the XPNET process
whenever the NCPI Server process is started. The XPNET process then performs an autostart of the system by
starting any application processes and links that have a startup logic of AUTOMATIC as well as all stations with an
autostart priority greater than zero. Starting the stations automatically starts the lines associated with those stations.

This startup logic automatically restarts the XPNET process after a failure. In this case, the XPNET process
performs a warmstart.

Startup logic can be specified for each node, process, and link using the#SET# or#ALTER# command with the
STARTUP attribute. Startup logic can be specified for stations using the#SET# or#ALTER# command with the
AUTOPRI attribute.

Command node startup logic

The command startup logic for the node specifies that the XPNET node is logically started only when a START
NODE command is issued.

85
 The NCPI Server process starts only the XPNET process when one of the following commands is
issued:

ADD ALTER CONTROL

NOTE
DELETE DELIVER DISABLE

ENABLE INFO START

In addition, the LISTOBJECTS command used with any filter starts the XPNET process.

The START NODE command starts any application processes and links that have a startup logic of AUTOMATIC. The
modifier AUTO or WARM can be included with the START NODE command in which case autostart or warmstart
functionality is undertaken. The AUTO or WARM modifier also starts all stations with an autostart or warmstart priority
greater than zero. Starting the stations automatically starts the lines associated with those stations.

Startup logic can be specified for each node, process, and link using the SET or ALTER command with the
STARTUP attribute. Startup logic can be specified for stations using the SET or ALTER command with the AUTOPRI
or WARMPRI attribute.

Autostarts

The START NODE command with the AUTO modifier specifies a special startup used primarily to bring up an XPNET
node after an operator-initiated termination.

During an autostart, the XPNET process starts all processes and links with a startup type of AUTOMATIC as well as
all stations with an autostart priority greater than zero. It also starts any process with a startup type of CLONE (which
is similar to AUTOMATIC except it must run in the same CPU as the XPNET primary). Starting the stations
automatically starts the lines associated with those stations.

An autostart priority can be specified for each station using the SET STATION or the ALTER STATION command
with the AUTOPRI attribute. Stations with the highest autostart priority are started first. The remaining stations are
started in descending order of priority, so that the stations with the lowest autostart priority are started last. Stations
with an autostart priority set to zero are not started.

Warmstarts

The START NODE command with the WARM modifier specifies a special startup used primarily to bring up an
XPNET node after an HP NonStop system failure or after an abnormal XPNET node termination. During a
warmstart, the XPNET process starts all stations and processes that were marked up when an abnormal termination
of the node occurred. Starting the stations automatically starts the lines associated with those stations. In addition, a
warmstart occurs automatically when the backup XPNET process takes over for the primary XPNET process and
warm backup is specified as the backup type.

During a warmstart, the XPNET process starts all stations, processes, and links that were marked up when the
abnormal termination occurred. Stations are started in order according to their warmstart priority. Stations with the
highest warmstart priority are started first. The remaining stations are started in descending order of priority, so that
the stations with the lowest warmstart priority are started last. Stations with a warmstart priority of zero are not
started.

86
A warmstart priority can be specified for each station using the SET STATION or the#ALTER STATION# command
with the WARMPRI attribute.

Startup summary

The following table summarizes the objects that are started in each of these situations.

Node Startup Logic What is Started

Automatic • XPNET process
• Application processes and links with startup logic of AUTOMATIC
• Stations with autostart priority greater than zero

Command START NODE command without a modifier

• XPNET process
• Application processes and links with startup logic of AUTOMATIC or CLONE

START NODE command with START NODE command with WARM modifier
AUTO modifier
• XPNET process
• XPNET process
• Application processes and links that were marked up when the abnormal
• Application processes and termination occurred
links with startup logic of
• Stations that were marked up when the abnormal termination occurred and
AUTOMATIC
that have a warmstart priority greater than zero
• Stations with autostart
priority greater than zero

Queue threshold

The queue threshold relates to the number of messages queued within the XPNET process. The XPNET process
calculates the number of queued messages every five seconds when attempting to start stations during an XPNET
node startup.

The XPNET process uses the queue threshold when an operator issues a START NODE command with the AUTO or
WARM modifier. The queue threshold is also used during warm backup takeovers, when the backup XPNET process
takes over as the primary XPNET process.

The queue threshold is set by the QUETHRESHOLD attribute and can range in value from 100 through
2,147,483,647. If the number of messages queued within the XPNET process reaches the level specified by the
queue threshold, the XPNET node startup is stopped for approximately 5 seconds while the XPNET process
services its queues. When the number of queued messages drops below the QUETHRESHOLD value, node startup
resumes.

ACI recommends setting the value of the QUETHRESHOLD attribute to the number of messages used in sizing the
extended memory segment. See Node definitions for information on calculating the number of extended memory
pages.

87
Starting an XPNET system

To start the XPNET system, perform the following steps.

1. Log on to the HP NonStop operating system as the owner of the XPNET system.
2. Move to the control subvolume by executing the following command, where xxxx is the XPNET system name
(for example, PROD):

VOLUME $[Link]

3. Verify that the XPNET system is not up by executing the following command at the TACL prompt:

STATUS *, USER

If the XPNET system is up, the XPNET processes and application processes are listed in the status output.

4. If necessary, start the Logdater utility by using the VOLUME command to move to the SCRIBE subvolume and
then issuing the following command at the TACL prompt.

O STRTLOGD

5. Verify that the Logdater utility is started by issuing the following command at the TACL prompt, where $logd is
the PPD name of the Logdater utility:

PPD $logd

If the Logdater utility is not running, check $0 for error messages. Correct any problems and retry step 4.

6. If required, start an EMSperus utility session to use as a log by executing the following TACL macro at the TACL
prompt:

STRTLOG

If the system is a BASE24 system, the STRTLOG file is usually an obey file. If this is the case,
enter the following command at the TACL prompt:

NOTE O STRTLOG

+ For more information about the EMSperus and Logdater utilities, see the NET24-XPNET
Event Management Manual.

7. Start the Pathway subsystem or XPMON subsystem. For the Pathway environment: Depending on the

88
 circumstances, the subsystem is brought up cold or cool.
◦ The subsystem is brought up cold after changes have been made to the configuration or to the software for
HP NonStop Pathway. To bring up the Pathway subsystem cold, enter the following command from the
TACL prompt:

PATHCOLD

◦ The subsystem is brought up cool under all other circumstances. To bring up the Pathway subsystem cool,
enter the following command from the TACL prompt:

PATHCOOL

For the XPMON environment: Execute the obey file. Enter the following command from the TACL prompt:

OBEY GOXMON

8. Verify that the PATHMON or XPMON process started by executing the following command from the TACL
prompt, where $ppmn is the PPD name of the process.

PPD $ppmn

If the process is not started, repeat steps 7 and 8. If the process is still not started, bring the subsystem up cold.

9. Verify that the appropriate server processes started by issuing the following command from the TACL prompt.

STATUS *, USER

You might see that more than just the server processes are started at this point. If the startup logic for the node
is AUTOMATIC, the NCPI Server processes start the XPNET processes, which in turn start any processes and
links that have a startup logic of AUTOMATIC as well as all stations with an autostart priority greater than zero.
Starting the stations automatically starts the lines associated with those stations.

10. Start the appropriate network control facility, either the NCS screen (Pathway environment only), or the
NCPCOM utility (both Pathway and XPMON environments).
11. If the startup logic for the node is COMMAND, only the server processes were started in step 7. In this case,
issue a#START NODE # command with the#AUTO# or#WARM# modifier for each XPNET node. The START
NODE command initiates normal system operations, which starts all processes and links with a startup logic of
automatic.
12. Start any other objects (for example, stations, lines) as necessary for your site (if the#AUTO# or#WARM#
modifier was not used).
13. Verify that the appropriate processes, links, lines, and stations required for your site are started by issuing the
following command from the network control facility.

89
 STATUS NODE *, DETAIL

This command displays status information for each node. This status information includes the number of
processes, links, lines, and stations currently in the Started state.

Changing the system time

When the local civil time changes (for example, because of daylight savings), the time change requires your system
time clocks to be changed accordingly. The XPNET process handles this time adjustment without any impacts.

Application processes could require operator intervention in order to compensate for the time change. For example,
an application process that uses offsets from the Greenwich mean time or from the time at another location might
need the offset adjusted when the local time changes. The actions required to compensate for the time change are
application specific.

Message routing
The XPNET process can route an incoming message based on any one of several methods. For messages from an
application process managed by XPNET, if the application has selected a destination for the message, that is the
destination that will be used. For incoming messages on a station, the most basic method uses the value of the
station DESTINATION attribute to route a message from the station to the specified service, process, station, or
internal destination. The DESTINATION attribute also exists for the process object to allow a default destination to
be configured for messages originating in an application process managed by XPNET. Alternatively, the XPNET
process can use destination string routing.

The XPNET process can also use Routing Profile Configuration File (RPConf) routing to determine how to route
incoming messages from a station or messages from a process. For information about using the RPConf, see the
NET24-XPNET Routing Profile Configuration Guide.

Destination string routing

Destination string routing determines the correct destination for a message based on message content. This routing
method can be used to route messages from dial-in and nondial terminals, as well as messages from application
processes.

Device object types can have an associated destination table. The destination table identifies the correct destination
for messages based on the message content. Up to 32 different destinations can be defined. Incoming transactions
are routed to the destination specified in the destination table entry if the specified message string matches the
appropriate string in the incoming message. The order of precedence for message routing is as follows:

1. Deststring
2. Route profile

Otherwise, the message is routed to the destination specified in the DESTINATION attribute for the process or
station object.

Some protocols only route messages based on the text string in each message received from the terminal. Other
protocols enable you to configure whether destination string routing is performed on every message or only on the

90
first message received during a session. In the latter case, subsequent messages received during a session are sent
to the destination established by the first message, regardless of the contents of subsequent messages. For those
protocols that are configurable, you can specify how the protocol handles destination string routing using the
DESTROUTE attribute for the device object.

The following protocols can be configured. The column labeled Default indicates how the protocol handles
destination string routing if you do not specify a value for the DESTROUTE attribute.

Protocol Default
VISA First message

X.21 ERIC No destination string routing

X.25 CompuServe POS First message

X.25 DATAPAC 3101 POS First message

X.25 DATAPAC 3201 No destination string routing

X.25 DATAPAC RAPID Every message

X.25 DSP 3270 No destination string routing

X.25 Host First message

X.25 None First message

X.25 PSS T/PAD First message

X.25 TRAN$END Every message

The following protocols route messages based on the text string in each message from the terminal:

AM3270 CSS Bisync Multipoint Supervisor

CSS Bisync Multipoint Tributary CSS Bisync Point-to-Point Primary

CSS Bisync Point-to-Point Secondary CSS Multipoint Supervisor Burroughs

Common Transport System LU 6.2

OSI PLU

91
SLU TCPC (internal TCP/IP Client)

TCPSC (Server Connection Handler) TR3271

The following protocols do not currently support destination string routing:

Prestel-Bulk-Update

TTY

To add a destination to the device destination table, you can issue the SET DEVICE or ALTER DEVICE command
with the DESTSTRING attribute and the ADD modifier. If you want to change a destination in an existing destination
table, you can use the SET DEVICE or ALTER DEVICE command with the DESTSTRING attribute and the ALTER
modifier. You can delete a destination by using the SET DEVICE or ALTER DEVICE command with the
DESTSTRING attribute and the DELETE modifier.

Service-based routing
Service-based routing provides for a message to be routed to a service provider rather than a specific object. A
service is a particular function provided by one or more objects within an XPNET system. A service provider is an
endpoint which performs that specific function. For example, an Authorization process is a service provider that
performs the specific service of authorizing a transaction.

If messages are routed to a service, they can be delivered to any provider of that service. This means that
consecutive messages from the same entry point to the same service could be delivered to different destinations. If
this is not acceptable because application processes retain context information from one message to the next,
service-based routing should not be used.

Service-based routing is configured in one of two ways: through defining object attributes or through object
registration. The attribute definition method uses an attribute named SERVICE in the process and station definitions.
Service names are user-defined. You can specify more than one service name in the SERVICE attribute by
separating each subsequent name from the previous name with a colon. Individual service names can be up to 16
characters in length. The entire value entered for the SERVICE attribute can be up to 32 characters in length,
including separators.

In the original configuration of the object, use the SET PROCESS or SET STATION command with the SERVICE
attribute. You can change the services provided by a particular object by using the ALTER PROCESS or ALTER
STATION command with the SERVICE attribute. To change an individual service name, enter the entire list of
service names. For example, if you had a process named P1A^PROC1 that was defined to provide services A and
B, and you wanted to update it to also provide service C, you would enter the following command:

ALTER PROCESS P1A^PROC1, SERVICE A:B:C

In the registration method, an application can be written to send a message to the XPNET internal destination
#REGISTER to register a service it provides. The application must send a separate registration message for each
service it provides. A single object can register an unlimited number of different services. The application can also
indicate when it no longer provides a service by sending a message to the XPNET internal destination

92
#UNREGISTER to unregister the service. For more information on registering and unregistering services, see the
NET24-XPNET Application Programming Guide.

The XPNET process adds an entry in its node destination table for each service name and keeps a list of all the
objects that provide the particular service. When links are started between two XPNET nodes, the nodes notify each
other about the available services they provide. As service providers are added or deleted, registered or
unregistered, or become available or unavailable, the XPNET nodes that are currently communicating send
notification messages to each other with these changes. The service transmit delay interval at which this occurs is
specified by the STD attribute. This effectively enables service-based message routing across all interconnected,
started XPNET nodes.

When a message is routed to a service, the XPNET process applies an algorithm to select the next available or next
best service provider to which to route the message. The message routing algorithm is summarized as follows.

Service-based routing algorithm

When the XPNET process receives a message routed to a service, the XPNET process performs the following
steps:

1. Checks its node destination table for available providers of that service on the local XPNET node. Service
providers are considered available if they are in the Started state and do not have a message queue equal to or
greater than the(SMT) service management threshold. If one or more local providers are available, the XPNET
process routes the message to the next local provider in rotation that is not busy.

If no local providers are available or all are busy, but stopped demand processes are configured as providing the
service, then one such process will be started and the message delivered. Once a demand process is started, it
becomes part of the rotation until you stop it.

If no local providers exist, the XPNET process continues with step 2.

2. Checks the node destination table for a provider of that service on a remote XPNET node on the same HP
NonStop system. If one or more remote providers exist on the same HP NonStop system, the XPNET process
routes the message to the link for the next service provider in rotation. If no remote providers exist on the same
HP NonStop system, the XPNET process continues with step 3.
3. Checks the node destination table for a provider of that service on other HP NonStop systems. If a remote
provider exists on a remote HP NonStop system, the XPNET process routes the message to the link for the next
service provider in rotation. If no remote providers exist on other HP NonStop systems, the XPNET process
continues with step 4.
4. Routes the message to an unavailable service queue and holds the message until a service provider is added,
enabled, or becomes available. If an object that provides the requested service becomes available, the XPNET
process routes the message to that service provider. If a service provider does not become available, the
message remains queued to the unavailable service queue.

Note that messages routed to a service are not seen in an unavailable service queue unless no providers for that
service are available.

Messages routed to remote XPNET nodes are distributed according to the number of service providers on those
nodes. For example, suppose two remote XPNET nodes (P1B^NODE and P2A^NODE) have service providers that
can provide the requested service. The node named P1B^NODE has one service provider and the node named
P2A^NODE has five service providers. The XPNET process sends one message to P1B^NODE and the next five to
P2A^NODE.

93
However, if the Distribute field in the message header is set to 1, the algorithm previously described is overridden
and messages are distributed to the next available service provider in rotation regardless of location. For more
information about the Distribute field, see the NET24-XPNET Application Programming Guide.

Determining the status of services and service providers

To retrieve status information about services and service providers, use the STATUS DEST command and specify
the name of the service (wild-carding service names across one or more nodes is also allowed). Various types of
response information is displayed depending on the command performed (see the Network Control Command
Reference for examples of these displays):

• The abbreviated display without the SERVICE filter displays general dest information, including the service
name, fail and frozen indicators, the number of messages queued to the service, the total number of messages
queued to providers of the service, and flags to indicate any error with the dest and whether or not a dest object
has been added for this destination. The following command shows a STATUS DEST command for the AUTH
service:

STATUS DEST AUTH

• The abbreviated display with the SERVICE filter gives a brief display of status information relevant to the
service, including the service name, fail and frozen indicators, the number of messages queued to the service,
the number of local (this node) and external (other nodes) providers that are currently available to provide the
service. The following command shows the SERVICE modifier used with the`STATUS DEST` command for the
AUTH service:

STATUS DEST AUTH, SERVICE

• The STATUS DEST command with the DETAIL modifier displays detailed status information on the screen for all
services (configured and registered) currently provided by that process. Additional information included in the
detailed response is the total number of providers, the number of usable providers and detailed status
information on each provider and each link to any node that has providers configured for the service. The
following command shows the DETAIL modifier used with the STATUS DEST command for the AUTH service:

STATUS DEST AUTH, DETAIL

The INFO PROCESS <pro name> used with the modifier DETAIL displays what services are defined for a
particular provider. However, this list is limited to configured services, or those services defined to the NEFS.
Registered or dynamic services are not shown by provider.

The UNAVAIL SERV QUEUE field on the STATUS NODE (with the DETAIL modifier) screen displays the total
number of messages queued to all unavailable services.

The BSISTATUS DEST command displays the internal BSI/SBA status information for a specified service. This
information comes from the SBA Register message sent by BSI/SBA service providers.

BSISTATUS DEST AUTH

94
Besides the STATUS DEST command with the DETAIL modifier for service destinations, the INFO PROCESS or
INFO STATION command with the UNDER SERVICE filter can be used to determine what objects provide a
particular service. The following example command can be used to determine what processes provide a service
named AUTH.

INFO PROCESS *, UNDER SERVICE AUTH

To determine what services are defined for a particular object (that is, services specified using the SERVICE
attribute), use the INFO PROCESS or INFO STATION command with the DETAIL modifier. The following is an
example of a command that displays the services defined for a process named P1A^APROC1.

INFO PROCESS P1A^APROC1, DETAIL

To determine what services have been registered in the XPNET network, use one of the following commands (with
the SERVICE filter) depending on what type of service information is desired:

STATISTICS DEST *, SERVICE

STATUS DEST *, SERVICE
INFO DEST *, SERVICE

These commands retrieve information from the network and display it on the network control terminal. Each of the
above commands can be used with the DETAIL modifier to display detailed information about each service
destination found.

The CONTROL NODE command with the DESTLOG directive can be used to log the service and service provider
information to the EMS log. The following is an example of this command:

CONTROL NODE P1A^NODE, DESTLOG * ALL

The XPNET process then generates informational event messages that list all destinations, including services,
known to the node named P1A^NODE. If the service is a BSI service, the EMS event 4052 has additional
information.

The NODEINFO attribute must be set to ON in order for informational event messages to be
NOTE
generated.

Application processes can determine the availability of providers of a particular service by sending
NOTE a message to the XPNET internal destination #NOTIFYON. For more information about this
feature, see the NET24-XPNET Application Programming Guide.

Broadcast messages
XPNET routing also provides an application process with the ability to send a broadcast message that is delivered to
all known service providers. The application process can set a bit in the message header and send a single
message to the service. The XPNET process determines that this is a broadcast message, copies the message, and

95
routes it to each appropriate destination on the local XPNET node. The local XPNET process also sends a copy of
the message to all remote XPNET nodes that contain an appropriate destination. Those XPNET nodes determine
this is a broadcast message from a link and deliver a copy of the message to all service providers on that node. The
remote XPNET nodes do not route the message to any other XPNET nodes.

If the BROADCAST field in the message header is set to 0, messages are not broadcast. If the BROADCAST field is
set to 1, a copy of the message is sent, or queued, to all appropriate known destinations, regardless of their current
state. If the BROADCAST field is set to 2, the message is sent to all appropriate destinations in the Started state.
For more information on sending broadcast messages, see the NET24-XPNET Application Programming Guide.

Destination table
The destination table is self balancing. The initial number of entries in the table is the number of local enabled
processes, plus the number of local enabled stations, plus 10,000. If the table becomes full, it grows by 50% each
time it fills (that is, 10,000 to 15,000 to 22,500 to 33,750 to 50,625, and so forth).

The destination table for an XPNET node contains the following entries:

• One entry for each enabled process and station configured on the local XPNET node.
• One entry for each configured service under local enabled processes and stations.
• One entry for each service registered by local enabled processes and stations.
• One entry for each configured and registered service that exists under enabled processes and stations on
external XPNET nodes connected by a started LINK process.
• One entry for each discovered destination.
• One entry for each unique msg.sym_source read from another XPNET node (link process). This automatically
adds the return path for messages that make a gateway hop. This avoids having to do a discover when the reply
is sent.
• One entry for each adapted (duplicate) destination. Up to 15 duplicates are allowed for a single destination.
• One entry for each external (or unknown) dest object added by an ADD DEST command which exists in the
network configuration at node startup.
• One entry for each unknown destination.
• One for each configured dest object added to the destination table using a CONTROL DEST command with the
DESTREFRESH directive.

When the location of a destination on a remote node is required, the XPNET subsystem makes attempts to discover
the destination on other nodes across one or all started links. If a dest object is added for a destination, the dest can
be configured to be found:

• Across only a single link:

◦ Set EXTDEST to YES or DETECT
◦ Set EXTLINK to the symbolic name of the desired link
◦ Set EXTCONTINGENCY to OFFDESTQ or OFFLINKQ

The XPNET process assumes the destination is present on the node across the specified link unless a
message failure to that destination (across that link) indicates otherwise.

96
 If a message sent to the destination is failed back to the originating node, the originating node marks the
destination as unknown. If EXTCONTINGENCY is set to OFFDESTQ or the link is in the started state, the
message is queued at the destination. Otherwise, messages queue at the link. When the destination once
again becomes available on the destination node, the originating node is notified and any queued messages
are routed across the link to that destination.

• Across one link as first choice and then across other started links as the second choice:
◦ Set EXTDEST to YES or DETECT
◦ Set EXTLINK to the symbolic name of the link which is the first choice
◦ Set EXTCONTINGENCY to ON

The XPNET process assumes the destination is present on the node across the specified link unless a
message failure to that destination (across that link) indicates otherwise.

If a message sent to the destination is failed back to the originating node, the originating node marks the
destination as unknown and attempts to find the destination on other available nodes across started links. If
the destination is found across another link, the destination is assigned to that link in the originating node’s
destination table.

When the destination once again becomes available on the preferred node, a CONTROL DEST <dest
name>, DESTREFRESH command can be performed on the originating node. This command reassigns the
destination to the link that connects the originating node to the preferred node. Altering the DEST ADAPT
attribute to ON can be required to complete this step.

• Across any started link (this is also the default action taken if a message is routed to a destination for which no
dest object is found):
◦ Set EXTDEST to YES
◦ Set EXTLINK to blanks
◦ Set EXTCONTINGENCY to ON

The XPNET process sends discovery requests across all allowed links in the started state in order to find the
destination. The destination is assigned to the link corresponding to the first node that responds to the
discovery request.

If a message routed to a previously discovered destination on a remote node is returned with an error stating
that the object does not exist, the XPNET process marks the destination table entry as unavailable and
sends a new discovery message to all allowed links in the started state. If a positive response is received,
the XPNET process updates the destination information and routes the message accordingly. If no positive
response is received, the XPNET process marks the destination table entry as an unknown destination and
periodically sends discovery messages to locate the destination.

To display status information about destinations or services in the destination table of a specified node, use the
STATUS DEST command (STATISTICS DEST and INFO DEST commands are also valid). Multiple display
modifiers and selection filters are allowed with these DEST commands. For a description of all DEST commands,
attributes, control directives, filters, and modifiers, see the NET24-XPNET Network Control Command Reference
Manual.

97
Adaptive routing

The XPNET process uses adaptive routing when it must distinguish between two or more objects with the same
symbolic name. This situation can occur when two or more objects with the same symbolic name are defined on
different XPNET nodes within the same XPNET system.

For example, although the fully qualified names of \SYS1.P1A^NODE.P^PROC1, \SYS1.P1B^NODE.P^PROC1, and
\SYS2.P1A^NODE.P^PROC1 are unique, they all share the same symbolic name of P^PROC1. If two or more of
these processes are enabled and started, a node that already has a destination of P^PROC1 in its destination table
can receive a message from another object with the same symbolic name.

In this example configuration, a message from \SYS1.P1B^NODE. P^PROC1 can be routed to a process named
P^PROC2 on node \SYS1.P1A^NODE. Node \SYS1.P1A^NODE already has P^PROC1 in its destination table (as
\SYS1.P1A^NODE.P^PROC1 is on that node), so the XPNET process cannot add an entry of P^PROC1 to
represent \SYS1.P1BNODE.PPROC1. In addition, if P^PROC2 sends a reply to P^PROC1 (in response to the message
just received), it would erroneously be delivered to \SYS1.P1A^NODE.P^PROC1 rather than
\SYS1.P1B^NODE.P^PROC1.

Adaptive routing enables the XPNET process to handle such situations. In the above scenario, when the message
from \SYS1.P1B^NODE.P^PROC1 is received by \SYS1.P1A^NODE and the XPNET process finds the duplicate in
the destination table, the XPNET process adapts the source object name from P^PROC1 to P^PROC1!!!!!!!, by
adding a repeated special character (an exclamation point, in this example). The XPNET process enters this
adapted name into the destination table with a record of the original symbolic name and the name of the link to
\SYS1.P1B^NODE. The XPNET process then sends the message to its destination, P^PROC2, with P^PROC1!!!!!!!
specified as the source, and generates an event message indicating the original source, the adapted name, and the
link to which the message source belongs.

If P^PROC2 sends a response message with P^PROC1!!!!!!! specified as the destination, the XPNET process looks
up the symbolic name in its destination table, recognizes it as an adapted entry, changes the destination name back
to P^PROC1, and correctly routes the response to \SYS1.P1B^NODE.

If an application process determines the destination for a response message from the message
symbolic source in the XPNET message header, adaptive routing works as described. However, if
NOTE an application process determines the response destination from other data, the response
destination is not the adapted name, adaptive routing is not invoked, and the message can be
delivered to an instance of the object other than the originator.

Up to 15 duplicates of an existing entry in a destination table can be handled by the XPNET process using the
following special characters.

Exclamation point (!) Double quotation marks (") Number sign (#)

Dollar sign ($) Percent sign (%) Ampersand (&)

Single quotation mark (') Left parenthesis ( ( ) Right parenthesis ( ) )

Asterisk (*) Plus sign (+) Comma (,)

Hyphen (-) Period (.) Forward slash (/)

98
The XPNET process uses these characters if more duplicates of the symbolic name are recognized. A message
from duplicate 16 (occurrence 17) is rejected. If a symbolic name already is 16 characters in length (the maximum
length of the destination fields in the message header and destination table), any messages from duplicates are
rejected.

Freezing a destination

The network control operator can freeze any of the four types of entries in the destination table: a destination on the
local XPNET node, a destination on a remote XPNET node, a service, or an unknown destination. In order to freeze
a destination, use the ADD DEST command to add a dest object for the destination and then use the ALTER DEST
command to modify the FREEZE attribute to ON (freeze) or OFF (thaw), as necessary. When a destination is frozen,
messages routed to the destination will continue to queue unless Network Overload Management (NOM) is invoked.
Messages with the Store-and-Forward Flag field in the message header set to 1 will queue to the frozen destination
regardless of the NOM state of that destination.

If a service is frozen, any messages currently queued to the service providers for that service continue to be
processed unless corresponding dest objects for each service provider are also individually frozen. Messages
queued to that service at the time it is frozen remain queued to the service.

To determine if any frozen destination or service provider has messages queued to it, use the STATUS DEST
command with the FROZEN and QUEUE filters. The QUEUE column shows the number of messages queued at the
destination table entry and the LINK/OBJ QUEUE column shows the number of messages queued at any associated
link, process and/or station objects (for a service, this column shows the total of the queues at all providers of that
service).

To recover queued messages from a frozen destination, use the CONTROL command with the QWRITE directive to
write the messages to a disk file. Use the CONTROL command with the QREAD directive to read the messages from
the disk file and queue the messages to another object.

For any frozen destination, queued messages can be transferred directly to the queue of another destination on the
same XPNET node by using the CONTROL command with the TRANSFER directive. To delete one or more
messages from the system, use the CONTROL command with the POP or PURGE directive. For more information
about the POP, PURGE, QREAD, QWRITE and TRANSFER directives, see the NET24-XPNET Network Control
Command Reference Manual.

Queue management
The XPNET process maintains a number of queues, including one for each of the following:

• Each process, station, and link managed by the XPNET process

• Expedited and normal log queues
• Each unknown or frozen destination
• Each unavailable service

If messages arrive faster than the process can accept them or if the process is stopped, the XPNET process queues
the messages until the process can accept them. If messages arrive faster than a station can accept them or if the
station is stopped and the Force Queue field in the message header is set on, the XPNET process queues the
messages to the station. For links, the local XPNET process queues the messages if the messages arrive faster
than the remote XPNET process can accept them.

99
The expedited log queue is used for threshold event messages. The normal log queue is used for all event
messages other than threshold event messages. The XPNET process queues these messages if they are generated
faster than the EMS Collector process can accept them.

The XPNET process queues messages to destination queues if messages cannot be routed because the destination
is frozen or is not currently in the destination table for this XPNET node and cannot be discovered. A separate
unknown destination queue exists on each XPNET node for each destination that cannot be found.

When a message is queued to an unknown destination, the XPNET process periodically sends a discovery message
to find the new destination when it is added to the configuration. The delay between discovery messages is set using
the DD attribute. When the appropriate destination is found, the XPNET process begins routing messages to that
destination. If the destination cannot be found, the messages remain queued if one or more of the specified links are
stopped or the Store-and-Forward Flag field is set in the message header, or will be failed back to the message
source if all links are started or the Unavailable Destination Flag field is set.

The XPNET process queues messages to unavailable service queues if the service or all service providers are
frozen or if messages cannot be routed to a service provider because all providers of that service are currently in an
unavailable state (that is, in a Stopped, Starting, or Abnormal state) or have messages queued beyond their service
management threshold or queue management threshold. The service and queue management thresholds are
described later in this subsection. The XPNET process automatically routes queued messages to one or more
service providers when they become available. A separate unavailable service queue exists on each XPNET node
for each service that is not available.

The NET24-XPNET product enables you to monitor and manage these message queues. This subsection describes
ways you can monitor and manage message queues and configure the initiation of network overload management
actions.

Monitoring message queues

The state of message queues can be manually monitored using the following commands:

• The STATUS NODE command with the DETAIL modifier displays the total number of messages queued for all
processes, stations, and links on the node; the number of bytes currently used for queueing; the number of
messages queued to all unknown destinations and all unavailable services; the number of messages queued to
the #DIAG-DEST internal destination; and the number of messages queued to the normal and expedited logs.
• The STATUS PROCESS command with the DETAIL modifier displays the total number of messages queued to
the process and the queueing state of the process message queue.
• The STATUS STATION command with the DETAIL modifier displays the total number of messages queued to
the station and the queueing state of the station message queue.
• The STATUS LINK command with the DETAIL modifier displays the total number of messages queued to the
link and the queueing state of the link message queue.
• The`STATUS DEST` command with the DETAIL modifier displays the total number of messages queued to the
dest entry in the destination table and the queueing state of the dest message queue. If the dest is a service,
queue counts are also shown for the number of messages queued to the destination table entry and object for
each service provider. If the dest is not a service, the queue count is shown for the associated object or link
queue.

The XPNET process can be configured to automatically monitor the state of message queues in the XPNET system
through the use of queue alert thresholds. Each time the XPNET process queues a message, it compares the
number of messages in the queue to the specified queue alert threshold. If the number of messages in the queue

100
exceeds the queue alert threshold, the XPNET process generates an event message indicating the queue exceeds
the queue alert threshold.

Queue alert threshold values can be specified for process, station, dest, and link queues; default values for unknown
destination and unavailable service queues; and for the XPNET node normal and expedited log queues. The
following attributes are used to specify these queue alert thresholds.

Attribute Queue Object Type

QAT Process, station, dest, and link queues Process, station, dest, and
link

UDQAT Unknown destination queues default Node

USQAT Unavailable service queues default Node

LOGNQAT XPNET node normal log queue Node

LOGEQAT XPNET node expedited log queue Node

The UDQAT attribute applies to each unknown destination queue on an XPNET node for which a corresponding dest
object does not exist with a QAT value greater than zero. The USQAT attribute applies to each unavailable service
queue on an XPNET node for which a corresponding dest object does not exist with a QAT value greater than zero.

When the XPNET process sends an event message indicating the queue exceeds the queue alert threshold, the
XPNET process also starts a timer. When the timer expires, the XPNET process compares the number of messages
in the queue to the appropriate queue alert threshold. If the number of messages in the queue still exceeds the
queue alert threshold, the XPNET process generates another event message and reinstates the timer. If the number
of queued messages is less than the queue alert threshold, the XPNET process generates an event message
indicating the queue no longer exceeds the queue alert threshold and does not reinstate the timer. The length of this
timer is called the queue evaluation delay and is set using the QED attribute.

ACI strongly recommends setting these attributes for all queues in an XPNET system. Adding dest objects for all
routing destinations is optional as long as the node UDQAT and USQAT values are sufficient defaults. Setting these
attributes ensures operations staff are aware of any message queues developing in the system and enables them to
take action to correct any underlying problems and prevent the queues from affecting system availability. Attribute
values should be set to a value exceeding normal queue lengths to ensure event messages relating to queueing are
not generated during normal processing conditions.

In addition to the queue alert thresholds, memory alert thresholds can be configured that specify the percentage of
XPNET process total memory that can be used before the XPNET process begins generating threshold event
messages about its memory usage. The memory alert threshold is set using the MAT attribute.

When the percentage of total memory used exceeds the memory alert threshold, the XPNET process generates an
event message and starts a timer for the number of seconds specified in the MED attribute. When the timer expires,
the XPNET process compares the percentage of its total memory used to the memory alert threshold. If the
percentage of total memory used still exceeds the memory alert threshold, another event message is sent to the
expedited log queue and the timer is reinstated. If the percentage of memory used is less than the memory alert
threshold, an event message is sent to the expedited log queue indicating that memory use no longer exceeds the
memory alert threshold. The timer is not reinstated.

101
Viewing queued messages
The NET24-XPNET product provides the ability to display queued messages back to the network control terminal in
a summary or detailed display. The#CONTROL# command with the QVIEW directive can be used to view messages
queued to the following locations.

Queue Object Type for Command

Process object Process

Station object Station

Link object Link

Unknown or frozen destination Dest

Unavailable service Dest

#DIAG-DEST internal destination Dest

The QVIEW abbreviated display can be used to quickly determine where messages are coming from and what types
of messages are queueing. If the QVIEW directive is used to display an abbreviated output of the messages queued,
the following information is displayed for each message.

• Position of the message in the queue

• Symbolic source of the message
• Byte length of the message text
• 40 bytes of ASCII text (or 20 bytes in hexadecimal) from the beginning of the message text or from a specified
text offset into the message text
• Message failure flag if nonzero

The QVIEW detailed display can be used to analyze a single message in the queue. The detailed QVIEW has the
ability to display the following information for each message.

• Position in the queue

• Transmission number of the message
• Total length, userdata length, payload length, application text length
• XPNET message header in hexidecimal with ASCII
• XPNET message userdata in hexidecimal with ASCII
• Application message
• In ASCII or in hexidecimal with ASCII
• Displayed for any length starting from any offset

For more information about the QVIEW directive, see the NET24-XPNET Network Control Command Reference

102
Manual.

Managing message queues

The NET24-XPNET product provides several methods that enable operators to manage message queues.

• Write the queued messages to a disk file

• Transfer messages from one queue to another
• Delete one or more messages from the queue

Queued messages can be recovered using the CONTROL command with the QWRITE directive to write messages
queued to a process, station, dest, or link to a disk file. The QWRITE directive enables the option to specify that all
messages in the queue or only those messages that have the Store-and-Forward Flag field set in the message
header be written to disk. The first message to be written and the total number of messages to be written to disk can
also specified. Once a qwrite file has been created, those messages can be reintroduced into the system by using
the CONTROL DEST, CONTROL LINK, CONTROL PROCESS, or CONTROL STATION command with the QREAD
directive to read the messages from the disk file and queue the messages to either the original object or an
alternative object of the same type. Additionally, messages can be requeued to their original destination(s) using the
CONTROL NODE command with the QREAD directive.

Queued messages can be transferred to a process, station, dest, or link directly to the queue of another object
destination on the same XPNET node by using the`CONTROL` command with the TRANSFER directive.

If the object with the queue is a service provider and other providers of that service are available, it is possible to
reroute the messages routed to that service to another service provider by using the CONTROL PROCESS or
CONTROL LINK command with the REROUTE directive.

One or more messages can be deleted from a dest, link, process, or station queue, using the`CONTROL` command
with the POP or PURGE directive. The PURGE directive deletes all messages from the queue. The POP directive
allows the selection of a single message or range of message to be deleted from the queue.

When multiple messages have been queued to a particular unknown destination or unavailable service, one of the
following actions is possible:

• If the destination is a valid (but not available) symbolic name, the destination can be made available by adding
the appropriate object, by enabling the object, or by starting the link to the node with the object configured.
• If the destination is an unavailable service, an object can be started that provides the service, a new service
provider can be added or enabled, or links can be started, added or enabled to nodes with service providers.
• If the destination is not valid (that is, the messages were routed to the destination in error), the operator must
resolve what caused the error. Use the CONTROL DEST command with the QVIEW directive to gain more
information about the message. If all links are started, normal processing causes non-SAF messages routed to
the unknown destination to be failed back to the source after the number of seconds configured in the node
discovery delay (DD) attribute. If one or more links are not started, messages queue at the unknown destination
either until the destination is found or all links have been started. If necessary, a dest object can be added for
this destination and the FAILURE or FREEZE flags turned on to dictate how messages routed to this destination
are to be treated.
• The CONTROL DEST command with the QWRITE, TRANSFER, POP or PURGE directive should be used to
remove the messages from any unknown destination or unavailable service queue.
• The CONTROL DEST command with the DELETE directive removes an unknown destination from the destination

103
 table after any queued messages have been removed. If a dest object has been added for the unknown
destination, it can be deleted using the DELETE DEST command.

Network overload management

Network overload management is a function of the XPNET process that safeguards against XPNET system outages
due to excessive queueing.

Queue management thresholds and queue management indexes enable you to define when the XPNET process
takes network overload management actions to manage excessive queueing. ACI recommends that the queue
management threshold and the queue management index be used in conjunction with each other, although each
can be used independently.

Queue management threshold

The queue management threshold specifies the number of messages that can be queued to an object before the
XPNET process begins network overload management actions for the queue. You can specify queue management
thresholds for process, station, dest, and link queues; default values for unknown destination and unavailable
service queues; and for the XPNET node normal and expedited log queues.

The following attributes are used to specify these queue management thresholds:

Attribute Queue Object Type

QMT Process, station, dest, and link queues Process, station, dest, and
link

UDQMT Unknown destination queues default Node

USQMT Unavailable service queues default Node

LOGNQMT XPNET node normal log queue Node

LOGEQMT XPNET node expedited log queue Node

When only the queue management threshold is configured for a queue, the XPNET process compares the number
of messages in the queue to the appropriate queue management threshold each time the XPNET process queues a
message to the object. If the number of messages in the queue exceeds the queue management threshold, the
XPNET process generates a threshold event message, sets a timer for the length of time specified as the queue
evaluation delay, and takes network overload management actions to determine whether to add messages to the
queue. See Network overload management actions for information on what network overload management actions
can be taken.

When the timer expires, the XPNET process compares the number of messages in the queue to the queue
management threshold. If the number of messages in the queue still exceeds the queue management threshold, the
XPNET process generates another event message, reinstates the timer, and continues taking network overload
management actions for that queue. If the number of queued messages is less than the queue management
threshold, the XPNET process generates an event message indicating the queue no longer exceeds the queue
management threshold, does not reinstate the timer, and ceases taking network overload management actions for

104
that queue.

Queue management index

The queue management index specifies what percentage of XPNET process total memory is to be in use before the
XPNET process begins network overload management actions for the queue. Note that the queue management
index refers to the percentage of the XPNET process total memory utilized for any purpose. This includes internal
tables and buffers as well as queued messages for all objects on the node, not just the object for which the attribute
is set.

You can specify queue management indexes for process, station, dest, and link queues; default values for unknown
destination and unavailable service queues; and for the XPNET node normal and expedited log queues. The
following attributes are used to specify these queue management indexes:

Attribute Queue Object Type

QMI Process, station, dest, and link queue Process station, dest, and
link

UDQMI Unknown destination queues default Node

USQMI Unavailable service queues default Node

LOGNQMI XPNET node normal log queue Node

LOGEQMI XPNET node expedited log queue Node

When only the queue management index is configured for a queue, the XPNET process compares the percentage of
total memory in use to the appropriate queue management index each time the XPNET process queues a message.
If the percentage of total memory in use by the XPNET process exceeds the queue management index, the XPNET
process generates a threshold event message, sets a timer for the amount of time specified as the queue evaluation
delay, and takes network overload management actions to determine whether to add messages to the queue. See
Network overload management actions for information on what network overload management actions can be taken.

When the timer expires, the XPNET process compares the percentage of total memory in use to the queue
management index. If the percentage of total memory in use by the XPNET process still exceeds the queue
management index, the XPNET process generates another event message, reinstates the timer, and continues
taking network overload management actions for that queue. If the percentage of total memory in use is less than
the queue management index, the XPNET process generates an event message indicating the percentage of
memory in use no longer exceeds the queue management index, does not reinstate the timer, and ceases taking
network overload management actions for that queue.

Using the queue management threshold and the queue management index together

When the queue management threshold and the queue management index are both configured for a particular
object or queue type, both must be exceeded for the XPNET process to take network overload management actions
on that queue.

Each time the XPNET process queues a message, it compares the number of messages in the queue to the

105
appropriate queue management threshold. If the number of messages in the queue exceeds the queue
management threshold, the XPNET process determines what percentage of its total memory is currently in use. If
the percentage of total memory in use is less than the specified queue management index, the message is left in the
queue. If the percentage of total memory in use exceeds the specified queue management index, the XPNET
process generates a threshold event message, sets a timer for the amount of time specified as the queue evaluation
delay, and takes network overload management actions to determine whether to add messages to the queue. See
Network overload management actions for information on what network overload management actions can be taken.

When the timer expires, the XPNET process compares the number of messages in the queue to the queue
management threshold and the percentage of total memory in use to the queue management index. If both
thresholds are still exceeded, the XPNET process generates another threshold event message, reinstates the timer,
and continues taking network overload management actions for that queue. If the number of messages in the queue
is less than the queue management threshold or the percentage of total memory in use falls below the queue
management index, the XPNET process generates an event message indicating the queue is no longer undergoing
network overload management, does not reinstate the timer, and ceases taking network overload management
actions for that queue.

ACI strongly recommends that the queue management threshold and queue management index be used together to
initiate network overload management actions. If the queue management threshold is used independently, it is
possible that network overload management actions will be invoked unnecessarily while ample memory space is still
available for queueing messages. If the queue management index is used independently, it is possible that network
overload management actions will be invoked unnecessarily for objects with minimal or no message queues where
messages could be processed immediately. The combination of the queue management threshold and queue
management index ensure that network overload management actions are invoked only when required due to a lack
of available memory space, and that they are invoked only against objects contributing to the memory space
shortage through message queueing.

When the queue management threshold and queue management index are used together to initiate network
overload management actions, ACI recommends that the queue management threshold be set relatively low (for
example, generally less than 20) and the queue management index be set relatively high (for example, in the range
70–90 percent). Generally, link and unavailable service queue management thresholds should be set slightly higher
than process, station, and unknown destination queue management thresholds because links and services
represent multiple endpoints. Queue management indexes for normal log queues and particularly expedited log
queues should be set higher than everything else. This ensures that messages informing operations staff of
queueing situations are output in a timely manner.

Using these recommended settings ensures that network overload management actions are invoked only when
necessary and only on objects with message queues. Large queue management threshold settings could prevent
network overload management actions being invoked on a variety of queues which together could cause memory to
be exhausted without any of the queues reaching their threshold.

Network overload management actions

When network overload management is being performed on a process, link, station, unknown destination, or
unavailable service queue, the XPNET process performs the following steps for each new message destined for that
queue.

• Checks the Network Overload Management Override field in the message header. If this field is set, the
message is added to the [Link] processes can set this field during the course of message
processing. In addition, the XPNET process sets this field if the message originates from a station that has the
NOMOVERRIDE attribute set to ON.
• Checks the Network Overload Management Return field in the message header. If this field is set, the message

106
 is returned to the source application process.
• Checks the Store-and-Forward Flag field in the message header. If this field is set in the message header and
the node NOMTODISK attribute is not set, the message is added to the queue.

If messages in the queue are currently being audited, the message is written to the audit file. If none of the above
flags are set, the XPNET process either writes the message to a named extended memory segment or discards it.

For all normal and expedited log queue messages, the XPNET process either writes the message to a named
extended memory segment or discards it, without performing the steps described.

The XPNET process checks the NOMTODISK attribute, which specifies whether the XPNET process should save
messages that would otherwise be discarded. If this attribute is set to ON, the XPNET process checks the NOMA,
NOMB, and NOMC attributes. If any one of these attributes contains a valid disk location, the message is written to a
named extended memory segment. If none of these attributes contains a valid location, the message is added to the
appropriate queue. If the NOMTODISK attribute is set to OFF, the XPNET process discards the message.

The XPNET process saves the messages in a named extended memory segment rather than writing them to disk,
thus avoiding the performance implications of disk I/O. You can specify the size of that extended memory segment
by using the SET NODE or ALTER NODE command with the NOMPAGES attribute.

Messages saved during network overload management are saved in audit file format. When the named extended
memory segment is closed, it remains on the disk as a file. The XPNET process assigns a name of NOM nnnnn,
where the variable nnnnn is a number from 00000 through 99999.

The NOMA, NOMB, and NOMC attributes specify the volume and subvolume in which to locate messages saved
during network overload management. You can specify up to three subvolumes in one or more disk volumes.
Messages are saved if the NOMTODISK attribute is set to ON and one or more of the NOMA, NOMB, or NOMC
attributes contain a valid disk location at the time the XPNET process evaluates network overload management
actions. The naming conventions for these subvolumes are described in The network overload management
subvolumes.

The XPNET process attempts to place the network overload management segment in the volume and subvolume
specified by the NOMA attribute. If this fails, the XPNET process generates an event message and attempts to place
the segment in the volume and subvolume specified by the NOMB attribute and then the NOMC attribute, if
necessary. ACI recommends naming separate disk volumes for the second and third volume locations to provide
extra disk space and to accommodate situations when one or more of the disks are not available.

If a file with the name assigned by the XPNET process already exists but does not contain data, the XPNET process
uses the existing name. If the name already exists and the file contains data, the number in the file name is
increased by one until an available file name is found. If all possible iterations of the file name in one volume and
subvolume are unsuccessful, the XPNET process attempts to go through the same file name iteration in the
remaining volumes and subvolumes. If any of the NOMA, NOMB, or NOMC attributes contains a value (and the
NOMTODISK attribute is set to ON) but all attempts to create an extended memory segment are unsuccessful, the
XPNET process continues to queue messages to their original destination.

The CONTROL NODE command with the SWNOM directive closes the current network overload management
extended memory segment and creates a new segment in the same volume and subvolume. Once the network
overload management segment is closed, you can use the NETADRD utility to analyze the messages or to create a
file in QWRITE format that can be used to reroute the messages to their original destinations. The NETADRD utility
is discussed in NETADRD and NETADRT utilities.

107
Event message content
Event messages generated by the XPNET process alert network operators to queueing situations in the network.
The expedited log queue is used for threshold event messages. Threshold event messages indicate when an object
has passed a user-established threshold, including the queue management thresholds and the queue management
indexes, which indicate when network overload management actions are initiated for a queue.

Queue alert threshold event messages include information about the threshold setting, the current number of
messages in the queue, and the maximum size of the queue. Network overload management event messages
include information about the threshold settings, the current number of messages in the queue, the current amount
of memory used, and the number of messages discarded or written to disk as a result of network overload
management.

The XPNET process updates these values when it passes the event message to EMS. If the event message spends
time in the expedited log queue before it is passed to EMS, the values in the event message can appear to be
incorrect. For example, the message indicating the queue alert threshold was exceeded can show a current queue
that is less than the queue alert threshold. Conversely, the message indicating the queue alert threshold is no longer
exceeded can show a current queue that exceeds the queue alert threshold.

This discrepancy occurs because the information in the event message reflects current values as of the time it was
passed to EMS rather than historical values at the time the event was generated. Having the most current
information should help you to determine the severity of the situation.

Auditing message traffic

The XPNET audit function allows system analysts and network operators to trace message traffic to and from the
XPNET process. An audit of message traffic has two purposes:

• Analyzing message traffic. If the system is experiencing problems, the audit can be used as a debugging tool.
• Storing critical messages. Messages can be written to disk, providing for nonvolatile storage of critical
messages. For this purpose, the audit can be used as a safeguard against the potential loss of messages.

Basically, an audit copies all messages between the XPNET process and designated processes or stations, as well
as individual messages identified by application processes, to a user-named audit file. The NETADRD utility is used
to produce various types of output from that audit file. The output can be printed or read to analyze the captured
messages. The NETADRD utility can also write selected messages from the audit file to a disk file in QWRITE
format. Messages in the QWRITE file can be read and requeued to their original destinations. The NETADRD utility
is described in NETADRD and NETADRT utilities.

The NETADRT utility is similar in functionality to the NETADRD utility. However, instead of reading the input from an
audit file, the input is sent over TCP/IP, and can be secured by TLS. This provides a more secure environment. The
NETADRT utility can still send output data to the spooler and a disk file (using the QWRITE option).The NETADRT
utility is described in Running the NETADRT utility.

An audit can cause severe degradation in system performance. This degradation can be mitigated by using external
audit or by the type of buffering action chosen for internal auditing. The ALTER NODE command with the AUDITIO
attribute specifies whether to use external audit or the type of buffering under which the internal audit operates.

108
Designating stations, processes, and specific messages to be audited
The audit function audits input and output from those stations and processes designated by the operator. You can
designate the stations and processes to be audited using network control commands. The audit function also audits
individual messages. The following table indicates the type of messages to be audited and the method used to turn
auditing on.

Type of Message Method

Input messages from a station or ALTER STATION or ALTER PROCESS command with the IAUDIT attribute
process set to ON.

Input messages from a station (as ALTER STATION command with IBAUDIT attribute set to ON.
they come in off the data
communications lines)

Output messages to a station or ALTER STATION or ALTER PROCESS command with the OAUDIT attribute
process set to ON.

Individual messages Application-modifiable bit in the message header set to ON. For more
information about the Audit Flag field, see the NET24-XPNET Application
Programming Guide.

System messages and event CONTROL NODE command with the SBIT directive set to a value of 14.
messages

All messages CONTROL NODE command with the SYSAUDIT directive set to ON.

Internal audit process and audit files

The internal audit process and external audit process handle the creation and naming of audit files in different ways.
The following information is for the internal audit process. See NET24-XPNET audit process for more information
about the two types of audit processes.

The system can hold as many as three audit files. The ALTER NODE command with the AUDITA attribute specifies
the name to be used for the A audit file. The ALTER NODE command with the AUDITB attribute specifies the name
to be used for the B audit file. The ALTER NODE command with the AUDITC attribute specifies the name to be used
for the C audit file.

Initiation and termination of an audit is controlled through the`ALTER NODE` command with the AUDIT attribute. It is
possible to initiate an audit without creating an audit file; however, at least one audit file must have been named as
either the A file or the B file. If an audit file has not been created at the time an audit is initiated, the XPNET process
creates an unstructured audit file. The ALTER NODE command with the ADEXTENT and ADMAXEXTENTS
attributes is used to specify the configuration of the audit file to be created by the XPNET process.

When an audit is started, the XPNET process automatically switches to a new audit file. This action causes the
XPNET process to begin using the A file name (or the B file name if an A file was not named) as the current audit
file. This file is the current file until any of the following events occur:

109
 • The file becomes full.
• A fatal error occurs on the file.
• A CONTROL NODE command with the SWAUDIT directive is issued.
• Auditing is stopped and restarted.
• The XPNET node is stopped and restarted.

When any of these occur, the XPNET process attempts to switch to a new audit file. Any records in the new audit file
when the XPNET process begins using the file are deleted.

When the XPNET process switches to a new audit file, the file names are rotated in the NEF so that the A file name
(or B file name if only two files are being used) always identifies the next file to be used for auditing.

If neither the A file nor the B file is accessible when an attempt is made to turn auditing on or to switch audit files, the
following occurs:

• The ALTER NODE command with the AUDIT attribute set to ON is rejected.
• The CONTROL NODE command with the SWAUDIT directive is rejected. Auditing continues using the current
audit file until the file becomes full or a fatal error occurs on the file.
• Any attempt by the XPNET process to perform an automatic switch to a new audit file fails. Auditing is turned off;
whether XPNET processing continues is based on the setting of the AUDERROR attribute. This attribute
specifies whether the XPNET process is to continue to process without auditing or whether the XPNET process
is to abend when an audit is in progress and all named audit files have unrecoverable errors.

Audit file rotation with three audit files

If three audit files are named, the XPNET process cycles through the audit files:

Audit File In NEF When Audit Starts Next Switch Subsequent Switch
Current AUDIT1 AUDIT2 AUDIT3

A AUDIT1 AUDIT2 AUDIT3 AUDIT1

B AUDIT2 AUDIT3 AUDIT1 AUDIT2

C AUDIT3 AUDIT1 AUDIT2 AUDIT3

When the audit starts, the XPNET process makes the A file (AUDIT1) the current audit file. The B file name
(AUDIT2) is moved to the A file name, identifying it as the next file to be used. The C file name (AUDIT3) is moved to
the B file name, identifying it as the file to be used second. In addition, the name of the current file (AUDIT1) is
copied to the C file name, so that it becomes the third file in the rotation.

The next time the XPNET process switches to a new audit file (Next Switch column), the XPNET process goes
through the same sequence. The A file name (AUDIT2) becomes the current file, the B file name (AUDIT3) is moved
to the A file name, the C file name (AUDIT1) is moved to the B file name, and the name of the current file (AUDIT2)
is copied to the C file name. The XPNET process continues to rotate audit file names in this manner as long as three
files are named.

110
Audit file rotation with two audit files

If two audit files are used, the XPNET process cycles through the audit files:

Audit File In NEF When Audit Starts Next Switch Subsequent Switch
Current AUDIT1 AUDIT2 AUDIT1

A AUDIT1

B AUDIT2 AUDIT2 AUDIT1 AUDIT2

C AUDIT1 AUDIT2 AUDIT1

When the audit starts, the XPNET process makes the A file (AUDIT1) the current audit file. In addition, the name of
the current file (AUDIT1) is copied to the C file name, so that it becomes the second file in the rotation.

The next time the XPNET process switches to a new audit file (Next Switch column), the XPNET process checks for
an A file name. Since there is no A file name, the B file name (AUDIT2) becomes the current file, the C file name
(AUDIT1) is moved to the B file name, and the name of the current file (AUDIT2) is copied to the C file name.

When the next subsequent switch occurs (Subsequent Switch column), the XPNET process goes through the same
sequence. Since there is no A file name, the XPNET process checks for a B file name, and makes the B file name
(AUDIT1) the current file. The C file name (AUDIT2) is moved to the B file name, and the name of the current file
(AUDIT1) is copied to the C file name. The XPNET process continues to rotate audit file names in this manner as
long as an audit is running and two files are named.

If the original two files are named using the B and C file names (instead of A and B as in the
NOTE example), the XPNET process immediately begins rotating between B and C as shown in the Next
Switch and Subsequent Switch columns.

External audit process and audit files

The internal audit process and external audit process handle the creation and naming of audit files in different ways.
The following information is for the external audit process. See NET24-XPNET audit process for more information
about the two types of audit processes.

Messages that would normally be written to AUDITA, AUDITB, or AUDITC by the XPNET internal node process are
instead sent to the external audit process via the internal #AUDIT-SERVICE dynamic service (the #AUDIT-SERVICE
and #AUDIT-CONTROL service are not propagated to other XPNET nodes so audit records will never be sent over
any LINK processes to audit services on another node).

When the audit process reads the message, it takes various actions based on the NODE configuration settings.

If EXTAUDIO is ALWAYS, the message will be written to the audit file. The external audit process will create an
indexed audit file (like how NOM files are managed in the XPNET node). The filename prefix will be AUD followed by
00000 to 99999. If there are no files on the subvol, it will start at 00000 and increase by 1 when the file fills up or a
CONTROL NODE <node>, SWAUDIT command is executed. If there are existing AUDnnnnn files on the subvol, the
audit process will determine the highest index and increase that by 1 for the next file to be allocated. So if there are

111
gaps ( due to EXTAUDRETDAYS or manually purged files ), these gaps are not used until the index reaches 99999.
This is done to attempt to keep the files in chronological order as much as possible on that subvol.

$SPAN01.P1ANAUDP
CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
AUD00000 1300 16384 04APR2017 11:15 154,111 CCCC 112 112
AUD00001 1300 16384 04APR2017 11:17 154,111 CCCC 112 112
AUD00002 1300 49152 04APR2017 11:19 154,111 CCCC 112 112
AUD00003 1300 49152 06APR2017 9:47 154,172 CCCC 112 112
AUD00004 1300 16384 07APR2017 14:12 154,172 CCCC 112 112
AUD00005 1300 16384 07APR2017 14:20 154,172 CCCC 112 112
AUD00006 1300 16384 07APR2017 14:21 154,172 CCCC 112 112
AUD00007 1300 16384 07APR2017 14:28 154,172 CCCC 112 112
AUD00008 1300 16384 09APR2017 11:26 154,172 CCCC 112 112
AUD00009 O 1300 0 10APR2017 10:15 154,172 CCCC 112 112

These files are created using the named file option with SEGMENT_ALLOCATE_ (just like NOM), so the EOF is not
updated until the file is closed and flushed to disk.

When the external audit process initializes and when the date changes, it will determine if it needs to cleanup any
stale files on the EXTAUDPRI and EXTAUDBACK volume and subvols. If EXTAUDRETDAYS = 0 or -1, then no files
will be purged and must be manually deleted. If it is greater than 0 (1 - 365) then any audit files older than this value
will automatically be purged.

If EXTAUDTCPIP is ON, the external audit process will also stream audit records on up to three TCP/IP connections
based on its PROCESS configuration in the NEF. This works in conjunction with EXTAUDIO.

SENDTIMER 10 TCPIPPRO $ZTC0

PROTOCOL TCPC AWAITTIMER 15
LOCALADDR [Link]
REMOTEPORT1 1234 REMOTEADDR1 [Link]
REMOTEPORT2 2345 REMOTEADDR2 [Link]
REMOTEPORT3 3456 REMOTEADDR3 [Link]
CONNTYPE COMMAND TCPRETRIES 0
RTSINIT IMMEDIATE

If EXTAUDTCPIP is ON and EXTAUDIO is BACKUP, audit records are only written to disk (AUDnnnnn) if there are
no established TCP/IP connections. If one or more are established, then the audit records are sent over the TCP/IP
connections (same audit record duplicated on each established connection) and not persisted to disk.

If EXTAUDTCPIP is ON and EXTAUDIO is NONE, audit records are not written to disk. If one or more are
established, then the audit records are sent over the TCP/IP connections (same audit record duplicated on each
established connection). If there are no connections, then the audit records are dropped and lost.

If NODE attributes AUDITIO = EXTERNAL, AUDIT = ON and EXTAUDDIAGDEST = ON, any messages sent to the
#DIAG-DEST queue in that XPNET node will be copied and sent to the EAUDPRO process and written into the
current audit file.

REALTIMEAUD is not supported with external auditing. If READTIMEAUD is required, the internal
NOTE audit logic must be used. The functional equivalent of REALTIMEAUD with external auditing would
be to use TCP/IP with the new NETADRT program that was added under XPNET 4.0

112
A user hook has been incorporated into the external audit process to allow a customer to examine, suppress,
tokenize, encrypt, modify and mask data in the audit record before it gets written to disk. This would be written by the
customer and linked into the EAUDPRO object.

call v_user_audit_rec ( aud^msg, old^len, new^len, suppress, user_1, user_2,

user_3 );

TThe following deliver commands can be sent to the external audit process:

CONNECTINIT
Initializes and attempts connections for every REMOTEPORT configured with a value other than zero.

CONNECTRESET
Will execute a shutdown of all connections currently in progress and will attempt to reconnect those same
sessions.

CONNECTFULL
Attempts to reconnect any previously lost connection.

RECONDELAY
This deliver command can be sent to determine the current value of the reconnection delay in seconds. This
delay is used after a connection is lost and a reconnection is attempted. The default value is 10 seconds.

RECONDELAY num
This deliver command is used if a value other than 10 seconds is desired. Accepted values are 1 - 999.

SHUTDOWN
Used to disconnect all current connections.

Examples:

deliver pro p1j^netaudp,"connectinit"

deliver pro p1j^netaudp,"recondelay 20"

The external audit process is also capable of utilizing SSL/TLS over its connections. The PROTOCOL and
CONNCONFIG attributes at the process level are used to do this. PROTOCOL should be configured as SSLC and
the CONNCONFIG attribute should specify an edit file containing params defining the SSL environment needed:

113
 param CERTFILE $[Link]
param PASSWORD password
param LICENCE_FILE $[Link]
param ROOTSFILENAME $[Link]
param CLIENTAUTH NO
param ALLOWMD5SIGNATURES NO
param SESSIONTIMEOUT 0
param SERVERMINPROTVERSION TLS12
param CLIENTMINPROTVERSION TLS12
param CLIENTHELLOPROTVERSION TLS12
param ENCRYPTTHENMACONLY NO

Audit file format

Audit files are unblocked and have the following format:

Length of record 1 Audit record 1 Length of record 2 Audit record 2 …

The record lengths are each one word and contain the byte count of the record, including the record length word.

If the audit record is streamed over TCP/IP there is also an audit header in front of the record:

definition aud-header.
02 msg-len type binary 32.
02 ver type binary 16.
02 msg-id type binary 16.
02 eye-catcher type character 16.
02 time-stamp type timestamp.
02 time-stamp-text type character 18.
02 nstp-node type character 8.
02 xpnet-node type character 16.
02 symbolic-name type character 16.
02 obj-type type binary 16.
02 ncpi-ddl-ver type character 8.
02 current-aud-file-len type binary 16.
02 current-aud-file type character 1 occurs 36 times.
02 user-1 type binary 16. !future!
02 user-2 type binary 16. !future!
end

Audit record formats

Each record in an audit file is in the standard XPNET process message format. The Internal Event Flag field in the
message header contains the audit record type. The following table shows the different types of records in the audit
file.

Type Description
0 Read complete from a station

114
Type Description
2 Write complete to a station

3 Write complete back to a source

4 Message dropped

5 System message

6 Read complete from a process

7 Write complete to a process

8 Console message

9 POPPED/PURGED message

10-19 Statistical messages

20 XPNET process generation of a text command message

90-99 User table dump records

180 Line open

181 Line close

190 Line error

191 Station error

End-of-file marks

When an audit record is added to the audit file, a value of zero is written at the end of the physical record. This value
is overwritten when the next record is added to the file. Its purpose is to signify the end of file in the case of a
complete system failure. When the audit file is closed normally, an end-of-file mark is added to the file.

115
Chapter 5. Configuring an XPNET system
Configuration of an XPNET system includes defining attributes for each XPNET node and all of its associated
processes, links, lines, stations, and devices. Dest objects can optionally be added to further configure selected
entries in the destination table for a node. All objects, including the XPNET node itself, can be added, changed, and
deleted online without stopping the XPNET system. Configuration information relating to each XPNET node is held
in the node’s Network Environment File (NEF). There is one NEF for each XPNET node in the system. Each NEF is
managed by the XPNET process in that XPNET node.

No two XPNET systems are configured exactly alike. In addition to being composed of different applications,
processes, devices, dests, and stations, there are a number of settings that depend entirely on how you want your
system to work.

This section discusses the following topics:

• Overview of configuration procedures

• Defining the NCP and NCPI Server processes
• Defining and adding objects to an XPNET system
• Guidelines for object definitions
• Making changes to the configuration
• Deleting objects from an XPNET system
• Generating a list of the current configuration
• Managing the configuration
• Managing a contingency configuration

For complete information on the syntax of the commands, attributes, and directives described in this section, see the
NET24-XPNET Network Control Command Reference Manual.

Overview of configuration procedures

The following steps are an overview of the procedures required to configure an initial version of an XPNET system
that contains multiple XPNET nodes on multiple HP NonStop systems. Steps 1 through 4 are planning steps. The
actual configuration begins in step 5. This manual describes the files and utility programs identified in steps 5
through 15, except where the step directs you to another manual for more information.

1. Select an XPNET system name. Naming conventions for XPNET system names are described in XPNET
components.
2. Determine how many HP NonStop systems are part of the XPNET system and the names of these HP NonStop
systems. The fully qualified names of XPNET objects include the HP NonStop system name.
3. If your application uses the logical network concept, determine the number of logical networks on each HP
NonStop system and the number of XPNET nodes that each logical network is to contain.
4. Determine the number of XPNET nodes required and name each XPNET node. Naming conventions for XPNET
nodes are described in XPNET components.
5. Create the configuration files in each XPNET system data subvolume:

116
 One Network Map File (NMAP) for each XPNET system on a particular HP NonStop system. You create the
NMAP using the NCPDFUP file in the XPNET subvolume. The NCPI Server process writes records to the NMAP
and the NCP Server process uses the NMAP to route network control messages.

One Network Environment File (NEF) for each XPNET node. You create the NEF as a key-sequenced file using
the NETDFUP file in the XPNET subvolume. Network control ADD and DELETE commands add and delete
records from the NEF.

6. If your application uses the logical network concept, create one Logical Network Configuration File (LCONF) on
the control subvolume for each logical network in the system. For information on the LCONF for BASE24
applications, see the BASE24 Logical Network Configuration File Manual. For information on the LCONF for
other applications, see the application-specific documentation.
7. Set up the environment configuration files on the control subvolume, either Pathway or XPMON. Defining the
NCP and NCPI Server processes is described in the next subsection. Examples of the Pathway and XPMON
files are in Examples of XPNET obey files.
8. Set up the application data files in the application data subvolumes for each XPNET node or logical network. For
more information on setting up the application data files, see your application-specific documentation.
9. Start the Pathway or XPMON subsystem.
10. Start the NCPCOM utility. This utility is described in Network control facilities.
11. Use SET NODE commands to define the node parameters for the first XPNET node you want to configure.
Using SET commands is described later in this section.
12. Use the ADD NODE command to add the XPNET node to the configuration. Using ADD commands is described
later in this section.
13. Use the SET and ADD commands to define and add other objects to the configuration for this XPNET node.
14. Issue a START NODE command to start the XPNET node you just configured. This command starts the XPNET
process and any application processes and links that have a startup logic of AUTOMATIC.
15. Issue START commands for any other objects in this XPNET node that you want to start at this time.
16. Repeat step 11 through step 15 for any other XPNET nodes that you want to configure at this time.

You can accomplish steps 11, 12, and 13 by using an edit file that contains the commands required
to configure the objects on a particular node. The suggested naming convention for this edit file is
NOTE NxxCONF, where xx is the node ID. This node ID is a one- or two-character node identifier that is
generally assigned sequentially using letters or numbers or a combination of both letters and
numbers.

This file can be used to document the initial configuration of a node. As changes are made to the configuration, a
replacement NxxCONF file can be generated to reflect the current configuration. See Generating a command file for
the current configuration.

Defining the NCP and NCPI server processes

This subsection describes the server assigns and params for the NCP and NCPI Server processes that are defined
in the Pathway Configuration File (PATHCONF) or XPMON Configuration File (XPCONF). Only the assigns and
params specific to the NET24-XPNET product are included. Examples of PATHCONF and XPCONF are illustrated in
Examples of XPNET obey files.

117
NCP server process
The following assigns and params are specific to the XPNET NCP Server process. For information about the HP
NonStop server assigns and params, see the HP NonStop NonStop TS/MP System Management Manual.

SET SERVER ASSIGN ALT-EVT

The fully qualified name of the alternate EMS collector process to which the NCP Server process is to write event
messages if the primary collector process becomes unavailable. Valid values are $0 or the PPD name of an
alternate collector process.

Example: \SYS1.$0
Required Assign: No
Default Value: No default value

SET SERVER ASSIGN NMAP

The fully qualified file name of the Network Map File (NMAP) for the XPNET system on this HP NonStop system.
If an XPNET system spans two or more HP NonStop systems, an NMAP must be located on each HP NonStop
system.

Example: \SYS1.$[Link]
Required Assign: Yes
Default Value: No default value

SET SERVER ASSIGN PMON

xx
The fully qualified PPD name of the PATHMON process (Pathway environment only) on another HP NonStop
system. This assign is used to locate the NCP Server process on a remote HP NonStop system that can be used
to send commands to XPNET nodes on that remote system. One instance of this assign is required for each HP
NonStop system that contains an NCP Server process with which this NCP Server process is to communicate.
The variable xx in the server attribute name specifies the instance of this assign. Numbering should start at 01.

Example: \SYS2.$PPMN
Required Assign: Yes
Default Value: No default value

SET SERVER ASSIGN XMON

xx
The fully qualified PPD name of the XPMON process (XPMON environment only) on another HP NonStop
system. This assign is used to locate the NCP Server process on a remote HP NonStop system that can be used
to send commands to XPNET nodes on that remote system. One instance of this assign is required for each HP
NonStop system that contains an NCP Server process with which this NCP Server process is to communicate.
The variable xx in the server attribute name specifies the instance of this assign. Numbering should start at 01.

Example: \SYS2.$XPMN
Required Assign: Yes
Default Value: No default value

SET SERVER ASSIGN PRI-EVT

The fully qualified name of the primary EMS collector process to which the NCP Server process is to write event
messages. Valid values are $0 or the PPD name of an alternate collector process.

118
 Example: \SYS1.$0
Required Assign: Yes
Default Value: No default value

SET SERVER PARAM ALT-TIM-LMT

Specifies the amount of time, in ticks, that the NCP Server process waits for a write to the alternate EMS
collector process to complete. The range of valid values is 0–2,147,482,647. A value of 0 disables the timer.

Required Param: No
Default Value: 500 ticks (5 seconds)

SET SERVER PARAM PRI-TIM-LMT

Specifies the amount of time, in ticks, that the NCP Server process waits for a write to the primary EMS collector
process to complete. The range of valid values is 0–2,147,482,647. A value of 0 disables the timer.

Required Param: No
Default Value: 500 ticks (5 seconds)

SET SERVER PARAM REFR-ERR-TIMEOUT

Specifies the interval, in ticks, at which the NCP Server process deletes the location of an object from the table in
its memory. The NCP Server process sends a message to discover the location of that object only when a
command referencing that object is received. This table is also used to determine which objects meet wildcard
criteria when wildcard characters have been used in the object name parameter of a network control command.

The value of this parameter is used when an error occurred on the previous discovery message. The range of
valid values is 0–2,147,482,647. A value of 0 disables the timer.

Required Param: No
Default value: 500 ticks (5 seconds)

SET SERVER PARAM REFR-TIMEOUT

Specifies the interval, in ticks, at which the NCP Server process deletes the location of an object from the table in
its memory. The NCP Server process sends a message to discover the location of that object only when a
command referencing that object is received. This table is also used to determine which objects meet wildcard
criteria when wildcard characters have been used in the object name parameter of a network control command.

During periods when the configuration is undergoing many changes (that is, objects are being added to or
deleted from the system), this parameter should be set relatively low. During periods when the configuration is
stable, the value should be set higher. The range of valid values is 0–2,147,482,647. A value of 0 disables the
timer.

Required Param: No
Default Value: 3000 ticks (30 seconds)

SET SERVER PARAM RQST-TIMEOUT

Specifies the amount of time, in ticks, the NCP Server process waits for a response before it sends a request-
timed-out message. The range of valid values is 0–2,147,482,647. A value of 0 disables the timer. This can be
overridden by the requester process.

Required Param: No
Default Value: 30000 ticks (5 minutes)

119
SET SERVER PARAM SERVERCLASS
The name of the server class for the NCP Server process. All NCP Server processes in an XPNET system must
have the same server class name.

Required Param: No
Default Value: SERVER-NCP

SET SERVER PARAM SINTERVAL

Specifies the interval, in ticks, at which NCP Server process statistics are automatically generated. The range of
valid values is 0–2,147,482,647. A value of 0 disables the timer.

Required Param: No
Default Value: 30000 ticks (5 minutes)

SET SERVER PARAM TN-TIMEOUT

Specifies the amount of time, in ticks, the NCP Server process waits for a response when it sends a network
control command to another member of the same server class. The range of valid values is 0–2,147,482,647. A
value of 0 disables the timer.

Required Param: No
Default Value: 6000 ticks (60 seconds)

SET SERVER PARAM XN-TIMEOUT

Specifies the amount of time, in ticks, the NCP Server process waits for a response when it sends a network
control command to an NCPI Server process. The range of valid values is 0–2,147,482,647. A value of 0
disables the timer.

Required Param: No
Default Value: 3000 ticks (30 seconds)

NCPI server process

The following assigns, params, and defines are specific to the XPNET NCPI Server process. One NCPI Server
process must exist for each XPNET node in the XPNET system. In addition to these XPNET-specific assigns and
params, the MAXSERVERS and NUMSTATIC attributes must be set to 1. For information about the HP NonStop
server attributes, see the HP NonStop NonStop TS/MP System Management Manual.

If you are adding many NCPI Server processes in the Pathway environment, you may want to
NOTE
evaluate the values of the various SET PATHWAY MAXxxxxxx attributes in the PATHCONF.

SET SERVER ASSIGN ALT-EVT

The fully qualified name of the alternate EMS collector process to which the NCPI Server process is to write
event messages if the primary collector process becomes unavailable. Valid values are $0 or the PPD name of
an alternate collector process.

Example: \SYS1.$0
Required Assign: No
Default Value: No default value

120
SET SERVER ASSIGN NCPCOM
The fully qualified name of the object file for the NCPCOM utility. If this assign is used, the NCPI Server process
starts an NCPCOM session when it starts the XPNET process. If this functionality is required, the NCP-IN and
NCP-OUT assigns are also required.

Example: $[Link]
Required Assign: No
Default Value: No default value

SET SERVER ASSIGN NCP-IN

The fully qualified file name of an input file to be processed by the NCPCOM utility. For more information on
specifying the input file and on the NCPCOM utility in general, see Network control point communications utility. If
this assign is used, the NCPCOM and NCP-OUT assigns are required.

Example: $[Link].N1ASTART
Required Assign: No
Default Value: No default value

SET SERVER ASSIGN NCP-OUT

The name of the output location for the NCPCOM utility. This location can be a spooler location or a disk file. If
this assign is used, the NCPCOM and NCP-IN assigns are required.

Example: $S.#N1ASTRT
Required Assign: No
Default Value: No default value

SET SERVER ASSIGN NCSP

The fully qualified file name of the Network Control Security Profile File (NCSP). This assign is required if the
ENABLE-SECURITY param is set to ON or DETAIL.

Example: \SYS1.$[Link]
Required Assign: Yes, if security is enabled
Default Value: No default value

SET SERVER ASSIGN NCSS

The fully qualified file name of the Network Control Security Specification File (NCSS). This assign is required if
the ENABLE-SECURITY param is set to ON or DETAIL.

Example: \SYS1.$[Link]
Required Assign: Yes, if security is enabled
Default Value: No default value

SET SERVER ASSIGN NEF

The fully qualified file name of the Network Environment File (NEF). A separate NEF must exist for each XPNET
node in an XPNET system.

Example: \SYS1.$[Link].N1ANEF
Required Assign: Yes
Default Value: No default value

121
SET SERVER ASSIGN NMAP
The fully qualified file name of the Network Map File (NMAP) for the XPNET system on this HP NonStop system.
If an XPNET system spans two or more HP NonStop systems, an NMAP must be located on each HP NonStop
system.

Example: \SYS1.$[Link]
Required Assign: Yes
Default Value: No default value

SET SERVER ASSIGN PRI-EVT

The fully qualified name of the primary EMS collector process to which the NCPI Server process is to write event
messages. Valid values are $0 or the PPD name of an alternate collector process.

Example: \SYS1.$0
Required Assign: Yes
Default Value: No default value

SET SERVER PARAM ALT-TIM-LMT

Specifies the amount of time, in ticks, that the NCPI Server process waits for a write to the alternate EMS
collector process to complete. The range of valid values is 0-32,767. A value of 0 disables the timer.

Required Param: No
Default Value: 500 ticks (5 seconds)

SET SERVER PARAM DELIVER-NOMOVERRIDE

Specifies whether the DELIVER msg^nom^override flag is set in the message header. By default, all DELIVER
messages have a msgnomoverride set to 0. If this parameter is specified it will apply to all deliver commands
(PROCESS, STATION & DEST) on that node. Valid values are as follows:

ON = Enables the DELIVER msg^nom^override flag in the message header to be a value other than 0.

OFF = Leaves the default value of 0 in the DELIVER msg^nom^override flag in the message header.

Required Param: No
Default Value: OFF

SET SERVER PARAM DELIVER-PRIORITY

Specifies the priority to assign to messages sent to the XPNET process through a DELIVER command. In most
cases, this priority causes the deliver message to be placed at the front of the object’s queue instead of at the
end of the queue. The range of valid values is 0-65535.

Required Param: No Default Value: 0

SET SERVER PARAM ENABLE-AUDIT

Specifies whether command auditing is enabled for this XPNET node. Valid values are as follows:

ON = Enables command auditing by generating one event message for each command issued.

OFF = Disables command auditing.

DETAIL = Enables command auditing by generating one event message for each object involved in a multiple-

122
 object command. Detail auditing applies only to object management commands.

Required Param: No
Default Value: OFF

SET SERVER PARAM ENABLE-SECURITY

Specifies whether security (command access limitation) is enabled for this XPNET node. Valid values are as
follows:

ON = Security is enabled.

OFF = Security is disabled.

DETAIL = Security is enabled, and invalid logon attempts are logged to EMS.

If this parameter is set to ON or DETAIL, the NCSP and NCSS assigns are required. For more information on
network control command security, see.

Required Param: No
Default Value: ON

SET SERVER PARAM PRI-TIM-LMT

Specifies the amount of time, in ticks, that the NCPI Server process waits for a write to the primary EMS collector
process to complete. The range of valid values is 0-32,767. A value of 0 disables the timer.

Required Param: No
Default Value: 500 ticks (5 seconds)

SET SERVER PARAM RQST-TIMEOUT

Specifies the amount of time, in ticks, the NCPI Server process waits for a response before it sends a request-
timed-out message. The range of valid values is 0-32,767. A value of 0 disables the timer.

Required Param: No
Default Value: 30000 ticks (5 minutes)

SET SERVER PARAM XN-LOCK

Specifies if detailed security violation messages are returned for commands that reference objects on an XPNET
node to which the user does not have command access. This assign is used only if the ENABLE-SECURITY
param is set to ON or DETAIL. Valid values are as follows:

ON = Detailed security violation messages are not returned for objects on the node to which the user does not
have access.

OFF = Detailed security violation messages are returned for each object on the node to which the user does not
have access.

Required Param: No
Default Value: ON

SET SERVER PARAM XN-TIMEOUT

Specifies the amount of time, in ticks, the NCPI Server process waits for a response when it sends a network
control command to the XPNET process it manages. The range of valid values is 0-32,767. A value of 0 disables

123
 the timer.

Required Param: No
Default Value: 3000 ticks (30 seconds)

SET SERVER DEFINE =_ACI_LICENSE_FILE

Specifies the name of the XPNET license file if the default license file on the XPNET subvolume is not being
used as the license file for the node. ACI recommends that the default location of the license file be used instead
of this define. This define, however, is provided to allow maximum flexibility, when necessary, for the location of
the XPNET license file.

If this define is used for one NCPI server, it should be used for all NCPI servers in this XPNET network on this
HP NonStop system, unless one node or a subset of nodes require a special license.

If this define is used for the license, then extra steps are required when installing a replacement XPNET license.
The operator will be required to manually rename the currently in use license file out of the way and the new
license into place before performing the CONTROL NODE command with the LICENSELOAD directive.

Required Define: No
Default Value: No default value.

The node will use the most current XPNET license on the subvolume where the XPNET network object file is
located.

Example:

SET SERVER DEFINE =_ACI_LICENSE_FILE, CLASS MAP, FILE \SYS.$[Link]

SET SERVER DEFINE =_EMS_TEMPLATES

If the latest EMS template files are not installed as the default, this define should be added to the NCPI server
configuration and pointed to the appropriate EMSNRES file. The following is an example of this define.

Required Define: No
Default Value: No default value

Example:

SET SERVER DEFINE =_EMS_TEMPLATES, CLASS MAP, FILE \SYS.$[Link]

Emergency assigns and params for the NCPI server process

The following assigns and params for the NCPI Server process are for emergency use only. They provide values for
attributes that the XPNET process typically reads from its NEF. They can be placed in a PATHCONF or XPCONF, so
the node can be restarted after a system failure that causes the NEF to become corrupted. These assigns and
params should not be used in standard configurations.

See the NET24-XPNET Network Control Command Reference Manual for more information on the following
attributes.

124
Assign Description
N-PPD The PPD name of the XPNET process

N-PROG The object file name for the XPNET process

N-SWAP A swap file or swap file volume for the XPNET process

N-EXTSWAP The extended swap file volume or extended swap file for the XPNET process

N-HOME The name of the home terminal for the XPNET process

N-CPU The CPU in which the XPNET process should be started

Defining and adding objects to an XPNET system

To add a device, line, link, node, dest, process, or station object, you first need to define the attribute values for the
object using a series of SET commands, and then add that object to the configuration using the ADD command. You
can enter these commands interactively from the NCPCOM utility, or you can place the commands in an obey file
and then run the obey file from the NCPCOM utility or from the NCS screen.

Newly added line, link, node, and process objects are placed in the Disabled state. By default, they immediately
receive an implicit ENABLE command and transition through the Disabled state to the Stopped state, unless you
specify the Disabled state in the ADD command or you have used the SET ADDTYPE command to set the implicit
configuration state for ADD commands to DISABLED.

For example, the following series of commands specifies a set of attributes for a process and adds that process to
the configuration.

SET PROCESS PROGRAM $[Link]

SET PROCESS PPD $AP01
SET PROCESS CPU 1
SET PROCESS PRIORITY 170
SET PROCESS STARTUP AUTOMATIC
SET PROCESS QAT 50
SET PROCESS QMT 100
SET PROCESS QMI 85
SET PROCESS CLASS APROC:COPY1
SET PROCESS UCQUEUE APROCQUEUE
SET PROCESS UCRATE APROCRATE
SET PROCESS UCSTATE APROCSTATE
ADD PROCESS \SYS1.P1A^NODE.P1A^APROC1

The series of SET PROCESS commands in the example above defines the working set of process attributes. A
working set of attributes is defined as the list of valid attributes and their current values for a particular object type.
Each object type has its own working set of attributes maintained in separate buffers. These working sets of
attributes are used only for adding objects; they have no effect on previously configured objects.

125
When you start the NCPCOM utility, each working set contains default values for attributes that have defaults or
blanks for attributes that do not have defaults. As you enter SET commands for an object, the attribute values in that
working set change in response to the values you specified with the SET commands.

After you enter an ADD command, the values in the working set for that object type stay unchanged unless you
perform one of the following:

• Enter another SET command for that object type. This changes the specified attribute value; all other attribute
values stay the same.
• Enter a RESET command for the object type. This changes the value of a specific attribute or the values of all
the attributes to their default (or blank) values. The RESET command is described in Resetting attributes in the
working set.
• Exit the NCPCOM utility. This empties the buffer containing the working set.

You can also use the SET LIKE command to define attributes that are the same as a previously configured object.
You can then use the SET command to change one or more attributes to a different value before you add the object
to the configuration. For example, the following commands define the attributes for a process the same as a
previously configured process, then change the PPD name, the startup logic, and the class name, and finally add the
process to the configuration.

SET PROCESS LIKE \SYS1.P1A^NODE.P1A^APROC1

SET PROCESS PPD $AP02
SET PROCESS STARTUP DEMAND
SET PROCESS CLASS APROC:COPY2
ADD PROCESS \SYS1.P1A^NODE.P1A^APROC2

You do not have to define all attributes, only those attributes for which you want to change the default values and
those attributes that do not have a default value and are required (for example, the PROGRAM attribute for the
PROCESS object type). You can enter the attributes in any order, with the following exceptions.

• Protocol-specific line attributes cannot be set until the protocol has been specified for the line.
• Protocol-specific station attributes cannot be set until the line with which the station is to be associated has been
specified. The line with which the station is to be associated establishes the protocol for the station.

Displaying current values for attributes

To determine what the current values are for a particular object type, you can use the SHOW command, which
displays all attributes in the working set along with the current values for those attributes. If this is the first command
that you executed after starting the NCPCOM utility, the values displayed are the default values. If you have entered
one or more SET commands, the values displayed are the current values for the working set of attributes.

For example, after entering the SET PROCESS commands shown in the first example in this section, the following is
the result of the SHOW PROCESS command.

126
 40 > show process
PROCESS: ENABLED
PROGRAM $[Link] TYPE NSK
LIBRARY
HOMETERM
DESTINATION AUTOPRI 128
DEVICENAME WARMPRI 128
XNCALIAS MSGPRO NORMAL
PPD $AP01 STARTUP AUTOMATIC ADOPT OFF
CPU 1 BCPU -1
PRIORITY 170 RETRIES 0 RED 0
CLASS APROC:COPY1 SOURCECLASS
SERVICE SMT 0
SAVEABEND ON DEBUG OFF DEFINES ON
IAUDIT OFF OAUDIT OFF OUTPUT ON
MORE>>> 41 +
PROCESS:
QAT 50 QMT 100 QMI 85%
QGCDEPTH 0
UCQUEUE APROCQUEUE UCRATE APROCRATE UCSTATE APROCSTATE
EXTSWAP
SWAP
XPNETSTARTSEQ ON REPLACEDEST ON RTS OFF
STARTOPTIONS
MORE>>> 41 +
PROCESS:
SENDTIMER 0 TCPIPPRO
PROTOCOL TCP AWAITTIMER 0
LOCALPORT LOCALADDR
REMOTEPORT1 0 REMOTEADDR1
REMOTEPORT2 0 REMOTEADDR2
REMOTEPORT3 0 REMOTEADDR3
CONNTYPE COMMAND TCPRETRIES 0
RTSINIT IMMEDIATE
CONNCONFIG DRPPD
NCSPFILE PROFILE
DRSAFPRI DRSAFBACK
DRSAFPAGES 2048 DR OFF
MORE>>> 41 +
PROCESS:
EVENT GENERATION --
PROABNORMAL NODE PROAVAIL NODE PROCONFIG NODE PRODEBUG NODE
PRODIAG NODE PROINFO NODE PROOTHER NODE PROTHRESHOLD NODE
PROUNAVAIL NODE

If the current values are not the default values, you can enter the RESET command before issuing the SHOW
command. For example, the following commands reset the values of all process attributes to the default values and
then display the process attributes and default values to the screen.

RESET PROCESS

SHOW PROCESS

The following is the result of the above commands.

127
 42 > show process
PROCESS: ENABLED
PROGRAM TYPE NSK
LIBRARY
HOMETERM
DESTINATION AUTOPRI 128
DEVICENAME WARMPRI 128
XNCALIAS MSGPRO NORMAL
PPD STARTUP COMMAND ADOPT OFF
CPU -1 BCPU -1
PRIORITY 100 RETRIES 0 RED 0
CLASS SOURCECLASS
SERVICE SMT 0
SAVEABEND ON DEBUG OFF DEFINES ON
IAUDIT OFF OAUDIT OFF OUTPUT ON
MORE>>> 42 +
PROCESS:
QAT 0 QMT 0 QMI 0%
QGCDEPTH 0
UCQUEUE UCRATE UCSTATE
EXTSWAP
SWAP
XPNETSTARTSEQ ON REPLACEDEST ON RTS OFF
STARTOPTIONS
MORE>>> 41 +
PROCESS:
SENDTIMER 0 TCPIPPRO
PROTOCOL TCP AWAITTIMER 0
LOCALPORT LOCALADDR
REMOTEPORT1 0 REMOTEADDR1
REMOTEPORT2 0 REMOTEADDR2
REMOTEPORT3 0 REMOTEADDR3
CONNTYPE COMMAND TCPRETRIES 0
RTSINIT IMMEDIATE
CONNCONFIG DRPPD
NCSPFILE PROFILE
DRSAFPRI DRSAFBACK
DRSAFPAGES 2048 DR OFF
MORE>>> 42 +
PROCESS:
EVENT GENERATION --
PROABNORMAL NODE PROAVAIL NODE PROCONFIG NODE PRODEBUG NODE
PRODIAG NODE PROINFO NODE PROOTHER NODE PROTHRESHOLD NODE
PROUNAVAIL NODE

Note that the SHOW commands for the line and station object types do not display the protocol-specific line and
station attributes until the protocol has been specified for the line. Once the protocol is set for the line, all line and
station attributes associated with the specified protocol can then be displayed.

Resetting attributes in the working set

The RESET command changes (or resets) one or more attributes in a working set to their default values (or blanks
for those attributes that do not have defaults). You can specify that an individual attribute be reset, that all attributes
for a particular object type be reset, or, for the NODE object only, that a particular subset of attributes be reset. Note
that this command does not reset attribute values for currently configured objects.

For example, if you want to change the priority for the process object type to the default value of 100, you would

128
enter the following command:

RESET PROCESS PRIORITY

If you do not include an attribute in the RESET command, all attributes of the specified object type are reset to their
default values.

For the NODE object type, additional parameters are available that enable you to reset a subset of attributes. The
following list indicates these additional parameters.

AUDINFO EVT^DIAG

EVTINFO EVT^INFO

EVT^ABNORMAL EVT^OTHER

EVT^AVAIL EVT^THRESHOLD

EVT^CONFIG EVT^UNAVAIL

EVT^DEBUG

For example, the following command resets the node attributes associated with event message generation to their
default values.

RESET NODE EVTINFO

Using configuration input files

You can enter all configuration commands in an edit file and then use the OBEY command to execute the edit file
from a network control facility. ACI recommends that you either include the LOG command in the obey file or use the
OUT file-name option so that all commands in the obey file and responses to those commands are written to an
output file. If you are using a configuration file containing a large number of commands (for example, adding a
thousand stations), it is particularly important that you be able to review the results of the obey file.

ACI recommends that you use the ALLOW command to set your environment to ALLOW NO ERRORS and ALLOW
NO WARNINGS. If there is a problem with the configuration input file, the file will stop on the first problem and you
will be able to correct it. If objects were successfully added before the file stopped, you will need to edit the file to
remove the commands for those objects before re-executing the input file. If an attempt is made to add an object that
already exists on the node, the XPNET process generates an error.

If you choose to allow the entire file to execute (allowing all errors and warnings), you will need to search the entire
output file for errors. Issues you might typically find when you execute a large configuration file are listed below
along with a word that you can use to search the output file for that possible problem.

129
Possible Problem Search For:
Pathway or XPMON error error

Syntax error expecting

Command rejected failed

Guidelines for defining and adding objects

This section provides some guidelines for defining and adding node, process, link, dest, line, device, and station
objects. Nodes must be added before the addition of any objects under the node. A device and a line referenced in a
station definition must be added before the station can be added. In addition, a controller station must be defined to
the XPNET node before stations that are tributaries of the controller station.

The symbolic name of a node to be added must be unique within the HP NonStop system. The symbolic name of
other objects to be added must be unique within the XPNET node with the exception of dest objects, which may
have names identical to processes or stations. For all ADD commands, the fully qualified object name must not
contain any wildcard characters. For ADD NODE commands, the HP NonStop system name must be specified. For
other ADD commands, the HP NonStop system name and the XPNET node name must be specified.

A symbolic name can be fully qualified by explicitly entering the HP NonStop system name and XPNET node name
with the object name, by identifying them with the UNDER SYSNAME and UNDER NODE filters, or by specifying
them with the ASSUME command.

You can specify that line, link, node, and process objects be added to the configuration in a Disabled or Enabled
configuration state. An object in the Enabled configuration state can be started and stopped and is available for
processing. An object in the Disabled state is essentially invisible and is not available for processing until it has been
changed to the Enabled configuration state using the ENABLE command. If you do not specify a state with the ADD
command and you have not entered a SET ADDTYPE command with the DISABLED parameter, the object is added
in the Enabled configuration state. Adding an object in the Disabled state is useful for a contingency configuration.
For more information on contingency configurations, see Managing a contingency configuration.

An XPNET node cannot be started (initialized) until it has first been enabled. Objects can be added to an XPNET
node whether the node is started or stopped, enabled or disabled; however, objects in the node cannot be started
until the XPNET node has been enabled and started. Line, link, and process objects under a disabled node must be
in the Disabled state.

Sample XPNET node configuration illustrates a sample configuration for a node.

Node definitions
The following attributes are required for a node definition:

• The PPD name of the PATHMON or XPMON process for the NCPI Server process. Typically, the NCPI Server
processes are all in the same Pathway or XPMON subsystem, which is the standard subsystem used for
network management. This PPD name is set using the PATHMON attribute or XPMON attribute.
• The server class name of the NCPI Server process for the node. The NCPI Server processes must all have
unique server class names. The server class name is set using the SERVERCLASS [Link] NCPI Server

130
 process passes command and control messages between the NCP Server process and the XPNET process. A
separate NCPI server class must be defined for each XPNET node in an XPNET system. This information is
stored in the NMAP used by the NCP Server process to route command and control messages to the
appropriate NCPI Server process.
• The PPD name of the XPNET process. This is set using the PPD attribute.
• The location of the object file that contains the processing logic for the XPNET process. This is set using the
PROGRAM attribute.
• The names of the primary and alternate EMS collector processes for the XPNET process. These are set using
the LOGFILE and ALTLOGFILE attributes.

If you want to see the startup messages when you start the node, you must also specify the name
NOTE
of the home terminal for the node. This is set using the HOMETERM attribute.

In addition, node definitions typically contain the following configuration information:

• The CPUs in which the primary and backup XPNET processes should run. The CPUs are set using the CPU
and BCPU attributes. If you have more than two CPUs, you can set CPU, BCPU, and SBCPU to different
values. This will allow XPNET to survive two CPU failures and continue running with no data loss (if you are
using hot backup). If you are running warm backup, it recommended that you set the NCPI process primary CPU
to a different value than thet XPNET node CPU.
• The startup logic for the XPNET node. This is set using the STARTUP attribute.
• The priorities of the primary and backup XPNET processes. These are set using the PPRI and BPRI attributes.
• The number of pages of extended memory that the XPNET process is to allocate. This is set using the
EXTPAGES attribute. Guidelines for calculating the value of this attribute are described later in this section.
• The volumes and subvolumes in which configuration journal files are to be placed. These are set using the CJA,
CJB, and CJC attributes. The naming conventions for the subvolumes are described in XPNET components. If
you enter a value in one or more of these attributes, you must also set the CJ attribute to ON.
• The volumes and subvolumes in which network overload management files are to be placed. These are set
using the NOMA, NOMB, and NOMC attributes. The naming conventions for the subvolumes are described in
XPNET components. If you enter a value in one or more of these attributes, you must also set the NOMTODISK
attribute to ON.

The following is an example of a basic node definition in the Pathway environment. Naming conventions for nodes
are described in XPNET components.

131
 SET NODE PATHMON $PPMN
SET NODE SERVERCLASS SERVER-NCPI-1A
SET NODE PPD $P1AN
SET NODE PROGRAM $[Link]
SET NODE LOGFILE $0
SET NODE ALTLOGFILE $0
SET NODE CPU 0
SET NODE BCPU 1
SET NODE STARTUP AUTOMATIC
SET NODE PPRI 155
SET NODE BPRI 180
SET NODE EXTPAGES 3200
SET NODE CJA $DATA.P1ANCJA
SET NODE CJB $DATA.P1ANCJB
SET NODE CJC $DATA.P1ANCJC
SET NODE CJ ON
SET NODE NOMA $DATA.P1ANNOMA
SET NODE NOMB $DATA.P1ANNOMB
SET NODE NOMC $DATA.P1ANNOMC
SET NODE NOMTODISK ON
ADD NODE \SYS1.P1A^NODE

For the XPMON environment, the basic node definition would be the same as above except for the first SET
statement:

SET NODE XPMON $PPMN

In addition to the basic node elements, some node definitions include additional information. These additional
attributes configure the following options:

• Whether the XPNET process is to start and run as a high PIN process. This is set using the HIGHPIN attribute.
• What types of event messages are to be generated. You can specify if each event type is to be generated for all
object types or for each individual object type.
• The thresholds, in number of messages queued to the various queues, above which the XPNET process begins
generating queue alert event messages. These thresholds are set using the LOGEQAT, LOGNQAT, UDQAT, and
USQAT attributes.
• The percentages of XPNET process total memory used for evaluating whether to take network overload
management actions on the various queues. These percentages are set using the LOGEQMI, LOGNQMI,
UDQMI, and USQMI attributes.
• The thresholds, in number of messages queued to the various queues, above which the XPNET process begins
taking network overload management actions. These thresholds are set using the LOGEQMT, LOGNQMT,
UDQMT, and USQMT attributes.
• The name of the Logical Network Configuration File (LCONF), if your application uses the logical network
concept. This is set using the STARTOPTIONS attribute.

Estimating the number of extended memory pages

The XPNET process uses extended memory to store internal tables used during processing, to provide dedicated
I/O buffers for each process and line, and to queue messages intended for a log queue, process, or station until that

132
object is ready to process the message. You set the number of extended memory pages using the EXTPAGES
attribute.

If you set a number that is too low for your system and message needs, additional memory pages will be allocated
automatically but this allocation process can degrade system performance. If needed, additional memory pages will
continue to be allocated until the system reaches the limit to the number of pages (65535 memory pages), after
which the system will abend. The optional EXTINCREMENT attribute sets up how many pages in a block will be
allocated at a time if needed; allocating them in a block rather than one at a time can help with performance issues.

The following are guidelines for estimating the value of the EXTPAGES attribute for each node on your production
system. On a test or development system with minimal queueing requirements and only a small number of stations
and lines configured, the default value of 2048 for the EXTPAGES attribute normally provides sufficient memory
space.

1. Calculate the memory required for buffers.

a. Determine the number of processes on the node. Multiply the value of the node attribute MAXPROMSG
attribute by the number of processes.
b. Determine the number of links on the node. Multiply the number of links by 32000.
c. Determine the number of lines associated with the node. Multiply the larger of the receive or transmit length
by the number of lines. For SLU, PLU, and full duplex X.25 lines, double the larger of the receive or transmit
length for each line to allow for concurrent I/Os.
d. Add the results of the above calculations together to determine the total buffer space requirement.
2. Determine the number of devices associated with the node. Multiply the number of devices by 1900 bytes to
determine the size of the device table.
3. Determine the number of stations on the node. Multiply the number of stations by 2000 bytes to determine the
size of the station table including protocol extensions.
4. Multiply the number of lines by 700 bytes to determine the size of the line table.
5. Multiply the number of processes by 1400 bytes to determine the size of the process table.
6. Multiply the number of dest objects by 400 bytes to determine the size of the dest object table.
7. Determine the number of messages to queue in memory. ACI recommends a minimum of 1000 messages but
suggests that the number used provides for a minimum of ten minutes worth of message traffic through the node
(that is, node tps * 600). Multiply the average size of a message by the number of messages.
8. If your environment requires messages larger than 32k and you have implemented the new large message
enhancement, you should multiply MAXLARGEMSGSIZE * the number of concurrent large messages you want
to be able to queue within the XPNET memory.
9. Add the amounts calculated in steps 1 through 8, and add 4.0 megabytes for the destination table and internal
context tables.
10. Divide the total number of bytes by 2048 to convert bytes to pages.
11. Add 500 pages for overhead that the system needs if large messages will be routed in smaller chunks.
12. Round this value up to allow for fragmentation.
13. If you configure PAYLOADPAGES (see the next subsection), that number is added to the EXTPAGES as
instructed.

For example, assume a node with the following configuration:

133
Number of processes: 30 (MAXPROMSG = 4096)

Number of lines: 200 SLU lines with receive/transmit length of 3072

Number of stations: 200

Number of devices: 10

Number of dest objects: 20

Average size of message: 1024

Node transactions per second (tps): 5

Payloadpages: 0

MAXLARGMSGSIZE: 1048276 (1 MB)

Concurrent Queued Large Messages: 20 20

The following is the calculation for this node:

Step 1: (30 * 4096) + (200 * 2 * 3072) = 1351680

Step 2: 10 * 1900 =19000

Step 3: 200 * 2000 = 380000

Step 4: 200 * 700 = 140000

Step 5: 30 * 1400 = 42000

Step 6: 20 * 400 = 8000

Step 7: 5 * 1200 * 1024 = 6144000 (20 minutes message traffic allowed for)

Step 8: 20 * 1048575 = 20971520

Step 9: (1351680 + 19000 + 400000 + 140000 + 42000 + 8000 + 6144000 +

20971520 ) + (1048667 * 4 ) = 33270504

134
Step 10: 33270504 / 2048 = 16245.4

Step 11: 16245.4 + 500 = 16745.4

Step 12: EXTPAGES = 16800

It is important to make this estimation when you originally configure the node. However, you should continue to
monitor memory utilization using the STATUS NODE command with the DETAIL modifier, the STATISTICS NODE
command with the DETAIL modifier, memory alert threshold (MAT) event messages, and node statistics event
messages.

You can dynamically increase the amount of memory available by altering the value of the EXTPAGES attribute and
then issuing a CONTROL NODE command with the RESIZESEGMENT directive to bring the new value into effect.
However, executing this CONTROL NODE command can cause serious performance degradation and you should
do this only during quiet processing periods.

Estimating the value for the PAYLOADPAGES attribute

The PAYLOADPAGES attribute defines the number of extended memory pages the system uses for payload
management within the node. The system allocates this number of extended pages from the number of pages you
defined in the EXTPAGES attribute. The PAYLOADPAGES attribute defines a subset of the EXTPAGES attribute.

The default value for the PAYLOADPAGES attribute is zero, which disables payload management in the node. You
cannot set the PAYLOADPAGES attribute higher than 30% of the value of the NODE EXTPAGES attribute.

You should set the PAYLOADPAGES attribute to a valid nonzero value only when XPNET must manage payloads on
behalf of processes that are not configured to receive messages with payloads. Payloads in XPNET messages are
extensions of the message which allow the sender to add additional data to the message. For example, messages
inbound on WebGate Interface (WGI) STATIONS and messages from Java processes have payloads attached. If
these messages are sent to application processes that cannot process payloads, the XPNET process saves the
payload portion of the message in memory on behalf of the application, and reattaches it to the response message.

To calculate the value for the PAYLOADPAGES attribute, you must calculate the potential maximum number of
payloads that the XPNET node is to manage for all application processes at any given time. Use the following steps
and worksheet to calculate the correct value:

1. Count the number of application processes configured in the node that process messages in a synchronous
fashion, and can have messages with payloads queued to them even if they are not designed to handle
payloads. A single payload is the maximum that can be held in memory for each of these processes at any one
time. You can identify these processes because they have no extra payload-specific code that allows them to
process payloads in any other way.

Assign the value S to this number. The value S is the maximum payloads for synchronous processes.

2. For nonsynchronous applications that receive the payload key in userdata and return it to the XPNET process in
the response message, the maximum number of payloads that the XPNET process can hold in memory for that
application is equivalent to the number of requests that can be outstanding to that application at any one time.
For each of these processes, calculate the maximum number of payloads that could reasonably be outstanding
and add those values together for all nonsynchronous processes that can receive messages with payloads.

135
 An example of a nonsynchronous application is a Host Interface process that receives a request and sends it to
a host for processing. Many transactions can be processed before the response to the request is returned to the
host interface process from the host. The host interface process creates the final response message. Calculate
the number of payloads that the XPNET process must manage for Host Interface processes as follows: if there
are 4 Host Interface processes that receive messages with payloads, and each can have 50 transactions
outstanding at one time, the number of payloads is 200 (4 Host Interface processes times 50 transactions is
equal to 200).

Assign the value N to this number. The value N is the maximum payloads for nonsynchronous processes.

3. Add the calculated values S and N to get the maximum number of payloads that the XPNET process is to
manage at any one time.

Assign the value M to this number. The value M is the maximum number of payloads that the XPNET node must
manage at any time.

4. After you have calculated the value of M, multiply M by the largest payload size expected. You can estimate this
value during testing, since the STATUS NODE,DETAIL command now shows the maximum payload size
encountered by the node. This multiplication step calculates the total number of bytes needed for storing
payloads, except for some overhead that you must still calculate.

Assign the value PB to this number. The value PB is the maximum number of payload bytes that the XPNET
node must manage at any one time.

5. Divide the value PB by the value 2048 to calculate the number of pages required by the node for payload
management, except for overhead.

Assign the value PP to this number. The value PP is the maximum number of payload pages that the XPNET
node must manage at any one time, minus overhead.

6. To determine the number of payload pages required for overhead, you must consider two separate components:

22 bytes of overhead are needed for each payload that is stored in memory. Therefore, multiply the value M by
the value 22. Divide the result by the value 2048 to get the number of pages required for individual payload
overhead.

Assign the value OP1 to this number. The value OP1is the overhead pages needed for individual payloads.

Memory must also be reserved for the payload table in memory. This requires 6 pages of memory for every 1000
payloads that must be stored in memory. Calculate this value using the following formula:

(( M / 1000 ) + 1 ) x 6

For example, if M equals the value 0 minus 1000, 6 extra pages are required for this component. If M equals the
value 1000, 12 extra pages are required for overhead.

Assign the value OP2 to this number. The value OP2 is the number of overhead pages required for the payloads
table.

Add the value OP1 and the value OP2 to calculate the total number of pages required for payload processing
overhead.

Assign the value OP to this number.

136
 7. Add the value PP and the value OP to calculate the PAYLOADPAGES value.
8. To implement the calculated number of PAYLOADPAGES in the network, add the value of the PAYLOADPAGES
just calculated to the value of the EXTPAGES attribute. Alter the EXTPAGES attribute to the new combined
value, increasing it by the PAYLOADPAGES value. It is necessary to increase the EXTPAGES value by this
amount since PAYLOADPAGES defines a subset of the EXTPAGES attribute. Perform the following steps:
a. Number of payloads XPNET must manage for nonsynchronous processes. For each process type, multiply
the number of processes of that type times the number of messages which can be outstanding to that
process at one time.
b. Enter the following command:

ALTER NODE <node name>, EXTPAGES <new value> c.

c. Enter the following command:

CONTROL NODE <node name>, RESIZESEGMENT

This is a system intensive command. To avoid impacting system performance, perform this
NOTE
command at an off-peak time.

d. Enter the following command:

ALTER NODE <node name>, PAYLOADPAGES <value>

e. Enter the following command:

CONTROL NODE <node name>, RESIZEPAYLOAD

The CONTROL NODE, RESIZEPAYLOAD command does not impact the system like the
RESIZESEGMENT command. PAYLOADPAGES can be modified up or down as needed. But, the value of
the PAYLOADPAGES attribute cannot be set less than the value currently being used unless it is set all the
way back to zero. The RESIZEPAYLOAD command enters the current PAYLOADPAGES value into effect in
the node. No extra memory is actually allocated or deallocated since the PAYLOADPAGES used are taken
from the total EXTPAGES as they are needed.

PAYLOADPAGES worksheet

Use this worksheet to calculate the values of the steps above.

1. Number of synchronous processes not handling payloads: _________ (= S)

2. Number of payloads XPNET must manage for nonsynchronous processes. For each process type, multiply the
number of processes of that type times the number of messages which can be outstanding to that process at
one time.

Num. Pros. X Msgs. Outst. = TTL Msgs. per

Type

Process Type 1: _______ X _______ = _______

137
 Process Type 2: _______ X _______ = _______

Process Type 3: _______ X _______ = _______

Process Type 4: _______ X _______ = _______

Process Type 5: _______ X _______ = _______

Total Payloads = _______(= N)

XPNET must
manage (sum)

3. Add the values from steps (1) and (2). This gives the maximum number of payloads XPNET must manage at
any one time.

_______(S) + _______(N) = _______ (= M)

4. Maximum Payload Bytes. Multiply M (from step 3) by the maximum payload size expected.

_______(M) x _______(max size) = _______ (= PB)

5. Maximum Payload Pages (without including overhead).

_______(PB) / 2048 = _______ (= PP)

6. Pages needed for overhead.

_______(M) x 22 (bytes) = _______ / 2048 (bytes) = _______ (= OP1)

_______(M) / 1000 =_______ + 1 =_______ x 6 (pages) = _______ (= OP2)

OP1 + OP2 = _______(= OP)

7. Total Payload Pages required.

_______(PP) + _______(OP) = _______ (= PAYLOADPAGES)

Reducing "Out of Memory" errors

Network trap 6410 occurs when a request for a block of memory from the XPNET memory manager fails because
memory is exhausted. The EXTINCREMENT attribute, which is set at the NODE level, helps extend the memory set
by the EXTPAGES attribute so that these traps do not occur. This attribute defines how many pages the segment will
be incremented at a time.

When Network Overload Management (NOM) is configured properly, trap 6410 should not occur, but such traps still
occur when NOM is not enabled, NOM attributes are not configured correctly, unexpected peak transaction volumes
or system performance issues occur and when additional objects (LINES, STATIONS, PROCESSES) are configured
over time without increasing the EXTPAGES attribute to account for them.

138
When this configuration is set properly, it improves the availability of the XPNET node by automatically increasing its
extended memory segment size in the event of peak burst of transactions, application problem or some type of
system or performance issue that would normally cause message queues to build to a point where the XPNET
nodes memory pool is exhausted and abends. Second it provides an additional level of support if NOM is not
enabled or is not configured correctly to handle an unexpected queuing event. In addition, this can reduce how many
times the segment will be resized, thus limiting the number of log events and amount of overhead. Lastly the
intention is to keep the nodes up long enough for the queuing event to subside and / or for the operations staff to
determine and resolve what the root cause is.

By default, the EXTINCREMENT attribute is set to 0 which disables this extension functionality and the node will
abend with a 6410 when it runs out of memory. If the EXTINCREMENT attribute is > 0 and the maximum extended
segment size has not been reached, the XPNET node will attempt to resize the memory manager segment to be
larger based on this attribute. If the segment is resized successfully, another attempt to allocate the block of memory
being requested will be made and should be successful.

If the EXTINCREMENT attribute is > 0 and the maximum extended segment size has been reached, trap 6410 will
still occur. This can happen if the resources consuming memory continuously do so at a rate higher than queues can
be serviced.

The XPNET node will generate EMS event 6479 each time the memory segment is incremented. This log event
includes the number of pages it was incremented by (EXTINCREMENT except for the final try), the size it was
incremented to, and a count of the number of times it has been incremented.

In the following example, EXTINCREMENT was configured to 2000.

16-10-03;09:55:45.418 \SYSTEM.$P1AN [Link].3400 6479

Extended Memory Segment was incremented by 2000 pages to 50000 pages
(count=20).

If the segment is incremented over and over, to the point of just short of the maximum segment size, a final attempt
to increase it to the maximum size is made.

16-10-03;11:45:12.161 \SYSTEM.$P1AN [Link].3400 6479

Extended Memory Segment was incremented by 1535 pages to 65535 pages
(count=28).

If the problem persists, the next attempt to allocate memory when the segment is full will cause trap 6410 as in the
past.

16-10-03;12:06:32.404 \SYSTEM.$SAT01 [Link]-U.3700 8001

!!! FROM: P1A^SAT01 RE: P1A^SAT01
$P1AN file error 201 (the current path to the device is down)

EXTINCREMENT valid values

• Default 0 - The RPE is disabled, 6410 traps occur as before.

• Minimum 1024

139
 • Maximum 64511

If you want to increase EXTPAGES manually, you must alter EXTPAGES to be larger than the current size (the value
in parenthesis), then do "control node <name>, resizesegment" as before. As before, the segment cannot be resized
to be smaller than the current size (now in parenthesis). As before to make the segment size smaller, the
EXTPAGES configured value can be altered smaller, but a "resizesegment" command will fail at that point, the node
must be re-started for the smaller size to take effect.

If the node is restarted for any reason, the current memory size will go back to the configured EXTPAGES value (not
the value to which it may have been incremented).

Node attributes

The following is a list the attributes that can be defined for a node.

• ADEXTENT
• ADMAXEXTENTS
• ALTLOGFILE
• AUDERROR
• AUDIT
• AUDITA
• AUDITB
• AUDITC
• AUDITIO
• BACKUPTYPE
• BCPU
• BPRI
• BRETRYDELAY
• CJ
• CJA
• CJB
• CJC
• CJPAGES
• CPU
• DD
• DR
• DEBUG
• EXTAUDBACK
• EXTAUDDIAGDEST
• EXTAUDFILECDE

140
• EXTAUDIO
• EXTAUDPAGES
• EXTAUDPRI
• EXTAUDQAT
• EXTAUDQMI
• EXTAUDQMT
• EXTAUDRETDAYS
• EXTAUDSTATINT
• EXTAUDTCPIP
• EXTINCREMENT
• EXTPAGES
• EXTSWAP
• HIGHPIN
• HOMETERM
• HSMKEY
• HSMLOCALADDR
• HSMPROTOCOL
• HSMREMOTEADDR
• HSMREMOTEADDR2
• HSMREMOTEPORT
• HSMREMOTEPORT2
• HSMSECUREBOX
• HSMTCPIPPROCESS
• HSMTIMER
• LASTAT
• LINEABNORMAL
• LINEAVAIL
• LINECONFIG
• LINEDEBUG
• LINEDIAG
• LINEINFO
• LINEOTHER
• LINESUPP
• LINETHRESHOLD
• LINEUNAVAIL

141
• LINKABNORMAL
• LINKAVAIL
• LINKCONFIG
• LINKDEBUG
• LINKDIAG
• LINKINFO
• LINKOTHER
• LINKTHRESHOLD
• LINKUNAVAIL
• LOGEQAT
• LOGEQMI
• LOGEQMT
• LOGFILE
• LOGNQAT
• LOGNQMI
• LOGNQMT
• MAT
• MAXLARGEMSGSIZE
• MAXPROMSG
• MED
• MEMFRAGPAGES
• MONITOR
• MONNOM
• MONQAT
• MONSTATES
• MSGPRIORITY
• MSGPRO
• MSGTIMEOUT
• NODEABNORMAL
• NODEAVAIL
• NODECONFIG
• NODEDEBUG
• NODEDIAG
• NODEINFO
• NODEOTHER

142
• NODETHRESHOLD
• NODEUNAVAIL
• NOMA
• NOMB
• NOMC
• NOMFILECODE
• NOMPAGES
• NOMTODISK
• OSIENABLE
• PATHMON
• PAYLOADPAGES
• PAYLOADTIMEOUT
• PFS
• PPD
• PPRI
• PROABNORMAL
• PROAVAIL
• PROCONFIG
• PRODEBUG
• PRODIAG
• PROGRAM
• PROINFO
• PROOTHER
• PROTHRESHOLD
• PROUNAVAIL
• QED
• QUETHRESHOLD
• QWRFILECODE
• REALTIMEAUD
• REPLICATION
• RTS
• SASTAT
• SBASTALEACTION
• SBASTALETIMEOUT
• SBASTALETIMER

143
 • SBCPU
• SERVERCLASS
• SINTERVAL
• SSLEXTMEG
• SSLMAT
• SSLMED
• SSLRECSIZE
• SSLSEGSIZE
• SSLWRAP
• STAABNORMAL
• STAAVAIL
• STACONFIG
• STADEBUG
• STADIAG
• STAINFO
• STAOTHER
• STARTOPTIONS
• STARTUP
• STASUSPENDED
• STATHRESHOLD
• STAUNAVAIL
• STD
• SWAP
• UDFAIL
• UDQAT
• UDQMI
• UDQMT
• USQAT
• USQMI
• USQMT
• X25TRUNKDEL
• XPMON

Process definitions
Basic process definitions specify the name of the process and the object file that contains the processing logic. In
addition, process definitions typically contain the following configuration information:

144
 • The CPU and alternate CPU in which the process is to run. The CPUs are set using the process CPU and
BCPU attributes.
• The name of a library file for the process. This is set using the LIBRARY attribute.
• The priority at which the process is to run. This is set using the PRIORITY attribute.
• A PPD name for the process. This is set using the PPD attribute.
• The startup logic for the process. This is set using the STARTUP attribute.
• Whether the process is part of a user-defined grouping or class. This is set using the CLASS attribute.
• A threshold, in number of messages queued to the process, above which the XPNET process begins generating
queue alert event messages on behalf of the process. This is set using the QAT attribute.
• A threshold and an index above which the XPNET process begins performing network overload management on
behalf of the process. These are set using the QMT and QMI attributes.
• Counters to use in monitoring the process. These are set using the UCQUEUE, UCRATE, and UCSTATE
attributes.

You can define up to 4096 processes in each node. A sample of a basic process definition is shown below. The
following definition includes all of the information mentioned above. Naming conventions for processes are
described in XPNET components.

SET PROCESS PROGRAM $[Link]

SET PROCESS CPU 1
SET PROCESS BCPU 0
SET PROCESS LIBRARY$[Link]
SET PROCESS PRIORITY130
SET PROCESS PPD $PBP1
SET PROCESS STARTUP AUTOMATIC
SET PROCESS CLASSOMAHA:NEBR
SET PROCESS QAT 20
SET PROCESS QMI 85
SET PROCESS QMT 150
SET PROCESS UCQUEUE BPROCQUEUE
SET PROCESS UCRATE BPROCRATE
SET PROCESS UCSTATE BPROCSTATE
ADD PROCESS \SYS1.P1A^NODE.P1A^BPROC1

In addition to the basic process attributes, some process definitions include additional information. Typically, these
attributes appear in process definitions for certain types of processes only. These additional attributes configure the
following options:

• Whether messages to and from the process are audited. This is set using the IAUDIT and OAUDIT attributes.
• Whether TACL defines are passed to the process. This is set using the DEFINES attribute.
• Whether a process snapshot file should be created if the process abends. This is set using the SAVEABEND
attribute.
• A home terminal for the process. This is set using the HOMETERM attribute.
• A swap file for the process. This is set using the SWAP attribute.
• An extended swap file for the process. This is set using the EXTSWAP attribute.
• One or more services that the process provides. This is set using the SERVICE attribute.

145
 • The XPNETSTARTSEQ. Set the XPNETSTARTSEQ ON to start satellite processes and OFF for external
processes.

The XPNET node must be added to the configuration before adding a process that is to run under that node.

Process attributes

The following is a list of the attributes that can be defined for a process.

• ADOPT
• AUTOPRI
• AWAITTIMER
• BCPU
• CLASS
• CONNCONFIG
• CONNTYPE
• CPU
• DEBUG
• DEFINES
• DESTINATION
• DEVICENAME
• DR
• DRPPD
• DRSAFBACK
• DRSAFPAGES
• DRSAFPRI
• EXTSWAP
• HOMETERM
• IAUDIT
• LIBRARY
• LOCALADDR
• LOCALPORT
• MSGPRO
• NCSPFILE
• OAUDIT
• OUTPUT
• PPD
• PRIORITY

146
• PROABNORMAL
• PROAVAIL
• PROCONFIG
• PRODEBUG
• PRODIAG
• PROGRAM
• PROINFO
• PROOTHER
• PROTHRESHOLD
• PROTOCOL
• PROUNAVAIL
• QAT
• QGCDEPTH
• QMI
• QMT
• RED
• REMOTEADDR1
• REMOTEADDR2
• REMOTEADDR3
• REMOTEPORT1
• REMOTEPORT2
• REMOTEPORT3
• REPLACEDEST
• RETRIES
• RTS
• RTSINIT
• SAVEABEND
• SENDTIMER
• SERVICE
• SMT
• SOURCECLASS
• STARTOPTIONS
• STARTUP
• SWAP
• TCPIPPRO

147
 • TCPRETRIES
• TYPE
• UCQUEUE
• UCRATE
• UCSTATE
• WARMPRI
• XNCALIAS
• XPNETSTARTSEQ

Recommendations for process priorities

The table below shows the interrelationship of the priorities of the major software components of an XPNET system.
This priority scheme is the result of benchmark research. The actual priority values listed are to serve as examples
only; it is the relationship of the process priorities that is important.

Process Priority
System TACL process (for emergency use) 199

HP NonStop HLS process 185

Backup XPNET process 180

Application processes that manage communications with other systems (such as 170
a host computer)

Application processes that perform online transaction processing 165

Primary XPNET, NCPI Server, NCP Server, and NCS Server processes 155

HP NonStop Zelm/Dmon processes, etc. 150

PATHMON process or XPMON process 145

Pathway Server processes 140

Pathway TCP 135

Application processes that perform batch processing (such as extracting data to 130
tape or generating periodic reports)

User TACL processes 120

148
Link definitions
Links identify the other XPNET nodes with which an XPNET node can communicate. The basic function of the link
definition is to provide a connection, using the PPD attribute, to another XPNET node. Each XPNET process is
responsible for establishing and maintaining its link with the other XPNET node. You can define up to 4096 links in
each node.

The definition for a link must include at a minimum a symbolic name and the PPD name of the XPNET process for
the XPNET node with which this XPNET node is communicating. Optionally, the link declaration can include the
following information:

• The startup logic for the link. This is set using the STARTUP attribute.
• Queue alert and network overload management thresholds. These are set using the QAT, QMI, and QMT
attributes.
• Whether messages to and from the link are to be audited. This is set using the IAUDIT and OAUDIT attributes.
• Whether the link is part of a user-defined class. This is set using the CLASS attribute.
• Counters to use in monitoring the link. These are set using the UCQUEUE, UCRATE, and UCSTATE attributes.

A sample link declaration is shown below. Naming conventions for links are described in XPNET components.

SET LINK PPD$P2AN

SET LINK STARTUP AUTOMATIC
SET LINK QAT225,
SET LINK QMI90,
SET LINK QMT200,
SET LINK UCQUEUE LINKQUEUE
SET LINK UCRATE LINKRATE
SET LINK UCSTATE LINKSTATE
ADD LINK \SYS1.P1A^NODE.P1A^LINK^P2A

The NODE object for this node (P1A^NODE) must be added to the configuration before adding the link.

Link attributes

The following is a list of the attributes that can be defined for a link.

• AUTOPRI
• CLASS
• DR
• IAUDIT
• LINKABNORMAL
• LINKAVAIL
• LINKCONFIG
• LINKDEBUG
• LINKDIAG

149
 • LINKINFO
• LINKOTHER
• LINKTHRESHOLD
• LINKUNAVAIL
• OAUDIT
• OUTPUT
• PPD
• QAT
• QMI
• QMT
• RTS
• STARTUP
• UCQUEUE
• UCRATE
• UCSTATE
• WARMPRI

Line, device, and station definitions

Line, device, and station definitions are interrelated. The XPNET process sends messages to stations throughout the
system via communications lines. Messages transmitted via communications lines are governed by line protocols.
Line definitions define logical attributes for data communications lines, including the protocol.

Device definitions provide protocol-specific attributes for generic types of stations within a network. Station
definitions specify the logical attributes for a station, or specific terminal. In each station definition, there is a
DEVICENAME attribute that references a specific device definition by the symbolic name assigned to the device.
Through the DEVICENAME attribute, the station assumes the attributes of the referenced device. This allows the
protocol-specific attributes to be specified once, although they may be used by numerous stations.

Stations can be started dynamically by the system, using one station as a template for additional stations that are
automatically created as needed. Additional information about the configuration of dynamic stations are in the
XPNET Internal TCPIP Implementation Guide.

Two things influence the configuration of a station: the type of terminal and the protocol being used to communicate
with the terminal. Many device and station attribute settings are specified by the terminal. The protocol being used
has an effect on the attributes in the device and station definitions for a terminal. A number of device and station
attributes are protocol specific, and have meaning only when used in conjunction with that protocol. The line with
which the station is associated establishes the protocol for the station.

Protocol-specific line attributes cannot be set until the protocol has been specified for the line. Once you specify the
line protocol, the SHOW LINE command displays the protocol-specific line attributes.

Protocol-specific station attributes cannot be set until the line with which the station is associated has been specified.
The station attribute LINENAME specifies the line with which the station is associated. Once you have specified the
LINENAME attribute, the SHOW STATION command displays the protocol-specific station attributes.

150
The XPNET node must be added to the configuration before adding the lines, devices, and stations. Devices and
lines referenced in station configurations must be added before the station can be added. A controller station must
be added before stations that are tributaries of the controller station.

Line attributes

The attributes required for a line definition are PORT and PROTOCOL. In addition, if the protocol specified is the
X.25 protocol, one or more call options is required. You can define up to 4096 lines in each node.

The following is an example of a line definition using the X.25 line protocol. Naming conventions for lines are
described in XPNET components.

SET LINE PORT $AX10

SET LINE PROTOCOL X.25
SET LINE ETE NONE
SET LINE WFCALL ON
SET LINE DUPLEX FULL
SET LINE ATIMER 1
SET LINE VERDTE OFF
SET LINE UCRATE X25LINRATE
SET LINE UCSTATE X25LINSTATE
SET LINE UCQUEUE X25LINQUEUE
SET LINE CLASS GROUP1
ADD LINE \SYS1.P1A^NODE.L1A^X251

The following is a list of the attributes that can be defined for a line.

• ATIMER
• BTIMER
• CINIT
• CLASS
• CMETHOD
• CONTPOLL
• CONV
• CTLBIAS
• CUCHARS
• DATATIMEOUT
• DIAFTER
• DR
• DUPLEX
• ENQ
• ERANALYSIS
• ETE
• EXPDATA

151
• FLUSH
• FMM
• GIVETOKENS
• INPUT
• INTERFACE
• IOBIAS
• LAPPL
• LCLLUNAME
• LINEABNORMAL
• LINEAVAIL
• LINECONFIG
• LINEDEBUG
• LINEDIAG
• LINEINFO
• LINEOTHER
• LINESUPP
• LINETHRESHOLD
• LINEUNAVAIL
• MAPPED
• MCALL
• MICALL
• MODE
• NOCONNECT
• OBIAS
• ORIGINATE
• OSIMGR
• OUTPUT
• PARITY
• POLLINT
• PORT
• PROTOCOL
• PRTLUNAME
• PVC
• RAPPL
• RECALL

152
 • REMOTE
• RESPTIMEOUT
• RETRY
• RVILEVEL
• SENDCONFIRM
• SERVINTRVL
• SIMPLEXSEND
• SPEED
• SSL
• SYNCLEVEL
• TCPCONNTIMEOUT
• TCPLISTENPORT
• TIMEOUT
• TIMER
• TIMERINT
• TYPE
• UCQUEUE
• UCRATE
• UCSTATE
• UNCHARS
• VERDTE
• WFCALL

Device attributes

A basic device definition does not have any required attributes. However, some protocols have protocol-specific
attribute requirements, as indicated in the following table.

Protocol Literal Attributes

AM3270 INPUTFORMAT, OUTPUTFORMAT
CBIS INPUTFORMAT, OUTPUTFORMAT, POLLFORMAT, SELECTFORMAT
CBIT INPUTFORMAT, OUTPUTFORMAT, POLLFORMAT, SELECTFORMAT
CMPSB INPUTFORMAT, OUTPUTFORMAT, POLLFORMAT, SELECTFORMAT
CTS INPUTFORMAT, OUTPUTFORMAT, POLLFORMAT, SELECTFORMAT
Internal TCP/IP INPUTFORMAT, OUTPUTFORMAT, POLLFORMAT, SELECTFORMAT,
ILENADJUST, ILENLITTLEE, ILENOFLEN, ILENTYPE, OLENADJUST,
OLENLITTLEE, OLENOFLEN, OLENTYPE

153
Protocol Literal Attributes
SLU INPUTFORMAT, OUTPUTFORMAT
TR3271 INPUTFORMAT, OUTPUTFORMAT

You can also set predefined values for these attributes using the MACRO attribute.

Occasionally different protocol support is required for terminals dialing in on the same line and sharing station
definitions. Protocol string logic determines the correct protocol for a message based on message content.

Device object types can have an associated protocol table. The protocol table is used during a dial-in session to
determine which protocol to use for an incoming transaction. Up to seven match strings and corresponding protocols
can be named. The protocol identified in the table entry is used if the specified message string matches the
appropriate string in the message from the terminal. If no protocol string match is found, a default is used. For the
VISA protocols, the default is VISA1 procedures.

Protocol string matching is performed only on the first message received during a call. Once a protocol has been
determined for a call, that protocol remains in effect for the entire call, regardless of the contents of subsequent
messages.

To add an entry to the protocol table, you can use the ADD PROTOCOLSTRING attribute. If you want to change an
entry in an existing protocol table, you can use the ALTER PROTOCOLSTRING attribute. You can also delete an
entry by using the DELETE PROTOCOLSTRING attribute.

You can define up to 4096 devices in each node. The following is an example of a device definition that uses the
X.25 protocol. Naming conventions for devices are described in XPNET components.

SET DEVICE RECVLEN 4095

SET DEVICE XMITLEN 4095
SET DEVICE ADD DESTSTRING 1, P1A^DPROC, 2, %HA0
SET DEVICE ADD DESTSTRING 2, P1A^EPROC, 2, %HA1
SET DEVICE ADD PROTOCOLSTRING 1, ITI, 10, %HF1
SET DEVICE ADD PROTOCOLSTRING 2, ATALLA, 10, %HF2
SET DEVICE ADD PROTOCOLSTRING 3, DATAFONO, 10, "?"
ADD DEVICE \SYS1.P1A^NODE.D1A^X251

The following is a list of the attributes that can be defined for a device:

• ACLENGTH
• ALTPROFILE
• APPLID
• DEFRSP
• DESTROUTE
• DESTSTRING
• DR
• ILENADJUST
• ILENLITTLEE

154
 • ILENOFLEN
• ILENTYPE
• INPUTFORMAT
• MACRO
• NRSSCP
• OLENADJUST
• OLENLITTLEE
• OLENOFLEN
• OLENTYPE
• OUTPUTFORMAT
• POLLFORMAT
• PROFILE
• PROTOCOLSTRING
• RECVLEN
• RPCONF
• SELECTFORMAT
• SELECTION
• SSLCERTSFILE
• SSLROOTSFILE
• TRADDRESS
• TRLEN
• TTRANSPARENT
• TYPE
• WILDCHAR
• XMITLEN
• XNCONF

Station attributes

The required attributes for a station definition are DEVICENAME, LINENAME, and DESTINATION. In addition, the
SDLC XF Multipoint Supervisor protocol requires the PADRESS and SADRESS attributes.

If you are defining both controller stations and tributary stations, you must define the controller station before
defining the tributary stations of that controller station.

If you are using dynamically created stations, you must set the TEMPLATE attribute to ON, and define a name with
the PREFIXDSTS attribute. For this attribute to be turned ON, RADDR must be spaces otherwise, NCPCOM will
display an invalid error.

155
 When setting up the configuration for dynamic stations, the first letter of the PREFIX will be
NOTE
changed to "S" when adding a station and "L" when adding a line.

You can define up to 4096 stations in each node. The following is an example of a station definition that uses the
X.25 protocol. Naming conventions for stations are described in XPNET components.

SET STATION DEVICENAME \SYS1.P1A^NODE.D1A^X251

SET STATION LINENAME \SYS1.P1A^NODE.L1A^X251
SET STATION DESTINATION \SYS1.P1A^NODE.P1A^DPROC
SET STATION UCRATE X25STARATE
SET STATION UCSTATE X25STASTATE
SET STATION UCQUEUE X25STAQUEUE
SET STATION CLASS GROUP1
ADD STATION \SYS1.P1A^NODE.S1AX251

The following is a list of the attributes that can be defined for a station:

• ALTDEST
• APPLREJ
• AUTOPRI
• CLASS
• CONNSPEC
• DESTINATION
• DEVICENAME
• DR
• ENCRYPTTHENMAC
• ENDBRACKET
• ERRORACT
• FMMBROADCAST
• FMMPRIORITY
• FORMATVARS
• IAUDIT
• IBAUDIT
• IGNORECONNID
• INITDSTS
• INITSIM
• INTVALDSTS
• LADDR
• LARGEMSG
• LCLTPNAME

156
• LINENAME
• LOGICALACK
• MAXDSTS
• MODENAME
• MSGPRIORITY
• NOMOVERRIDE
• NOTIFYSERVICE
• OAUDIT
• OINTERVAL
• PADRESS
• PARTNERLINK
• PASSFMH
• PREFIXDSTS
• PRTTPNAME
• QAT
• QGCDEPTH
• QMI
• QMT
• RADDR
• REINSTATE
• RETRY
• ROUTETYPE
• RTS
• SADRESS
• SAVEDMSGS
• SBAENABLE
• SBRDISTGLOBAL
• SBRFORCELOCAL
• SEQVERIFY
• SERVICE
• SMT
• SOURCECLASS
• SSLALLOWMD5SIG
• SSLCIPHER3DES
• SSLCIPHERAES128

157
• SSLCIPHERAES256
• SSLCIPHERDES
• SSLCIPHERNULL
• SSLCLIENTAUTH
• SSLCLIHELLOPROVER
• SSLCLIMINPROVER
• SSLCONNTIMEOUT
• SSLCPRAES128GCM
• SSLCPRAES256GCM
• SSLDNMATCH
• SSLRFCINITNEGOT
• SSLRFCLEGACYCLI
• SSLRFCLEGACYSRV
• SSLSESSREUSE
• SSLSESSTIMEOUT
• SSLSRVMINPROVER
• SSQCNT
• STAABNORMAL
• STAAVAIL
• STACONFIG
• STADEBUG
• STADIAG
• STAINFO
• STAOTHER
• STASUSPENDED
• STATHRESHOLD
• STAUNAVAIL
• TCPDIALUP
• TCPINADDR
• TCPKEEPALIVE
• TCPLISTENLINE
• TCPRADDRINUDATA
• TCPZEROLENMSGS
• TEMPLATE
• TRIBUTARYOF

158
 • UCQUEUE
• UCRATE
• UCSTATE
• UPPHDRVSN
• USERDATA
• WARMPRI

Dest definitions
Dest objects identify entries in the node destination table to which messages can be routed within the network. Dest
objects can represent local processes and stations, external processes and stations (found on other nodes via links
to those nodes), and services. Thus, dest objects will have identical symbolic names as processes, stations, and
services configured in the network.

Adding dest objects to a network configuration is optional, but does allow for additional configuration of destination
table entries when necessary. The configuration for dest objects becomes a static part of the network configuration
until they are altered or deleted. CONTROL, INFO, STATUS, and STATISTICS commands for the dest object will
provide control and inquiry abilities for destination table entries with or without the corresponding dest object being
added to the network configuration.

The definition for a dest must include at a minimum the symbolic name of the dest, which will be identical to the
symbolic name of the destination table entry it represents. Optionally, the dest declaration can include the following
information:

• Whether the dest is part of a user-defined class. This is set using the CLASS attribute.
• Queue alert and network overload management thresholds which override the node defaults for unknown
destinations and unavailable services. These are set using the QAT, QMI, and QMT attributes.
• A queue counter used for monitoring queueing at the destination. This is set using the UCQUEUE attribute.
• Whether the dest is only to be found on other nodes, which link to look across for the dest and whether or not
one or more links may be valid. These settings are made using the EXTDEST, EXTLINK, and
EXTCONTINGENCY attributes.
• If adaptive routing is required, this can be set using the ADAPT attribute.
• The ability to make the network fail back all non-SAF messages sent to the destination can be set using the
FAILURE attribute.
• The ability to make the network freeze the destination so that messages queue to it and are not processed can
be set using the FREEZE attribute.

A sample dest declaration is:

RESET DEST
SET DEST CLASS AUTH1
SET DEST QAT 80
SET DEST QMI 85
SET DEST QMT 20
SET DEST UCQUEUE AUTHSRVQ
ADD DEST \SYS1.P1A^[Link]

159
The NODE object for this node (P1A^NODE) must be added to the configuration before adding the dest.

Dest attributes

The following is a list of the attributes that can be defined for a dest:

• ADAPT
• ALIAS
• CLASS
• DR
• EXTCONTINGENCY
• EXTDEST
• EXTLINK
• FAILURE
• FREEZE
• QAT
• QGCDEPTH
• QMI
• QMT
• REPLACEALIAS
• RTS
• UCQUEUE

Making changes to the configuration

You can use the ALTER command to change the values of the attributes for existing dest, device, line, link, node,
process, and station objects. For example, to change the priority for a process named P1A^PROC2, you could enter
the following ALTER PROCESS command:

ALTER PROCESS \SYS1.P1A^NODE.P1A^PROC2, PRIORITY 140

As another example, to change event type filtering so that abnormal event messages are generated for all object
types on P1A^NODE, you could enter the following ALTER NODE command:

ALTER NODE \SYS1.P1A^NODE, EVT^ABNORMAL ON

You can also use wildcard characters to specify the objects for which you want to change the attribute values. For
example, to change the startup logic for all links on a particular XPNET node, you could enter the following ALTER
LINK command:

160
 ALTER LINK *, STARTUP AUTOMATIC, UNDER NODE P1A^NODE

Note that many station and line attributes can be changed only when the station or line is in a Stopped state. Some
station and line attributes are applicable only to specific line protocols.

If you are a system manager and are making changes to the system (for example, if you are trying to solve a system
problem), you probably do not want other users making changes to the configuration at the same time. You can
manually lock the configuration, make your changes, and then manually unlock the configuration. The CONTROL
NODE command with the LOCK and the UNLOCK directives enable you to do this. These directives include a key
variable that identifies you to the NCPCOM utility. This key variable can be any user-defined identifier up to eight
alphanumeric characters. The key variable is case sensitive and must be enclosed by delimiters. You can use
double quotation marks ("), single quotation marks ('), forward slashes (/), square brackets ([]), angle brackets (<>),
or parentheses ( () ). The following are examples of these two commands:

CONTROL NODE P1A^NODE, LOCK "Problem"

CONTROL NODE P1A^NODE, UNLOCK "Problem"

When you execute the CONTROL NODE command with the LOCK directive, the NCPCOM utility holds the value of
the key variable in memory. When you execute object management commands during this NCPCOM session, this
identifier is sent with the command and the XPNET process knows that it can process the command. If any other
user (during a concurrent NCPCOM session) attempts to issue an ADD, ALTER, DELETE, ENABLE, or DISABLE
command or a CONTROL NODE command with the COMMIT or ROLLBACK directive, this identifier is not sent with
the command. The XPNET process rejects the command. Other users can execute commands other than those
specified above even when the configuration is locked.

The CONTROL NODE command with the UNLOCK directive and the same key variable that was sent with the
LOCK directive tells the XPNET process that it can now accept the specified object management commands from all
users. You can issue the CONTROL NODE command with the UNLOCK directive from any NCPCOM session.

If an emergency situation occurs while the configuration is locked and a CONTROL NODE command with the
UNLOCK directive cannot be executed, you can use the following command to remove the lock.

CONTROL NODE P1A^NODE, DELETELOCK

NOTE This command should be secured so only the Super ID user has access to it.

Moving objects from one XPNET node to another

Occasionally you may want to move one or more objects from one XPNET node to another XPNET node. For
example, you may need to balance your configuration because the rate of messages through objects on one node
has grown disproportionately to the rate of messages through objects on another node. To balance the throughput, it
is necessary to reconfigure the system such that some of the busy objects are relocated to the quieter node. This
can be achieved in several ways using a combination of ADD, DELETE, ENABLE, DISABLE, and other commands.
If the reconfiguration is to be undertaken while transactions are in progress, the steps involved become more
complex to ensure that responses are correctly returned to the originating objects. One such method is described
below, but you must carefully consider the issues involved in your particular situation.

161
You can achieve a reconfiguration without system or even object downtime by using duplicate symbolic names and
adaptive routing. For example, you might want to move a process, PROCX, from a node named P1B^NODE to a
node named P1A^NODE. In this example, messages originating from PROCX are routed to destinations on both
nodes, and replies to these messages are returned to PROCX, which is holding some context that requires the
response. The link from P1A^NODE to P1B^NODE is named P1ALINKP1B, and the link from P1B^NODE to
P1A^NODE is called P1BLINKP1A.

Prior to the reconfiguration, all replies sent by objects on P1A^NODE with a destination of PROCX are routed to the
link connecting P1A^NODE with P1B^NODE. You can verify this using the following command:

STATUS DEST P1A^[Link], detail

The results of this command show PROCX as an external destination with P1A^LINK^P1B as the link to which
messages for this destination are routed. All messages received on P1B^NODE with a destination of PROCX are
sent directly to the local process. You can verify this using the following command:

STATUS DEST P1A^[Link], detail

The results of this command list the destination as a local process with no associated link.

Before using either of these procedures, carefully research the application in question to ensure that the message
header contains the source of the message. In addition, you should test these procedures thoroughly before trying
this in a production environment.

To move PROCX from node P1B^NODE to node P1A^NODE on HP NonStop system \SYS, perform the following
steps:

1. If a dest object does not already exist for PROCX in the configuration for node P1A^NODE, add the dest object
using the following commands:

RESET DEST
ADD DEST \SYS.P1A^[Link]

If necessary, use the following command to refresh the dest into the destination table (this will not be necessary
if a STATUS DEST PROCX command returns status information on this destination):

CONTROL DEST PROCX, DESTREFRESH

2. Turn on adaptive routing for PROCX on P1A^NODE using the following command:

ALTER DEST P1A^[Link], ADAPT ON

This command ensures replies are correctly routed to the old PROCX process on node P1B^NODE during the
transition.

162
 When the next message is received on P1A^NODE from PROCX on P1B^NODE, an adapted entry,
PROCX!!!!!!!!!!!, will be added to the destination table for P1A^NODE. This can be verified using the following
command:

STATUS DEST P1A^[Link]*

The results of this command show at least two entries: one for PROCX and one for the adapted entry
PROCX!!!!!!!!!!! (as well as any other entries that match the wildcard pattern).

Leave the configuration in this state until all messages previously sent from P1B^[Link] to destinations
on P1A^NODE have been replied to. (A few minutes should be ample time in an online environment.)

If the destination application replies to the source of the message from the message header, then, as messages
arrive with the adapted source name, the replies will be sent to PROCX!!!!!!!!!!! rather than PROCX.

3. Add and start the new P1A^[Link] process.

This causes the PROCX entry in the destination table of P1A^NODE to be updated. You can verify this using the
following command:

STATUS DEST P1A^[Link]

The results of this command show PROCX as a local process instead of an external process. Replies to
P1B^[Link] are still successfully delivered as they are being routed to PROCX!!!!!!!!!!!.

If the source information in the message header is used for sending replies, then during this transition period
while there are two operational PROCX processes, both the new and old PROCX processes can be sending
messages out to processes on both nodes and both will receive the appropriate replies.

P1A^[Link] sends messages to local processes with a source of PROCX, replies will be sent to
PROCX, and the replies are routed to the local PROCX process.

P1B^[Link] sends messages to P1A^NODE processes with a source of PROCX!!!!!!!!!!!, replies are
sent to PROCX!!!!!!!!!!! and routed to the P1ALINKP1B link and back to P1B^[Link].

P1B^[Link] sends messages to local processes on node PIB^NODE with a source of PROCX, replies
are sent to PROCX and routed to the local PROCX process.

If P1A^[Link] sends messages to P1B^NODE processes, an adapted source name of PROCX!!!!!!!!!!!

on P1B^NODE is automatically generated, replies are sent to PROCX!!!!!!!!!!! and routed to the P1BLINKP1A link
and back to P1A^[Link].

4. Stop and delete P1B^[Link].

5. Delete the adapted name destinations from the routing table on both nodes, using the following command:

CONTROL DEST *.PROCX!!!!!!!!!!!, DELETE

163
 6. If desired, you can delete the PROCX dest object from P1A^NODE using the following command:

DELETE DEST P1A^[Link]

If the PROCX dest object is not deleted, the ADAPT attribute can be turned off as necessary.

ALTER DEST P1A^[Link], ADAPT OFF

If the object to be moved is a destination rather than a source of messages, the procedure is simpler. Consider
the following scenario using the previous example.

7. Prior to the reconfiguration, all messages received on P1A^NODE with a destination of PROCX are sent to the
link connecting P1A^NODE with P1B^NODE, and all messages received on P1B^NODE with a destination of
PROCX are sent directly to the local process. You can verify this using the following command to see that node
P1A^NODE understands PROCX to be external, while node P1B^NODE identifies PROCX as a local process:

STATUS DEST *.PROCX

In this case, perform steps 8-12.

8. If a dest object does not already for PROCX in the configuration for node P1A^NODE, add the dest object using
the following commands:

RESET DEST
ADD DEST \SYS.P1A^[Link]

If necessary, refresh the dest into the destination table (this will not be necessary if a STATUS DEST PROCX
command returns status information on this destination):

CONTROL DEST PROCX, DESTREFRESH

9. Turn on adaptive routing for the PROCX destination on P1A^NODE using the following command:

ALTER DEST P1A^[Link], ADAPT ON

In this case, no messages will actually use adaptive routing, but this is required to enable a new instance of
PROCX to be added.

10. Add and start the new PROCX process on P1A^NODE. The PROCX destination table entry on P1A^NODE is
updated to point to the local PROCX process and messages are routed accordingly.
11. Stop and delete the PROCX process on P1B^NODE.

164
 For any existing messages or the first new message, an unknown destination of PROCX is created on
P1B^NODE, and inquiry messages are sent across started links to find the destination. A response is received
from P1A^NODE and the PROCX destination table entry is updated to point to P1B^LINK^P1A. All messages
routed to PROCX from P1B^NODE are now routed to P1A^[Link].

12. If desired, you can delete the PROCX dest object from P1A^NODE using the following command:

DELETE DEST P1A^[Link]

If the PROCX dest object is not deleted, the ADAPT attribute can be turned off as necessary.

ALTER DEST P1A^[Link], ADAPT OFF

Deleting objects from an XPNET system

The DELETE command removes objects from the configuration database. Node, link, line, station, and process
objects to be deleted must be in the Stopped or Disabled state. For example, the following commands stop and then
delete a process named P2C^CPROC1:

STOP PROCESS \SYS1.P2C^NODE.P2C^CPROC1

DELETE PROCESS \SYS1.P2C^NODE.P2C^CPROC1

When you execute this DELETE command from the NCPCOM utility, the following prompt is displayed to request
confirmation of the command:

Delete \SYS1.P2C^NODE.P2C^CPROC1 (y[es]/n[o]/l[istobjects])?

If you respond Y (yes), the NCPI Server process verifies that the object exists in the NEF and then sends the
command to the XPNET process, which determines if the object can be deleted. If it can be deleted, the object is
removed from the NEF and the internal tables, and an event message is generated.

If you respond N (no), the command is terminated and the NCPCOM prompt is displayed.

If you respond L (listobjects), a list of the objects that meet the command criteria is displayed and then the
confirmation prompt shown above is displayed again.

To ensure that you delete the desired object, you should fully qualify the symbolic name of the object even though
you can use wildcard characters for all object types except the NODE object type. You can fully qualify a symbolic
name by explicitly entering the HP NonStop system name and the XPNET node name, by using the UNDER
SYSNAME and UNDER NODE filters, or by specifying the HP NonStop system name and XPNET node name with
the ASSUME command.

The object being deleted cannot be referenced by other objects or the command fails. For example, you cannot
delete a line referenced in a station definition until the station has been stopped and then deleted. The following
example stops an X.25 station and line and then deletes the station, device, and line. Before you attempt to delete

165
the device, you should check that it is not referenced in another station definition.

STOP STATION \SYS1.P1A^NODE.S1AX251

STOP LINE \SYS1.P1A^NODE.L1A^X251
DELETE STATION \SYS1.P1A^NODE.S1AX251
DELETE DEVICE \SYS1.P1A^NODE.D1A^X251
DELETE LINE \SYS1.P1A^NODE.L1A^X251

If you attempt to delete an object referenced by another object, the error message you receive indicates that the
object you are trying to delete is currently in use. For example, if you try to delete a line referenced in a station
definition before you delete the station, the error message indicates that the line is in use.

To execute a DELETE NODE command, you must fully qualify the symbolic name of the node. That is, the command
must include the HP NonStop system name, and it cannot contain wildcard characters. In addition, you must stop
and delete any objects configured under that node before you can delete the node.

For example, the following series of commands stops and deletes the station, device, line, link, and process objects
configured under the node named P1A^NODE and then stops and deletes the node itself.

ASSUME SYSNAME \SYS1

ASSUME NODE P1A^NODE
STOP STATION S1AX251
STOP LINE L1A^X251
STOP LINK P1A^LINK^P1B
ABORT PROCESS P1A^APROC1
DELETE STATION S1AX251
DELETE DEVICE D1A^X251
DELETE LINE L1A^X251
DELETE LINK P1A^LINK^P1B
DELETE PROCESS P1A^APROC1
STOP NODE
STOP NODE
DELETE NODE P1A^NODE

Note the use of the ABORT PROCESS command rather than the STOP PROCESS command. If the STARTUP
attribute for the process is set to AUTOMATIC, the XPNET process automatically restarts the process after a STOP
PROCESS command is issued. To prevent the process from being restarted, you should stop the process with the
ABORT PROCESS command.

When you execute the STOP NODE command, you are asked to confirm the command. When you enter the STOP
NODE command again, the node is stopped.

When you execute the DELETE NODE command, the system displays the following prompt to request confirmation
of the command:

Delete of an XPNET Node cannot be recovered via CONTROL,ROLLBACK !

Continue Delete \SYS1.P1A^NODE (y[es]/n[o])?

Note the first line of this prompt. When you issue a DELETE NODE command, the XPNET process deletes the
records for that node from the NEF, which leaves the NEF empty, and the NCPI Server process deletes the record

166
for that node from the NMAP. Therefore, it is not possible to roll back to a previous point in the configuration. For
information about rolling back changes to the configuration, see Managing the configuration.

Generating a command file for the current configuration

You can use the INFO command with the OBEYFORM modifier to generate a command file that reflects the current
configuration (excluding attributes that currently have default values). The command file contains a set of NCPCOM
commands. You can specify that the generated command file be displayed to the terminal or that it be written to a
disk file. If you specify that it be written to a file, you can then edit the listed commands, use the file as input to the
NCPCOM utility, and generate the specified objects. You can generate the command file for a specific object, for a
specific group of objects, or for all objects in a node.

The suggested naming convention for the generated command file for all objects in a node is NxxCONF, where xx is
the node ID. This node ID is a one- or two-character node identifier that is generally assigned sequentially using
letters or numbers or a combination of both letters and numbers.

For example, the following series of commands generates a command file for the current configuration for all objects
in a node named P1A^NODE, and specifies that the output be written to a file named N1ACONF.

INFO /OUT N1ACONF/ NODE P1A^NODE, OBEYFORM

INFO /OUT N1ACONF/ PROCESS *, UNDER NODE P1A^NODE, OBEYFORM
INFO /OUT N1ACONF/ LINK *, UNDER NODE P1A^NODE, OBEYFORM
INFO /OUT N1ACONF/ DEVICE *, UNDER NODE P1A^NODE, OBEYFORM
INFO /OUT N1ACONF/ LINE *, UNDER NODE P1A^NODE, OBEYFORM
INFO /OUT N1ACONF/ STATION *, UNDER NODE P1A^NODE, OBEYFORM, CONTROLLER
INFO /OUT N1ACONF/ STATION *, UNDER NODE P1A^NODE, OBEYFORM, TRIBUTARY
INFO /OUT N1ACONF/ DEST *, UNDER NODE P1A^NODE, OBEYFORM, ADDED

If your system contains both controller and tributary stations and you plan to use the output file to recreate an
XPNET node, the sequence of the INFO STATION commands is important. Because a controller station must be
defined to the XPNET node before stations that are tributaries of the controller station, the first INFO STATION
command must include the CONTROLLER filter, and the second INFO STATION command must include the
TRIBUTARY filter.

An example of OBEYFORM output for a process named P1A^APROC1 is displayed below:

RESET PROCESS
SET PROCESS BCPU 3
SET PROCESS LIBRARY $[Link].NLIB00
SET PROCESS PROGRAM $[Link]
SET PROCESS PPD $AP01
SET PROCESS PRIORITY 165
SET PROCESS CPU 3
SET PROCESS DEFINES ON
SET PROCESS SAVEABEND OFF
ADD PROCESS P1A^APROC1, UNDER SYSNAME \SYS1, UNDER NODE P1A^NODE

167
 ACI provides an edit file named NEFLIST that is located on the XPNET subvolume and contains
the commands required to create a command file for all objects on a particular node. You will need
NOTE
to edit the file to include the appropriate node name. A listing of the NEFLIST file is in Examples of
XPNET obey files.

Managing the configuration

The XPNET process can maintain a configuration journal for each XPNET node. This journal contains information
about any changes made to the configuration of objects on the XPNET node and can be used for internal auditing.
All ADD, ALTER, DELETE, ENABLE, and DISABLE commands are recorded in this journal.

You can also use this journal to mark a point at which you know the configuration is stable. You can then make
changes to the configuration (for example, adding or deleting XPNET objects, changing object attributes, and so on).
If, for some reason, you need to roll back these changes, you can revert to the marked stable configuration. The
CONTROL NODE command with the COMMIT directive writes a record in the configuration journal marking a stable
point in the configuration. The CONTROL NODE command with the ROLLBACK directive rolls back the changes
made after the specified point.

Marking a stable configuration

The COMMIT directive includes a tag variable that can be any user-defined identifier up to eight alphanumeric
characters. For example, the tag identifier could be a version name or number, a date, the name of a project, or
anything meaningful to you. This commit tag is also used with the ROLLBACK directive to specify which
configuration point to roll back to. The tag variable must be enclosed by delimiters. You can use double quotation
marks ("), single quotation marks ('), forward slashes (/), square brackets ([]), angle brackets (<>), or parentheses (
() ).

The following shows an example of the CONTROL NODE command with the COMMIT directive, where the tag
variable is a combination of a date and a version number.

CONTROL NODE \SYS1.P1A^NODE, COMMIT "9711VER1"

Typically, this command is issued once you have determined that the configuration is stable and the system is
working as desired. You can mark as many configuration points as necessary.

For example, you know that you are going to make several sets of changes in the near future. You used the
command shown above to mark the initial stable configuration; you then make and test one group of changes. Once
you determine that the changes you made are working as desired, you could use the following command to mark
another point at which the configuration is stable.

CONTROL NODE \SYS1.P1A^NODE, COMMIT [9801VER2]

These two commands in essence isolate the group of changes that you made. You can repeat these steps as many
times as desired.

The commit tag is an alternate key into the configuration journal file. You will need to keep track of the commit tags
because rolling back the changes requires the same tag identifier.

168
Rolling back changes
After changes to an XPNET configuration have been tested or have operated for some time, it may be required to
revert to an earlier point in the configuration. You can accomplish this online with the CONTROL NODE command
with the ROLLBACK directive. The ROLLBACK directive includes a tag variable that is either a commit tag that
identifies a previous configuration point or a date in YYYYMMDDhhmm format, even if this date was not used as a
commit tag. If you use the name of a commit tag, delimiters are required.

For example, the following command rolls back the configuration to the marked configuration point described in the
second example in the previous subsection.

CONTROL NODE \SYS1.P1A^NODE, ROLLBACK (9801VER2)

This command rolls back all changes made after the configuration point identified by the CONTROL NODE
command with the COMMIT directive and the specified commit tag.

If you use the date format in the tag variable, specifying the hour and minute (hhmm) is optional. If you omit the hour
and minute, zero seconds after midnight is assumed. All changes made after the time specified are rolled back.

Since a ROLLBACK command implicitly aborts the objects that it affects, you should perform this command on a
quiet system or stop all objects that it will impact before executing the command.

You can use the ROLLBACK command on only one node at a time; you cannot use wildcards.

As the DELETE NODE command deletes all configuration data from the NEF for that node, it is not
NOTE possible to roll back a node after deleting it. In addition, an ADD NODE command cannot be rolled
back.

You can revert to any previous configuration point. For example, if you need to roll the configuration back to the point
before the first group of changes were made, you would enter the following command rather than the command
shown above.

CONTROL NODE \SYS1.P1A^NODE, ROLLBACK <9711VER1>

When you execute a CONTROL NODE command with the ROLLBACK directive, the XPNET process locks the
configuration to prevent other users from making changes to the configuration while the rollback is in progress. That
is, other users are prevented from issuing ADD, ALTER, DELETE, ENABLE, and DISABLE commands, as well as
the CONTROL NODE command with the COMMIT or ROLLBACK directive. However, other users can execute other
commands (such as inquiry, stop, or start commands) that do not change the configuration.

The XPNET process then generates an obey file that contains the opposite commands to the ones that generated
the changes in the first place. For example, if one of the commands issued after the marked configuration point was
an ADD PROCESS command, the XPNET process generates a DELETE PROCESS command.

The following prompt is then displayed:

169
 Rollback file filename created
containing num commands.
Do you wish to proceed? y[es] n[o]

You can review this obey file from another TACL session before answering this prompt.

If you respond to the prompt by entering the letter Y, the system processes the commands in the obey file (which
rolls back the changes), and then unlocks the configuration so that changes can once again be made.

NOTE This obey file is named ROLLBACK and is automatically deleted after the rollback occurs.

Managing the configuration journal

The XPNET process maintains the configuration journal in the volumes and subvolumes specified by the CJA, CJB,
and CJC attributes. The CJ attribute specifies whether the XPNET process writes configuration change information
to the configuration journal. For the XPNET process to write to the configuration journal, the CJ attribute must be set
to ON and a location specified for at least one of the CJA, CJB, or CJC attributes.

The XPNET process attempts to create a file in the volume and subvolume specified by the CJA attribute. If this
fails, the XPNET process generates an event message and attempts to create a file in the volume and subvolume
specified by the CJB attribute and then the CJC attribute, if necessary. You can name separate disk volumes for the
second or third volume location to accommodate situations when you may not have enough disk capacity. See The
configuration journal subvolumes for information on naming conventions for these subvolumes.

The XPNET process assigns a file name of CJnnnnn, where nnnnn represents a number from 00000 through 99999.
If the file already exists but does not contain data, the XPNET process uses the existing file. If the file already exists
and contains data, the file name is incremented by one until an available file name is found. If all possible iterations
of the file name in one volume and subvolume are unsuccessful, the XPNET process attempts to go through the
same file name iteration in the remaining volumes and subvolumes.

Each configuration journal file is associated with an alternate key file. Records of CONTROL NODE commands with
the COMMIT directive are the only records in the alternate key files. Therefore, the alternate key files are generally
much smaller than the configuration journal files (or even empty).

The CONTROL NODE command with the SWCJ directive closes the current configuration journal file and creates a
new file in the same volume and subvolume. The configuration journal files remain on disk indefinitely and can be
archived to tape.

The configuration journal is not required if rollback functionality is not required. If you set the CJ attribute to OFF and
do not set the CJA, CJB, and CJC attributes, the XPNET process does not write to a journal file. However, if you
plan to use rollback functionality, the configuration journal must have been in use from the present time back to the
marked configuration point or time that you want to roll back to. You cannot open the configuration journal only when
you want to make configuration changes and then close it after the changes are made.

You can generate a report from the configuration journal using the NETCJRD utility. This utility is described in Utility
programs.

170
Managing a contingency configuration
A contingency configuration can be defined by configuring duplicate objects (using the same symbolic names) in
multiple XPNET nodes.

The fully qualified name of an XPNET node consists of the name of the HP NonStop system on which it runs and the
symbolic name of that XPNET node (for example, \SYS1.P1A^NODE). Therefore, you can configure multiple
XPNET nodes with the same symbolic name as long as they are on different HP NonStop systems (for example,
\SYS1.P1A^NODE and \SYS2.P1A^NODE).

The fully qualified name of an object managed by the XPNET process consists of the fully qualified name of the
XPNET node on which the object runs and the symbolic name of the object itself (for example, \SYS1.P1A
NODE.P1A
APROC1). Therefore, you can configure multiple instances of an object as long as they are on different HP
NonStop systems or different XPNET nodes. For example, you could configure multiple instances of P1A^APROC1
as follows: \SYS1.P1A^NODE.P1A^APROC1, \SYS1.P1B^NODE.P1A^APROC1, and
\SYS2.P1A^NODE.P1A^APROC1.

Two configuration states assist in the management of a contingency configuration: the Enabled state and the
Disabled state. An object in the Enabled configuration state can be started and stopped and is available for
processing. An object in the Disabled state is essentially invisible and cannot be started until it has been changed to
the Enabled configuration state using the ENABLE command.

There are two ways to create a contingency configuration:

• You can create a dedicated, backup copy of an XPNET node that contains the duplicate objects in a Disabled
state.
• You can distribute the duplicate objects across other XPNET nodes (rather than dedicating a backup XPNET
node). These duplicate objects can be configured in the Disabled state.

Because newly added objects, by default, immediately transition from the Disabled state to the Stopped state, you
must specify the Disabled state in the ADD command or use the SET ADDTYPE DISABLED command before
configuring the contingency objects.

When the contingency objects (currently in the Disabled state) need to be started, you can issue the following
ENABLE and START NODE commands. Note that the ENABLE NODE command must be executed before enabling
the other objects, and that enabling the line enables all the stations associated with that line.

ENABLE NODE \SYS1.P1B^NODE, DISABLED

ENABLE PROCESS \SYS1.P1B^NODE.P1A^PRO1, DISABLED
ENABLE LINK \SYS1.P1B^NODE.P1B^LINK^P1A, DISABLED
ENABLE LINE \SYS1.P1B^NODE.L2B^VISA, DISABLED
START NODE \SYS1.P1B^NODE

The START NODE command starts the XPNET process and any application processes and links that have a startup
logic of AUTOMATIC. You would then have to enter START commands for any lines and stations that you want to
start as well as any application processes and links that do not have a startup logic of AUTOMATIC. Note that you
can use these ENABLE and START commands in an obey file from a network control facility.

Alternatively, the contingency objects can be enabled and in the Started state all the time. When an object is added,
a request is broadcast in an attempt to determine if the object being added is a duplicate of an existing symbolic

171
name. If the object is a duplicate, or if it is not possible to determine whether or not the object is a duplicate, a
warning is generated but the ADD command succeeds.

In order for routing to work correctly when duplicate objects have been configured, the XPNET process needs to
identify when it has received a message from a duplicate object or is routing a message to a duplicate object. When
this occurs, the XPNET process applies adaptive routing algorithms to guarantee that messages are routed
correctly. Adaptive routing is described in Aspects of network control.

Configuring disaster recovery

A clone satellite process module (DRPRO) supports the DR (disaster recovery) replication functionality to
automatically replicate network environment file (NEF) changes to a DR site. This keeps the primary NEF and DR
NEF in sync where needed to allow for a more seamless failover and recovery in the event of an outage and
restoration of the two systems.

The primary and DR nodes communicate with each other and keep ONCF changes in sync. This is configurable so
that not all attributes/changes need to be replicated. The configuration also allows the ability to do some
customizations (modify requests for site-specific data if needed).

The configuration for this process is automatically added to the NEF for each NODE when the N24SETUP macro is
run to create the initial XPNET system. It is added as a COMMAND process so that it is not started unless the
customer wants to enable and use the DR replication feature. If this is the case, the STARTUP must be changed to
CLONE, for example:

ALTER PROCESS P1A^DRPRO, STARTUP CLONE

A clone process is the same as AUTOMATIC except it runs in the same CPU as the XPNET node primary PID so it
can share its extended memory segment (read only) to access configuration and status information

A number of attributes need to be set to enable the DR process. See the Network Control Command Reference for
additional information on these attributes.

NODE:

• REPLICATION ON/OFF
• DR ON/OFF

LINK:

• DR ON/OFF

DEVICE:

• DR ON/OFF

STATION:

• DR ON/OFF

LINE:

172
 • DR ON/OFF

DEST:

• DR ON/OFF

PROCESS: ( NON DR PROCESS )

• DR ON/OFF

DR PROCESS:

• DR ON/OFF
• NCSPFILE <$[Link]> ($)
• PROFILE <profile name>
• DRSAFPRI <$[Link]>
• DRSAFBACK <$[Link]>
• DRSAFPAGES <pages>
• DRPPD <\sys.$drppd>

Once the above attributes have been configured as desired, you will need to configure which attributes you want to
be replicated in the PROFILE in the above NCSP. For example, if the two systems are not mirroring each other, you
may not want to replicate certain fields like STATION LADDR / RADDR.

You would configure “R” ( replicate ) for any attributes you want to be replicated to the other system. This will apply
to every STATION that has DR ON set. This applies to all ALTER <attribute> for all object types as well also ADD,
DELETE, ENABLE, DISABLE (if enabled in the NCSP). You need to SET <object type> DR ON when adding the
object for it to get replicated. See Network control security profile file for additional information.

This will need to be done on both the primary and DR site if you want replication both ways.

From NCPCOM:

• ALTER STATION <station>, DR ON for all stations you want replicated

• ALTER PROCESS <process>, DR ON for all processes you want replicated
• ALTER LINE <line>, DR ON for all lines you want replicated
• ALTER LINK <link>, DR ON for all links you want replicated
• ALTER DEST <dest>, DR ON for all added DESTS you want replicated
• ALTER DEVICE <device>, DR ON for all devices you want replicated
• ALTER NODE <node>, DR ON for if you want NODE attributes to be replicated
• ALTER NODE <node>, REPLICATION ON ( enabled replication on this node )
• ALTER PROCESS DR^PROCESS, STARTUP CLONE
• ALTER PROCESS DR^PROCESS, DRPRO DRPPD \DR.$DRPPD for primary node
• ALTER PROCESS DR^PROCESS, DRPRO PPD \PROD.$DRPPD for DR node

173
The NET24SETUP macro will configure DR PROCESS with the NCSPFILE, PROFILE, DRSAFPRI, DRSAFBACK,
DRSAFPAGES with default values. If you want to modify these or you are adding the DR Process manually, you will
need to ALTER/SET these values as well.

The symbolic names of the objects must be the same on both the primary and DR XPNET nodes for the command
to be replicated. There is a user hook ( see details later ) available in the DR CLONE Process to allow for system
specific modifications if needed (for example, you could modify symbolic names / values in the ONCF request before
it is sent to the DR site).

For example:

S1A^STA^01 has DR ON

• ALTER STATION S1A^STA^01, FMMPRIORITY 190 would get replicated

• ALTER STATION S1A^STA^01, LADDR [Link] would not get replicated

S1A^STA^02 has DR OFF

• ALTER STATION S1A^STA^02, FMMPRIORITY 190 would not get replicated

• ALTER STATION S1A^STA^02, LADDR [Link] would not get replicated

The two partner DR CLONE processes will open each other over expand. Whenever a ONCF command is executed
by the XPNET Node, if REPLICATION is ON, then is DR ON for the specific object, then the command is copied and
sent to the local DR CLONE process. The DR CLONE will read the command, check the NCSP to see if the
command should be replicated. If the access flag for this command = “R” then the command request is sent to the
remote DR clone process. The remote DR clone process reads the command and sends it to the remote DR XPNET
Node (just as if an NCPCOM had been executed on the remote system). The remote XPNET identifies this as DR
request, processes and responds to its clone process. The remote clone process then responds to its partner DR
CLONE process to indicate it succeeded. This is then logged to the LOG<nnnnn> file on the DRSAFPRI subvol (or
DRSAFBACK if there was an error). An event is logged to indicate what the command was and that it succeeded. If
it failed for some reason, then the response is written into the ERR<nnnnnn> file on the DRSAFPRI (or
DRSAFBACK) subvol and the error with response code details are written to the EMS log.

If for some reason, the local clone cannot open/communicate with the remote clone process, then all commands are
written into the SAF<nnnnn> file (starts at SAF00000 and increments by 1 as needed) on the DRSAFPRI and
DRSAFBACK subvols (so SAF processing can continue if the DRPRISAF subvol/files can not be accessed for some
reason). It also updates a SAFCNTL file on both subvols the keep track of the current SAF file, the address of the
last added record and the address of the last sent message ( when communication is re-established with the remote
DR clone process). This is done in case the DR clone stops and restarts for some reason. It opens the SAFCNTL file
and determines if there are still SAF’d messages that need to be sent. Opens the appropriate SAF file and continues
sending commands to the DR site. New commands are written to the end of the SAF file until all the commands are
executed, so they remain in order. If there are multiple SAF files, they are purged once all the commands have been
sent to the DR site.

174
Chapter 6. Utility programs
ACI provides utilities to assist in the operation of the XPNET system. These utilities are executed through TACL.

LIVERIFY utility
A license verification utility is present on the XPNET subvolume to allow users to verify a license before loading it
into a running system. This utility has the filename LIVERIFY. LIVERIFY can be run from the XPNET subvolume
without any parameters and searches for the most recent license file in the same manner as XPNET searches.
When it finds the most recent file, it opens it and reads it in the same manner as XPNET reads the license file.
LIVERIFY provides detailed output including the following:

• The name of the license file

• The customer for whom the license was created
• The HP NonStop systems for which the license is valid
• A list of XPNET-related product IDs for which the customer is licensed
• The expiration date of the license (including the number of days left until expiration)
• A final indication of whether the license is valid on the system where LIVERIFY is being run

In order to verify licenses that are not located on the XPNET subvolume, move to the subvolume where the license
file is located and run the LIVERIFY utility, specifying the path to the XPNET subvolume where the utility is located. If
a license file other than the most recent LIyymmdd license is to be verified, add an _ACI_LICENSE_FILE assign for
that license before running the LIVERIFY utility. The GOLIVERI license verification obey file on the XPNET
subvolume is provided to allow users to easily verify licenses with nonstandard names.

Syntax
[ RUN ] [ location ] LIVERIFY [ / OUT file-name / ]

RUN — An optional keyword for the RUN command. If this keyword is included in the command and you are not
starting the utility from the subvolume in which it is located, the location variable must also be included in the
command. If this keyword is not included in the command, the LIVERIFY utility must be located on a volume and
subvolume that is in the PMSEARCH list at your site.

location — Specifies the volume and subvolume on which the LIVERIFY utility is located. This variable is required if
the location of the LIVERIFY utility is not included in the PMSEARCH list at your site and you are starting the utility
from a location other than the subvolume in which the utility is located.

OUT file-name — Designates a location to receive the output of the utility. This location can be a spooler location or
a disk file. If this parameter is omitted, the output displays on your home terminal.

NETADRD and NETADRT utilities

The net audit read utilities are used to create various types of output from an audit or network overload management
file. You can create an audit report, which is a listing of an audit or network overload management file that can be
used for analyzing captured messages.

175
You can also specify that the NETADRD utility create a disk file in QWRITE format that contains designated
messages from the audit or network overload management file. These messages in QWRITE format can then be
reintroduced to the XPNET system using the CONTROL NODE command with the QREAD directive.

The NETADRT utility is similar to NETADRD; however it uses TCP/IP as input instead of a disk file. In addition, it can
support TLS to protect the streaming transaction data. These two features add additional security protections for
sensitive trace data.

The flow of the NETADRD utility is shown below, for both the internal audit process and the external audit process.
The following section contains a description of this utility and the type of information generated.

The NETDMPRD utility produces a report that contains a count of the number of messages written to the audit files.
You can specify that the report be written to a spooler location or the terminal.

NETADRD flow with internal audit process

NETADRD flow with external audit process

NETADRT flow with external audit process

176
Running the NETADRD utility
The NETADRD utility reads an audit or network overload management file and displays the contents as specified by
the options. The NETADRD utility resides on the XPNET subvolume and is run from a TACL prompt.

Syntax

[ RUN ] [location ] NETADRD [ / OUT list-file / ] audit-file-name

[ , [ NO ] REAL-TIME ] [ ,select-option ]… [ , output-option ]…
[ , display-option ]… [ , FILTER filter-file-name ]
[ , QWRITE_queue-file-name_ ]

RUN - An optional keyword for the RUN command. If this keyword is included in the command, the location variable
must also be included in the command if you are not starting the utility from the subvolume in which it is located. If
this keyword is not included in the command, the NETADRD utility must be located on a volume and subvolume that
is in the PMSEARCH list at your site.

location - Specifies the volume and subvolume on which the NETADRD utility is located. This variable is required if
the location of the NETADRD utility is not included in the PMSEARCH list at your site and you are starting the utility
from a location other than the subvolume in which the utility is located.

OUT list-file - Designates a file to receive all listing output. This file is normally a device, such as a terminal or line
printer. If an unstructured disk file is specified, 132-character messages are written. If a list file name is omitted, the
home terminal is used.

audit-file-name - Specifies an audit file or network overload management file that the XPNET process has written
messages to.

[ NO ] REAL-TIME - Specifies whether the audit file is to be processed in real time. (A network overload
management file cannot be processed in real time.)

If REAL-TIME is specified, the NETADRD utility runs normally until it reaches the end of the audit file and then waits
for the XPNET process to add more records to the audit file. As records are added, the NETADRD utility processes
the new information and then resumes waiting until it is stopped from the TACL prompt or the audit file is closed by
the XPNET process.

If NO REAL-TIME is specified, the NETADRD utility runs until it reaches the end of the audit file and then stops. The
default is NO REAL-TIME.

177
The keyword NO cannot be abbreviated. The keyword REAL-TIME can be abbreviated to the character R.

A SET NODE or ALTER NODE command with the REALTIMEAUD attribute set to ON is also
NOTE required to process the audit file in real time; see Processing the audit file in real time for more
information.

select-option - Specifies one or more options for selecting messages to be displayed. There are eight select options,
and one of each of the options can be specified. If more than one option is specified, a record that meets any one of
the criteria will be selected. For example, if three select options are specified, a record that meets the first criteria or
the second criteria or the third criteria will be selected. The syntax for these select options is described below. If no
select options are specified, all messages are selected.

output-option - Specifies which parts of the message are displayed. You can choose whether to display the system
header, the system message header, and the message text. The syntax for these output options is described below.

display-option - Specifies the format used for displaying the message text and user message header, if requested.
The syntax for these display options is described below. If no format (ASCII, EBCDIC, octal, decimal, or
hexadecimal) is specified, the data is displayed as a string of ASCII characters; unprintable characters are displayed
as question marks.

FILTER filter-file-name - Specifies the name of a user-written routine used to manipulate audit or network overload
management data. It is called after all other NETADRD utility selection criteria have been met. A sample filter is
included at the end of this section.

QWRITE queue-file-name - Specifies the file name base of the disk file to which selected messages in the audit or
network overload management file should be written. The NETADRD utility creates the file in the audit file format.

The file name consists of a user-defined file name base of up to six alphanumeric characters. The NETADRD utility
adds a file name stem of two digits, beginning with 01. The file name stem indicates the sequence in which the files
are created. For example, if you specified RECOVR as the disk file name, the NETADRD utility creates the first file
with a file name of RECOVR01. If more than one file is required for the number of records requested, a second file is
created with a file name of RECOVR02.

Select options

The following table describes the syntax for the options available in the NETADRD and NETADRT utilities for
selecting what messages are to be displayed:

178
select-option Description
AUDMESSAGES message- Specifies the type of message to be selected for output. Selection is based on the
type Audit Flag field in the message header. This field is set by the application process
and specifies whether a message is to be audited. Valid message-type values are
as follows:

ON = Includes all messages. Setting AUDMESSAGES to ON is the same as not

including any select options in the RUN command.

OFF = Excludes messages with the Audit Flag field set to true from the display.

ONLY = Includes only messages with the Audit Flag field set to true.

The keyword AUDMESSAGES can be abbreviated to AUDM.

COUNT number Specifies the total number of messages to be output. That is, the number of
output messages is not to exceed the specified number of messages. The
keyword COUNT cannot be abbreviated.

DEST route-code Displays only those messages with the destination specified by the routing code.
Valid route-code values are defined below. The keyword DEST can be
abbreviated to the character D.

DEST "<sym-name>" Displays only the messages with the destination specified by the sys-name
option.

FIRST number Specifies the first message of the audit or network overload management file to
have the message selection criteria applied. Thus, number minus one messages
are skipped. The keyword FIRST cannot be abbreviated.

SOURCE route-code Displays only those messages from the source specified by the routing code.
Valid route-code values are defined below. The keyword SOURCE can be
abbreviated to the character S.

SOURCE "<sym-name>" Displays only the messages with the source specified by the sys-name option.

[ SOURCE route-code AND Displays only those messages from the specified source and to the specified
DEST route-code ] destination. Valid route-code values are defined below. The keyword SOURCE
can be abbreviated to the character S, and the keyword DEST can be
abbreviated to the character D.

The brackets ([ ]) are a required part of the syntax for this option.
NOTE
Parentheses may be substituted for brackets.

SOURCE "<sym-name>" AND Displays only the messages from the specified source to the specified destination.
DEST "<sym-name>"

179
select-option Description
TIME start-time [ / stop-time ] The start or start and stop time identifying which messages to display. The start
and stop times must be specified in a 24-hour format (HHMM). All four digits are
required. For example, 8:30 a.m. is specified as 0830. The keyword TIME cannot
be abbreviated.

If a start time is specified without a stop time, only those messages with a
timestamp on or after the specified start time are displayed.

If both start and stop times are specified, only those messages with a timestamp
between the start and stop time inclusively are displayed.

If other selection criteria are specified, they apply only to the time range specified.

TYPE type Displays only those messages with the specified audit record type. The keyword
TYPE can be abbreviated to the character T. For a description of audit record
types, see Audit record formats.

route-code values. The following information can be entered for the variable route-code in the select options.

Value Description
ALERT Specifies alert messages. The keyword ALERT cannot be abbreviated.

NET-CTR Specifies network control messages. The keyword NET-CTR can be abbreviated
to the character N.

route-code The actual routing code. Valid routing codes are from 0 through 9999. Routing
codes used by processes and stations are application-specific.

"sym-name" Specifies the routing code of the object indicated by the symbolic name. The
symbolic name must be enclosed in quotation marks.

USER subtype Specifies the routing code for a user-defined destination in the VTASK procedure.
This option provides a routing type of 3 and subtype of subtype. The keyword
USER cannot be abbreviated.

Output options

The following table describes the syntax for the output options for both the NETADRD and NETADRT utilities that
specify which parts of the message are displayed:

180
Option Description
[ NO ] HEADER Specifies whether the system header and line printer page headings should be
displayed.

If HEADER is specified, the system header and line printer page headings are
displayed. If NO HEADER is specified, the system header and line printer page
headings are not displayed. The default is HEADER.

The keywords NO and HEADER cannot be abbreviated.

[ NO ] MSGHEADER [ DETAIL Specifies whether the system message header is to be displayed.

]
If MSGHEADER is specified, the system message header is displayed. The data
is presented in octal word format unless another display option is specified.

If NO MSGHEADER is specified, the system message header is not displayed.

The default is NO MSGHEADER.

If the DETAIL option is used, the output for each message in the audit file will list
the message header information with field names and corresponding values
shown for each valid field in the message header. This option significantly
expands the output listing but greatly improves readability of information in the
XPNET message header.

The keywords NO, MSGHEADER and DETAIL cannot be abbreviated.

[ NO ] REPORT Specifies whether reports are generated.

If NO REPORT is specified, reports are not generated.

[ NO ] TEXT Specifies whether the message text is displayed.

If TEXT is specified, the message text is displayed. If NO TEXT is specified, the

message text is not displayed. The default is TEXT.

The keywords NO and TEXT cannot be abbreviated.

[ NO ] TRUNCATE Specifies how much text to display.

If TRUNCATE is specified, only one line of text is displayed. If NO TRUNCATE is

specified, all text is displayed. The default is NO TRUNCATE.

The keywords NO and TRUNCATE cannot be abbreviated.

181
Option Description
[ NO ] PAYLOAD Specifies whether the message payload area is to be displayed if present in the
message.

If PAYLOAD is specified, the payload area is displayed when it is present in a

message. If NO PAYLOAD is specified, the payload area is not displayed. The
default is NO PAYLOAD.

If NO PAYLOAD is specified or used as the default, and a message is read that

has payloads present, the payload is not displayed, but a line is printed indicating
the number of bytes of payload that is present.

The keyword NO cannot be abbreviated. The keyword PAYLOAD can be

abbreviated to the character string PAY.

[ NO ] USER Outputs user data, if any data is available.

Display options

The following table describes the syntax for the display options, which specify the format for displaying the message:

Option Description
[ NO ] ASCII Specifies whether the data is to be displayed in ASCII format.

If ASCII is specified, the data is displayed in ASCII with the unprintable characters
displayed as a three-character octal value. If NO ASCII is specified, the data is
not displayed in ASCII. The default is NO ASCII.

The keyword NO cannot be abbreviated. The keyword ASCII can be abbreviated

to the character A.

[ NO ] BYTE Specifies whether octal and decimal formatted data is to be displayed in bytes.

If BYTE is specified, the text formats of octal and decimal information are
displayed in bytes. If NO BYTE is specified, the data is in word format. The
default is NO BYTE.

The keywords NO and BYTE cannot be abbreviated.

[ NO ] CONTROL Specifies whether the control character definition is displayed for octal values.
This option is used in conjunction with the ASCII or EBCDIC option.

If CONTROL is specified, the control character definition for the octal value is
displayed (for example, ETX for 003). If NO CONTROL is specified, only the octal
value is displayed. The default is CONTROL.

The keywords NO and CONTROL cannot be abbreviated.

182
Option Description
[ NO ] DECIMAL Specifies whether the data is to be displayed in decimal format.

If DECIMAL is specified, the data is displayed in decimal format. If NO DECIMAL

is specified, the data is not displayed in decimal format. The default is NO
DECIMAL.

The keyword NO cannot be abbreviated. The keyword DECIMAL can be

abbreviated to the character string DEC.

[ NO ] EBCDIC Specifies whether the original data is in EBCDIC format.

If EBCDIC is specified, the audit or network overload management data is in

EBCDIC characters. The data is translated into equivalent ASCII characters for
display. An EBCDIC to ASCII conversion table can be found in the HP NonStop
6100 BSC Programming Manual.

If NO EBCDIC is specified, the data is presumed not to be in EBCDIC. The

default is NO EBCDIC.

The keyword NO cannot be abbreviated. The keyword EBCDIC can be

abbreviated to the character E.

[ NO ] HEX Specifies whether the data is displayed in hexadecimal format.

If HEX is specified, the data is displayed in hexadecimal format. If NO HEX is

specified, the data is not displayed in hexadecimal format. The default value is
NO HEX.

The keyword NO cannot be abbreviated. The keyword HEX can be abbreviated to

the character H.

HEXASCII Specifies that data is to be displayed as 16 characters per output line with the
hexadecimal value shown on the left and the corresponding ASCII characters
shown on the right. Characters not representable as ASCII characters are
denoted on the right using the . (period) character.

The keyword HEXASCII overrides other keywords (such as ASCII, BYTE, HEX,
OCTAL, and so on).

[ NO ] OCTAL Specifies whether the data is to be displayed in octal format.

If OCTAL is specified, the data is displayed in octal format. If NO OCTAL is

specified, the data is not shown in octal format. The default is NO OCTAL.

The keyword NO cannot be abbreviated. The keyword OCTAL can be

abbreviated to the character O.

183
Option Description
[ NO ] TRANSPARENT With the ASCII character string (no format is explicitly specified), TRANSPARENT
causes the following unprintable characters not to be translated to question
marks:

%000-%037
%173-%377

If NO TRANSPARENT is specified, the above characters are printed as question

marks. The default is NO TRANSPARENT. The keywords NO and
TRANSPARENT cannot be abbreviated.

RECOUT number Specifies the length of each output line. The default is the physical record length
of the output device specified at SYSGEN time, except for disk files and
processes, where the default is 17 through 132 characters. The keyword
RECOUT cannot be abbreviated.

Examples

RUN $[Link] AUDFILE

This example lists all messages in the file named AUDFILE displaying the system header and the text data in ASCII
string format.

RUN $[Link] AUDFILE, S "S1A32701," TIME 10:30

This example lists all messages from the station named S1A32701 after 10:30.

RUN $[Link] AUDFILE, FILTER filter

This example causes the NETADRD utility, once all other selection criteria have been met, to write all messages to
the user-written routine filter. In this example there are no selection criteria, so all messages are written directly to
the filter routine. A sample filter routine is included at the end of this subsection.

RUN $[Link] AUDFILE, AUDMESSAGES ONLY, QWRITE $[Link]

This example causes the NETADRD utility to write only messages that have the Audit Flag field set to true. The
selected messages are written to the disk file named $[Link].

The above examples would also apply to the NETADRT utility, with the exception of using a configuration file name
instead of the input audit file name of "AUDFILE".

184
Running the NETADRT utility
The NETADRT utility reads an audit or network overload management file and displays the contents as specified by
the options. The NETADRT utility resides on the XPNET subvolume and is run from a TACL prompt. The NETADRT
utility runs normally once it establishes a connection to the EAUDPRO and then waits for the EAUDPRO to send
more data (audit records) over TCP/IP. As records are read, the NETADRT utility processes the new information and
then resumes waiting until it is stopped from the TACL prompt or the TCP/IP socket is closed by the EAUDPRO
process.

Syntax

[ RUN ] NETADRT [ / OUT list-file / ] config-file-name [ , select-option [output-option ]…

[ , display-option ]… [ , FILTER filter-file-name ]
[ , QWRITE queue-file-name ]

RUN - An optional keyword for the RUN command. If this keyword is included in the command, the location variable
must also be included in the command if you are not starting the utility from the subvolume in which it is located. If
this keyword is not included in the command, the NETADRD utility must be located on a volume and subvolume that
is in the PMSEARCH list at your site.

OUT list-file - Designates a file to receive all listing output. This file is normally a device, such as a terminal or line
printer. If an unstructured disk file is specified, 132-character messages are written. If a list file name is omitted, the
home terminal is used.

config-file-name - Specifies a configuration file that contains the data necessary to establish the TCP/IP connection
with the external audit process.

select-option - Specifies one or more options for selecting messages to be displayed. There are eight select options,
and one of each of the options can be specified. If more than one option is specified, a record that meets any one of
the criteria will be selected. For example, if three select options are specified, a record that meets the first criteria or
the second criteria or the third criteria will be selected. The syntax for these select options is described below. If no
select options are specified, all messages are selected.

output-option - Specifies which parts of the message are displayed. You can choose whether to display the system
header, the system message header, and the message text. The syntax for these output options is described below.

display-option - Specifies the format used for displaying the message text and user message header, if requested.
The syntax for these display options is described below. If no format (ASCII, EBCDIC, octal, decimal, or
hexadecimal) is specified, the data is displayed as a string of ASCII characters; unprintable characters are displayed
as question marks.

FILTER filter-file-name - Specifies the name of a user-written routine used to manipulate audit or network overload
management data. It is called after all other NETADRD utility selection criteria have been met. A sample filter is
included at the end of this section.

QWRITE queue-file-name - Specifies the file name base of the disk file to which selected messages in the audit or
network overload management file should be written. The NETADRT utility creates the file in the audit file format.

The file name consists of a user-defined file name base of up to six alphanumeric characters. The NETADRT utility
adds a file name stem of two digits, beginning with 01. The file name stem indicates the sequence in which the files
are created. For example, if you specified RECOVR as the disk file name, the NETADRT utility creates the first file
with a file name of RECOVR01. If more than one file is required for the number of records requested, a second file is

185
created with a file name of RECOVR02.

NETADRT configuration file

The NETADRT program uses a configuration file that contains the data necessary to establish the TCP/IP
connection with the external audit process.

The following is a sample TCP/IP configuration file.

param PROTOCOL TCPS

param RPORT 20270
param TCPIPPRO $ZTC1
param AWAITTIMER -1

The following is a sample configuration file if SSL/TLS is required.

param PROTOCOL SSLS

param LPORT 20093
param TCPIPPRO $ZTC1
param AWAITTIMER -1
param SSLCONFIG <$[Link]>

The following is a sample SSL configuration file.

param CERTFILE $[Link].cert2025

param PASSWORD
password
param LICENCE_FILE $[Link].lic2020
param ROOTSFILENAME $[Link].ROOT2025
param CLIENTAUTH NO
param ALLOWMD5SIGNATURES YES
param CONNECTIONTIMEOUT 0
param SESSIONTIMEOUT 0
param SERVERMINPROTVERSION TLS12
param CLIENTMINPROTVERSION TLS12
param CLIENTHELLOPROTVERSION TLS12
param ENCRYPTTHENMACONLY ON

Processing the audit file in real time

Processing an audit file in real time is running the NETADRD utility against the file while the XPNET process still has
it open for auditing. Two factors are required to process the audit file in real time: the REAL-TIME parameter for the
NETADRD utility is used to specify real time processing and the REALTIMEAUD attribute must be set to ON for the
XPNET node performing the audit. The REAL-TIME parameter is described earlier in this section.

This topic applies only to internal audit. Using external audit with TCP/IP and NETADRT is a
NOTE
functional equivalent for REALTIMEAUD.

The REALTIMEAUD attribute affects the buffering action for audited messages as well as the maximum allowable

186
size for messages written to the audit file.

When this attribute is set to the value ON, the XPNET process changes the value of the AUDITIO node attribute to
NOWAIT, which impacts system performance. You cannot change the value of the AUDITIO node attribute until the
REALTIMEAUD attribute is set to OFF. For more information about how the NOWAIT setting impacts system
performance, see the description of the AUDITIO attribute in the NET24-XPNET Network Control Command
Reference Manual.

In addition, messages written to the audit file with a message length greater than 4095 bytes are truncated to 4095
bytes. When the NETADRD utility encounters a message that has been truncated, the following message is written
to the output location specified in the NETADRD RUN command:

Message truncated at 4095 bytes.

The NETADRD utility recognizes if a message has been truncated; such messages are not written to a QWRITE file.
This safeguards against truncated messages being reintroduced into the XPNET system with a QREAD command.
When the NETADRD utility encounters this type of message, the following message is written to the output location
specified in the NETADRD RUN command:

Message not put in QWRITE file.

If the message length of your messages is greater than 4095 bytes but you need to process the messages quickly,
you can take one of three actions.

• You can turn auditing off, which closes the audit file.
• You can use the CONTROL NODE command with the SWAUDIT directive to close the current audit file and
open the next audit file.
• You can set the ADEXTENT and ADMAXEXTENTS attributes to a low file size. This latter action causes the
XPNET process to switch to a new audit file more frequently, resulting in more rapid turnover of audit files.

Once an audit file is closed, you can process the messages without the limitations of processing the audit file in real
time.

NETADRD and NETADRT output examples

The audit report data for a message can consist of a system message header and message text data.

The system message header can be selected using the MSGHEADER output option. The system message header
is presented in octal format. If other display formats are requested in the command, the system message header is
also presented in those formats. The information is presented in word format, unless BYTE format is specified.

The message text data is presented as a string of ASCII characters with the unprintable characters converted to
question marks. The optional display formats (ASCII, EBCDIC, decimal, hexadecimal, and octal) are presented in
word format unless BYTE is specified. Specifying TRANSPARENT suppresses the conversion of unprintable
characters. The NO TEXT option suppresses the message text.

Page headings and summary statistics are generated unless output is sent to a terminal or the output option NO
HEADER is selected.

187
RECD-NO
The relative position of this message in the audit file.

LENGTH
The length of the message text.

TIME
The message timestamp.

ERROR
The value of the Error Number field from the system header. If no Error Number field is in the system header, the
error field display is blank.

TRN-NO
The transaction number of the message.

FAIL
The value of the Failure Code field from the system header. If the Failure Code field does not contain a value,
this field is blank.

TYPE
The value of the Internal Event Flag field from the system header. This value represents the audit record type.
For a description of audit record types, see Audit record formats.

SOURCE
The source of the message. This field displays two pieces of information. The first is the symbolic name of the
station or process that sent the message. The second is the source of the message internal to the local XPNET
node; it gives the source type (PROCESS or STATION) and a number that is for internal use only.

DEST
The destination of the message. This field displays two pieces of information. The first piece is the symbolic
name of the station or process that is to receive the message. The second piece of information is the destination
of the message internal to the local XPNET node; it gives the destination type (PROCESS or STATION) and a
number that is for internal use only.

O
An octal representation of the message. This field is present only when octal format output is requested in the
RUN command.

D
A decimal representation of the message. This field is present only when decimal format output is requested in
the RUN command.

H
A hexadecimal representation of the message. This field is present only when hexadecimal format output is
requested in the RUN command.

A
An ASCII representation of the message. This field is present only when ASCII format output is requested in the

188
 RUN command.

E
An EBCDIC representation of the message. This field is present only when EBCDIC format output is requested in
the RUN command.

messages read
The number of messages read by the NETADRD utility.

messages out
The number of messages actually displayed by the NETADRD utility.

189
190
NETADRD and NETADRT output with message chunks

If NETADRD output includes large messages that have been broken into multiple chunks, the TRN-NO field contains

191
a unique identifier for each chunk, and each chunk contains the following additional field.

LARGE MESSAGE

An internal identifier used by all chunks in a message, a value that shows which chunk is displayed, and the number
of chunks that a large message contains.

The following output shows how the first three chunks of a large message are presented.

5 10000 06/02/13 13:14:37.65 253 6 - Process

Input

SOURCE P1A^102 ( PRO 14 )

DEST P1B^000 ( %177777 )
(large message id=1819043186, chunk 1 / 20)

6 10000 06/02/13 13:14:37.65 255 6

- Process Input

SOURCE P1A^102 ( PRO 14 )

DEST P1B^000 ( %177777 )
(large message id=1819043186, chunk 2 / 20)

7 10000 06/02/13 13:14:37.65 256 6

- Process Input

SOURCE P1A^102 ( PRO 14 )

DEST P1B^000 ( %177777 )
(large message id=1819043186, chunk 3 / 20)

NETADRD and NETADRT output with message header detail

The following NETADRD output example shows how the MSG HEADER DETAIL option affects the output. The
message header is shown in detailed format, showing values for each field in the message header on a field-by-field
basis (with the word offset shown on the left). Field explanations can be found in the NET24-XPNET Application
Programming Guide.

192
74 138 06/05/23 10:54:46.80 62210 7 - Pro

SOURCE S1A^STA1 ( %177777 )

DEST P1A^PRO1 ( PRO 20 )

system message header detail

word [0] msg^type = 00 (normal)
[1] msg^source^ty = 15 (other) msg^source^st = 4095
[2] msg^dest^ty = 01 (process) msg^dest^st = 0020
[ 3-10] msg^sym^source = S1A^STA1
[11-18] msg^sym^dest = P1A^PRO1
[19] msg^source^class = PWS
[21] msg^payload^length = 00000
[22-24] = 00000 00000 00000
[25] msg^pro^nom^max^: type = 0 (QMI) percent = 000
msg^service^nom^max^: type = 0 (QMI) percent = 000
[26] msg^abort^requested = 0
msg^http^request = 0 msg^http^response = 0
msg^text^is^padded = 0 msg^jms^client = 0
msg^text^type = 00
[27] msg^sym^type^source = 02 (station)
msg^sym^type^dest = 01 (process)
msg^control^flag = 0
[28] msg^qstate^: qat^exp = 0 qat^pct = 000 nom^pct = 000
[29] msg^priority = 00000
[30] msg^category = 00 (passthru)
[31] msg^subcategory^saf = 0
[32] msg^failure = 00000 (no error)
[33] msg^length = 00138
[34] msg^skel^warmboot = 0
msg^seqno = 0007
[35] msg^error = 00000
msg^service^qstate^:
qat^exp = 0 qat^pct = 000 nom^pct = 000
[36-37] = 00000 00023
[38] msg^tptr = 00116
[39-41] msg^time = 020523 10:54:46.80
[42-44] msg^timelimit = 000000 00:00:00.00
[45-46] msg^trans = 0000062210
[47] msg^disposition = 0 (fail action: return)
msg^noaudit = 0 msg^ack^req = 0
msg^forceq = 0 msg^poss^dup^ = 0
msg^transparent = 0 msg^nom^override = 0
msg^nom^return = 0 msg^fm^msg = 0
msg^audit = 0
[48-51] msg^pro = 16384 00000 00001 00000
[48] msg^cts^flow^ind = 1
[49] msg^cts^data = 00000
[50] msg^data^type = 00001
[52] msg^connect^id = 00000
[53] msg^external^source = 0 msg^service^dist^global = 0
msg^fmh^indicator = 0 msg^broadcast = 0
msg^fail^unavailable^dest = 0
msg^usize = 004

<message text is shown here>

193
NETADRD filter processing
It is possible to do further selection, rejection, or updating of records utilizing a user-written filter routine. If the
FILTER option is specified in the NETADRD RUN command, the NETADRD utility calls the user-written routine after
all prior selection criteria have been met. The following is an example of a filter routine:

! SAMPLE FILTER (SERVER) to handle data from NETADRD

!
!
?INSPECT,SYMBOLS
?nolist,source $[Link](msgdef)
?list
?NOLIST,SOURCE $[Link](MYTERM,read,OPEN,WRITE,wait^file,DEBUG,
? fileinfo,stop,readupdate,receiveinfo,reply)
?NOCODE,LIST
!******************************************************************************
! brief review of Requester/Server fields
! REQUESTER (NETADRD)
! call writeread(filt^num, *** $XXXX process file number
! record, *1* buffer in server
! cnt, *2* number of bytes sent by requester
! filtmaxct, *3* max no of bytes requester will accept
! rd^cnt) *4* number of bytes to be sent by server
!
! SERVER (FILT^SAMPLE)
! call readupdate(recv^num, *** $receive
! buff, *1* record from requester
! maxbytes, *** max [Link] bytes server will accept
! actualcnt) *2* actual no.
of bytes sent by requester
!
! call receiveinfo(processid, *** process id of requester
! messtag, ***
! syncid, ***
! fileno, *** file no written by the requester
! reqmaxcnt) *3* max no of bytes requester will accept
!
! call reply (buff, *1* record to requester
! writebytes *4* number of bytes to send to requester
! rqstcnt *** count sent (returned from call reply)
!
!
!*****************************************************************************
?page
PROC FILT^SAMPLE MAIN;
BEGIN
LITERAL true = %177777,
bufflen = 4096, ! number of bytes in buffer
false = %000000;

define byteaddr ( addr ) = (( addr ) '<<' 1 ) #,

words (CNT) = ((( CNT ) + 1 ) '_' 1 ) #,
decr ( VAR ) = VAR := VAR '-' 1 #,
incr ( VAR ) = VAR := VAR '+' 1 #;
int recv^num, ! $receive file number
dummycnt, ! manipulation count area
reqmaxcnt, ! max no of bytes for requester
maxbytes, ! max bytes this server will accept
actualcnt, ! number of bytes sent by requester

194
 recverr, ! error info area for $receive
ptr, ! index for manipulation
fstsw, ! on = got "open" msg on $receive
writebytes, ! number of bytes to be written by server
rqstcnt, ! area that REPLY returns bytes sent
filt^open^flag, ! set up to accept system msgs
recv[0:11] :="$receive ", !$receive
.buff[0: (bufflen / 2) - 1 ], ! record from net audit read
.msg := @buff '+' 1; ! point msg past length byte
string .sbuff := byteaddr(@buff), ! byte scanner
.mtp;
! HOUSEKEEPING
fstsw := 0;
dummycnt := 0;
writebytes := 0;
rqstcnt := 0;
ptr := 0;
filt^open^flag := %040000 ; ! we want to get system messages
! for more info on system messages
! see the appropriate operating
! system procedure calls manual.
call open (recv,recv^num,filt^open^flag,1);
! do pre process routines here
! ie special heading etc...
while 1 do ! forever loop
begin
recverr := 0;
maxbytes := 4096;
ptr := 0;
call readupdate(recv^num,buff,maxbytes,actualcnt);
if <> then
begin
call fileinfo(recv^num,recverr);
if recverr = 6 then ! system message open,close,etc...
begin
call reply; ! answer the system msg
if fstsw then ! 2nd system msg assume it is a close message
begin
call stop; ! do file cleanup here
end;
fstsw := true;
end
else
begin
call debug;
end;
end
else
begin ! start of non-system messages
call receiveinfo(,,,,reqmaxcnt); ! get max no of bytes for requester
if <> then
begin
call debug;
end;
! SAMPLE manipulation of data from netaudit read here
! Tells NETADRD to process the first 10 records normally, then reject
! records 11 through 50, and finally to add the constant "ACI#1ACI#1"
! to all remaining records.
while actualcnt > ptr do ! make P1A = XYZ
begin
if sbuff[ptr] = "P1A" then

195
 sbuff[ptr] ':=' "XYZ" ;
incr (ptr);
end;
if dummycnt < 10 then
writebytes := actualcnt;
if dummycnt >= 10 then !do the first ten records normally then
writebytes := 0; !tell net aud read to reject records 11-50
if dummycnt > 50 then !then add 10 bytes of info to remaining recs
begin
set^text; ! set to offset from hdr to start of text
mtp[msg^length] ':=' "ACI#1ACI#1"; ! add 10 bytes of info
msg^length := msg^length + 10; ! fix length accordingly
writebytes := actualcnt + 10; ! original length plus 10
end;
dummycnt := dummycnt + 1;
rqstcnt := 0; ! returned from call REPLY tells how many
! bytes were written
if writebytes > maxbytes then
call debug; ! we tried to send more than requester will accept
! end of sample manipulation
call reply(buff,writebytes,rqstcnt); ! send to requester
if <> then
begin
call fileinfo(recv^num,recverr);
call debug;
end;
end; ! end of non-system messages
end; !of while loop

END; !of main

NETDMPRD utility
The NETDMPRD utility is a recovery tool designed to extract any queued messages existing in an XPNET
saveabend file and write them to an audit file. You can then use this audit file as input to the NETADRD utility to
create a disk file in QWRITE format and then reintroduce the messages to the XPNET system using the CONTROL
NODE command with the QREAD directive.

The utility determines if the dump is complete and attempts to verify the integrity of the saveabend file. Any memory
corruption detected in the saveabend file stops the utility.

You can specify two audit files as output. The first file is required and contains queued event messages, messages
queued to the XPNET receive queue, and messages queued to processes, links, and stations, and to unknown
destinations and unavailable services. The second audit file is optional and contains any messages that were
queued to the audit queue at the time of the abend.

The NETDMPRD utility produces a report that contains a count of the number of messages written to the audit files.
You can specify that the report be written to a spooler location or the terminal. The flow of the NETDMPRD utility is
shown here:

196
Running the NETDMPRD utility
The NETDMPRD utility resides on the XPNET subvolume and is run from a TACL prompt.

Syntax

[ RUN ] [location ] NETDMPRD / IN ZZSA-file [ , OUT $S. location ]

[ , LIB [Link] ] /audit-file1 [ , audit-file2 ]

RUN — An optional keyword for the RUN command. If this keyword is included in the command, the location
variable must also be included in the command if you are not starting the utility from the subvolume in which it is
located. If this keyword is not included in the command, the NETDMPRD utility must be located on a volume and
subvolume that is in the PMSEARCH list at your site.

location — Specifies the volume and subvolume on which the NETDMPRD utility is located. This variable is required
if the location of the NETDMPRD utility is not included in the PMSEARCH list at your site and you are starting the
utility from a location other than the subvolume in which the utility is located.

IN ZZSA-file — Specifies the XPNET saveabend file containing the queued messages.

OUT $S. location — Designates the spooler location for the statistics report. If this parameter is omitted, the report
displays on your home terminal.

LIB — Specifies the name of a library that is required when running the NETDMPRD utility on an HP NonStop S-
series platform (that is, G-series Guardian operating system). The NETDMPLB library includes the SVREAD library
provided by HP. See the NET24-XPNET Introduction Manual for the license terms for this software.

audit-file1 — The name of the audit file in which queued event messages, messages queued to the XPNET receive
queue, messages queued to processes, links, and stations, and messages queued to unknown destinations and
unavailable services are to be placed.

audit-file2 — The name of an optional audit file in which messages from the audit queue are to be placed. If this
parameter is omitted, no messages from the audit queue are extracted from the saveabend file.

Example

RUN $[Link] / IN ZZSA1234, OUT $S.LP7 / TSTAUDFL

197
NETCJRD utility
The NETCJRD utility is used to create a report from the configuration journal. The XPNET process can optionally
maintain a configuration journal for each XPNET node. This journal contains information about any changes made to
the configuration of objects on the XPNET node. All ADD, ALTER, DELETE, ENABLE, and DISABLE commands are
recorded in this journal as well as CONTROL NODE commands with the COMMIT and ROLLBACK directives.

You can use this utility to create a report that contains changes made by a specified user, changes made between
specified times, changes made by a specific command, and changes made to a specified object type.

The flow of the NETCJRD utility is shown below. The following sections contain a description of this utility and the
type of information generated.

Running the NETCJRD utility

The NETCJRD utility reads the configuration journal and displays the contents as specified by the options. The
NETCJRD utility resides on the XPNET subvolume and is run from a TACL prompt.

Syntax

[ RUN ] [ location ] NETCJRD [ / OUT file-name / ] journal-file-name

[ , USER user-id ] [ , FROM date-time ] [ , TO date-time ]
[ , CMD command-type [ : command-type ] … ]
[ , OBJTYP object-type [ : object-type ] … ]

RUN - An optional keyword for the RUN command. If this keyword is included in the command and you are not
starting the utility from the subvolume in which it is located, the location variable must also be included in the
command. If this keyword is not included in the command, the NETCJRD utility must be located on a volume and
subvolume that is in the PMSEARCH list at your site.

location - Specifies the volume and subvolume on which the NETCJRD utility is located. This variable is required if
the location of the NETCJRD utility is not included in the PMSEARCH list at your site and you are starting the utility
from a location other than the subvolume in which the utility is located.

OUT file-name - Designates a location to receive the output of the utility. This location can be a spooler location or a

198
disk file. If this parameter is omitted, the report displays on your home terminal.

journal-file-name - Specifies the name of a configuration journal file. If you do not fully qualify the file name, the
NETCJRD utility searches for the file on the current volume and subvolume. If more than one file is necessary for the
report, the file specified by this parameter must be the most recent file. The NETCJRD utility can move backward
through configuration journal files but not forward.

USER user-id - Specifies the user ID of the operator who made the configuration changes. This value must match
the ID that the operator enters in the SET USER command. If you do not specify a user ID, the utility lists
configuration changes made by all operators.

FROM date-time - Specifies the beginning date and time (in YYYYMMDDhhmm format) for which you want
configuration changes listed. If you do not specify a beginning date, the report starts at the beginning of the named
configuration journal.

TO date-time - Specifies the ending date and time (in YYYYMMDDhhmm format) for which you want configuration
changes listed. If you do not specify an ending date, the report lists configuration changes through the end of the
named file.

CMD command-type - Specifies the type of command that you want listed in the report. You can specify more than
one command type by separating each subsequent command type from the previous command type with a colon (:).
If you do not specify a command type, the report lists all commands. Valid values are as follows:

ADD = List only ADD commands in the report.

ALTER = List only ALTER commands in the report.

COMMIT = List only CONTROL NODE commands with the COMMIT directive in
the report.

DELETE = List only DELETE commands in the report.

DISABLE = List only DISABLE commands in the report.

ENABLE = List only ENABLE commands in the report.

ROLLBACK = List only CONTROL NODE commands with the ROLLBACK directive
in the report.

OBJTYP object-type - Specifies the object type for which you want configuration changes listed. You can specify
more than one object type by separating each subsequent object type from the previous object type with a colon (:).
If you do not specify an object type, the utility reports on all object types. Valid values are as follows:

DEST = List changes only for dests.

DEVICE = List changes only for devices.

199
LINE = List changes only for lines.

LINK = List changes only for links.

NODE = List changes only for the node.

PROCESS = List changes only for processes.

STATION = List changes only for stations.

Examples

RUN $[Link] / OUT $[Link].CNFG1 / $DATA.P1ANCJA.CJ00006, FROM

199801010100, TO 199806301159

This example lists all configuration changes that have been made between 1:00 a.m. on January 1, 1998 and just
before midnight on June 30, 1998, and writes them to a file named CNFG1.

RUN $[Link] / OUT $[Link].CNFG2 /, $DATA.P1BNCJA.CJ00032, USER OPER6,

CMD DELETE

This example lists all DELETE commands executed by the operator with a user ID of OPER6 and writes them to a
file named CNFG2.

RUN $[Link] / OUT $[Link].CNFG3 / $DATA.P1ANCJA.CJ00060, CMD ADD:ALTER,

OBJTYP STATION:LINE

This example lists all ADD and ALTER commands executed on stations and lines and writes them to a file named
CNFG3.

NETCJRD report example

An example of a NETCJRD report is shown below. This report lists all ADD and DELETE commands for stations and
lines as well as CONTROL NODE commands with the COMMIT directive executed between July 1, 1998 and July
15, 1998. Descriptions of the fields on the report follow the report.

JOURNAL
The fully qualified file name of the configuration journal specified in the NETCJRD command. This field is
followed by a list of the options specified in the command. In this example, the FROM, TO, CMD, and OBJTYP
options were specified.

FILE
The name of the configuration journal file for which information is being reported. Depending on the options
specified in the NETCJRD command, more than one journal file can be read.

NODE
The fully qualified name of the XPNET node for which configuration journal information is being reported.

200
CMD-NO
The number of the command as listed in the configuration journal file. Commands are numbered in chronological
order in each configuration journal file.

TIME
The date and time the command being reported was executed.

USER
The user ID of the operator who executed the command.

COMMAND
The text of the command that was executed.

201
RELPROC macro
RELPROC is a TACL macro that helps customers obtain release information from the XPNET-related objects on

202
their system. XPNET code is versioned in a clear way by placing release procedures into each object module with
the purpose of being able to identify which release and fix version it represents. By viewing the release procedures
for a module, it can be easily determined which version of code the customer has and whether or not additional fixes
are available for individual modules.

If a problem is called into the support center for XPNET, support persons will commonly request that the release
procedure information be obtained for the affected module(s). The RELPROC macro provides the user an easy way
to obtain the release information for any XPNET object module. RELPROC uses BIND, NOFT, or eNOFT, depending
on whether the object is TNS, TNS/R (native), or TNS/E (native), respectively, to obtain a list of the release
procedures and display them as output to the terminal or to a specified file. RELPROC can provide abbreviated or
detailed output for each release procedure identified. This information can then be sent to the support center to
provide help for solving the reported problem.

203
Running the RELPROC macro
The RELPROC macro resides on the XPNET subvolume and is run from a TACL prompt.

204
Syntax

[ RUN ] [ location ] RELPROC [ / OUT list-file / ] object-file-name [ DETAIL ]

RUN — An optional keyword for the RUN command. If this keyword is included in the command, the location
variable must also be included in the command if you are not running the macro from the subvolume in which it is
located. If this keyword is not included in the command, the RELPROC macro must be located on a volume and
subvolume that is in the PMSEARCH list at your site.

location — Specifies the volume and subvolume on which the RELPROC macro is located. This variable is required
if the location of the RELPROC macro is not included in the PMSEARCH list at your site and you are running the
macro from a location other than the subvolume in which the macro is located.

OUT list-file — Designates a file to receive all listing output. This file can be a device, such as a terminal or line
printer. It can also specify an edit file or a spooler location. If a list file name is omitted, the home terminal is used.

object-file-name — Specifies the name of the object file for which release procedure information is required.

[ DETAIL ] — Specifies that detailed information be displayed for each release procedure found. Detailed information
includes the following:

• Release procedure name

• Source filename for the source file which contains the indicated release procedure
• Last modified timestamp for the source file which contains the indicated release procedure
• Compilation timestamp for the module which contains the indicated release procedure
• Source code compiler that was used (C, TAL, pTAL, and so on)
• Optimization level of the module is shown for TNS/R (native) and TNS/E (native) objectsNon-detail output lists
only the following information in an abbreviated format:
• Release procedure name
• Compilation timestamp for the module which contains the indicated release procedure
• For TNS objects, the source code compiler that was used (C, TAL, and so on)This is an example of non-detail
RELPROC output for the NETWORK object:

205
 TACL > RELPROC NETWORK
RELPROC (DEC2003), executing: March 2, 2005 12:03:08
File : \SYS.$[Link]
Type : TNS/R Native
Module List
-----------------------------
REL3^VER1^IPOS00^20041122 Compiled: January 20, 2005 21:57:33
REL3^VER1^INON00^20031031 Compiled: January 20, 2005 21:56:33
REL3^VER1^CTS00^20041122 Compiled: January 20, 2005 21:39:08
REL3^VER1^BCS00^20041122 Compiled: January 20, 2005 21:32:14
REL3^VER1^OSI00^20041122 Compiled: January 20, 2005 22:14:34
REL3^VER1^ERIC00^20041122 Compiled: January 20, 2005 21:49:59
REL3^VER1^X2100^20041122 Compiled: January 20, 2005 22:35:24
REL3^VER1^B1P00^20041122 Compiled: January 20, 2005 21:31:33
REL3^VER1^DLM00^20041122 Compiled: January 20, 2005 21:42:46
REL3^VER1^DP3200^20041122 Compiled: January 20, 2005 21:44:47
REL3^VER1^DSP00^20041122 Compiled: January 20, 2005 21:45:49
REL3^VER1^HOST00^20041122 Compiled: January 20, 2005 21:55:57
REL3^VER1^NONE00^20041122 Compiled: January 20, 2005 22:01:14
.
.
.
REL3^VER1^DLIB05^050208 Compiled: February 10, 2005 13:46:38
REL3_VER1_EBU02_040624 Compiled: July 20, 2004 18:36:34
REL3_VER1_HTTP08_041228 Compiled: December 28, 2004 14:51:32
REL3_VER1_HTTP_UTIL05_030112 Compiled: (not available)
REL3^VER1^SCRB00^040624 Compiled: January 20, 2005 21:00:17
REL3_VER1_PRUT01_20050129 Compiled: January 28, 2005 12:02:38
REL3^VER1^BASE^REL01^20050211 Compiled: February 11, 2005 16:24:01
Finished - March 2, 2005 12:03:22

RPCGEN utility
The RPCGEN utility is located on the XPNET subvolume and is used as part of the Routing Profile Configuration
facility to compile complex message routing scripts from an XML source file. RPCGEN generates an extended
segment file of data that can be used by XPNET when routing messages within the network.

The Routing Profile Configuration facility adds the following capabilities to message routing within XPNET:

• Route to an unlimited number of potential destinations

• Match on large character strings within the message
• Make complex routing decisions based on several relational comparison operators and multiple data fields within
the message
• Configure routing of messages from a process as well as a station
• Extract the symbolic destination from within the message
• Route one message to multiple destinations (broadcasting or forking)

The flow of the RPCGEN utility is shown below. The following sections contain a description of this utility and the
type of information generated. The NET24-XPNET Routing Profile Configuration Guide provides a complete
explanation of the Routing Profile Configuration facility and all its components.

206
Running the RPCGEN utility
The RPCGEN utility resides on the XPNET subvolume and is run from a TACL prompt.

Syntax

[ RUN ] [ location ] RPCGEN / IN XML-source-file-name [ , OUT list-file ] / RPConf-file-name

RUN — An optional keyword for the RUN command. If this keyword is included in the command and you are not
starting the utility from the subvolume in which it is located, the location variable must also be included in the
command. If this keyword is not included in the command, the RPCGEN utility must be located on a volume and
subvolume that is in the PMSEARCH list at your site.

location — Specifies the volume and subvolume on which the RPCGEN utility is located. This variable is required if
the location of the RPCGEN utility is not included in the PMSEARCH list at your site and you are starting the utility
from a location other than the subvolume in which the utility is located.

IN XML-source-file-name — Specifies an XML source file that has been written using tags and identifiers understood
by the RPCGEN utility and which defines the routing configuration required by the XPNET network.

OUT list-file — Designates a file to receive all listing output. This file is normally a device, such as a terminal or line
printer. If an unstructured disk file is specified, 132-character messages are written. If a list file name is omitted, the
home terminal is used.

RPConf-file-name — Specifies a file to receive the routing configuration data generated by the RPCGEN utility. This
file is created by the RPCGEN utility and must not exist prior to running the utility. Once this file is successfully
created, the name of this file can be placed into the RPCONF device attribute in a device object added to the
XPNET configuration. When the RPCONF device attribute is altered to the name of this file or a new device object is
added to the XPNET configuration with the name of this file set in the RPCONF attribute, XPNET opens this file as
an extended segment file and uses the data, as necessary, to route messages from processes and stations that use
the device under which it is configured.

207
XNCGEN utility
The XNCGEN utility is located on the XPNET subvolume and is used as part of the Extended Network Configuration
facility to compile nonstandard process configurations from an XML source file. XNCGEN generates an extended
segment file of data that can be used by XPNET when starting processes that require additional assign and
parameter information in the standard startup message.

All processes managed by XPNET are configured by adding the appropriate process object in the network
configuration, as follows.

• Satellite processes are those processes designed to use one of the XPNET API libraries to communicate with
the XPNET process at process startup, shutdown, and for receiving messages from the XPNET process and
sending messages to the XPNET process. Satellite processes receive the proprietary XPNET startup message
when the process is started.
• Non-satellite processes are those processes the XPNET process can start up and manage (that is, start, stop,
restart on failure), but do not use an XPNET API to communicate directly with XPNET. Non-satellite processes
do not receive the proprietary XPNET startup message when the process is started since they are not designed
to understand it.

The Extended Network Configuration facility allows XPNET to be used to start and manage additional types of
processes running on the HP NonStop server, including the following:

• XPNET satellite processes running in the OSS space

• Non-satellite processes running in the Guardian space
• Non-satellite processes running in the OSS space

These three types of processes require configuration data that does not readily fit into the XPNET Network
Environment File (NEF). Instead, the Extended Network Configuration File (XNConf) contains the additional
standard startup assigns and parameters for these purposes.

The flow of the XNCGEN utility is shown below. See Running the XNCGEN utility for a description of this utility and
the type of information generated. The NET24-XPNET Extended Network Configuration Guide provides a complete
explanation of the Routing Profile Configuration facility and all its components.

208
Running the XNCGEN utility
The XNCGEN utility resides on the XPNET subvolume and is run from a TACL prompt.

Syntax

[ RUN ] [ location ] XNCGEN / IN XML-source-file-name [ , OUT list-file ] / XNConf-file-name

RUN — An optional keyword for the RUN command. If this keyword is included in the command and you are not
starting the utility from the subvolume in which it is located, the location variable must also be included in the
command. If this keyword is not included in the command, the XNCGEN utility must be located on a volume and
subvolume that is in the PMSEARCH list at your site.

location - Specifies the volume and subvolume on which the XNCGEN utility is located. This variable is required if
the location of the XNCGEN utility is not included in the PMSEARCH list at your site and you are starting the utility
from a location other than the subvolume in which the utility is located.

IN XML-source-file-name - Specifies an XML source file that has been written using tags and identifiers understood
by the XNCGEN utility and which defines the standard startup assigns and parameters required by the XPNET
process to start one or more processes.

OUT list-file - Designates a file to receive all listing output. This file is normally a device, such as a terminal or line
printer. If an unstructured disk file is specified, 132-character messages are written. If a list file name is omitted, the
home terminal is used.

XNConf-file-name - Specifies a file to receive the extended configuration data generated by the XNCGEN utility. This
file is created by the XNCGEN utility and must not exist prior to running the utility. Once this file is successfully
created, the name of this file can be placed into the XNCONF device attribute in a device object added to the
XPNET configuration. When the XNCONF device attribute is altered to the name of this file or a new device object is
added to the XPNET configuration with the name of this file set in the XNCONF attribute, XPNET opens this file as
an extended segment file and uses the data, as necessary, to start processes that use the device under which it is
configured.

209
Appendix A: Examples of XPNET obey files
This section gives examples of Obey files that can be used to start and stop the XPNET system and other
processes. These files are divided into three groups:

• Obey files used by the Pathway environment

• Obey files used by the XPMON environment
• Obey files used by both environments

The obey file examples shown in this section are for an XPNET system called PROD. For other systems, such as
TEST, names differ according to the XPNET standard naming conventions. Standard naming conventions for the
XPNET system name are described in XPNET components.

Pathway environment obey files

The XPNET system can use the HP NonStop Pathway environment to provide online access. This section contains
examples of several Pathway files. Also included are example files that bring up the Pathway screens on a terminal,
that start the NCPCOM utility, and that start the LCONF entry program as well as a TACL macro to start the
EMSperus utility and an obey file to stop the EMSperus utility.

The Pathway environment configuration and files defined in this section reflect the XPNET configuration described in
The XPNET system name and Examples of XPNET obey files. Note, however, that a separate Pathway environment
configuration must be defined for use by the XPNET node on the second HP NonStop system. Essentially, this
Pathway environment configuration would be a duplicate of the configuration and files described in this section, with
appropriate changes made to reflect the different HP NonStop system.

Pathway configuration file

The Pathway Configuration File (PATHCONF) contains PATHCOM commands to be run in noninteractive mode. This
file is used when the Pathway system is started cold (that is, when a new Pathway Control file (PATHCTL) must be
built).

PATHCONF is composed entirely of PATHCOM commands. For a description of their syntax and functions, see the
appropriate HP NonStop Pathway manual.

Definitions for the ACI-specific server processes are illustrated in this section. The XPNET-specific assigns and
params for the NCP and NCPI Server processes are described in Configuring an XPNET system. An NCPI Server
process must be defined for each XPNET node.

If you change any assigns or params for a server process, you must stop and start the server
NOTE process before the changes take effect. An example of the necessary commands to stop the server
process is included in the PATHSTOP file later in this section.

stop the server process is included in the PATHSTOP file later in this section.
[ ****************************************************************** ]
[ * * ]
[ * PATHWAY CONFIGURATION FILE (PATHCONF) * ]
[ * * ]
[ * THIS PATHCONF FILE CONTAINS COMMANDS FOR AN XPNET SYSTEM. * ]

210
[ * * ]
[ * PATHCONF IS A PATHWAY OBEY FILE CONTAINING PATHCOM COMMANDS * ]
[ * TO BE RUN IN A NONINTERACTIVE MODE.
THIS FILE IS USED WHEN * ]
[ * THE PATHWAY SYSTEM IS STARTED COLD, I.E.
WHEN A PATHCTL MUST * ]
[ * BE BUILT. * ]
[ * * ]
[ ****************************************************************** ]

[ ****************************************************************** ]
[ * * ]
[ * THE LOG1 AND LOG2 COMMANDS SPECIFY THE FILES USED FOR REPORT- * ]
[ * ING ERRORS AND CHANGES IN STATUS.
IF BOTH LOG1 AND LOG2 ARE * ]
[ * UNAVAILABLE, PATHMON REPORTS ERRORS TO THE OPERATOR CONSOLE. * ]
[ * * ]
[ ****************************************************************** ]

LOG1 $0, EVENTFORMAT

[ THE FOLLOWING COMMANDS CONFIGURE THE PATHMON PROCESS. ]

SET PATHMON BACKUPCPU 15

SET PATHWAY OWNER [Link]
SET PATHWAY SECURITY "N"
SET PATHWAY MAXTCPS 3
SET PATHWAY MAXTERMS 75
SET PATHWAY MAXPATHCOMS 75
SET PATHWAY MAXDEFINES 15
SET PATHWAY MAXLINKMONS 16
SET PATHWAY MAXPROGRAMS 5
SET PATHWAY MAXSERVERCLASSES 500
SET PATHWAY MAXSERVERPROCESSES 500
SET PATHWAY MAXSTARTUPS 500
SET PATHWAY MAXASSIGNS 500
SET PATHWAY MAXPARAMS 500

[ ****************************************************************** ]
[ * * ]
[ * THE FOLLOWING COMMAND STARTS PATHWAY COLD, INDICATING THAT A * ]
[ * OBJ PATHCTL FILE IS TO BE BUILT FROM THE PARAMETERS WHICH * ]
[ * FOLLOW. * ]
[ * * ]
[ ****************************************************************** ]

START PATHWAY COLD !

[ ****************************************************************** ]
[ * * ]
[ * THE FOLLOWING COMMANDS DEFINE THE TCP PROCESS.
ONE TCP WILL * ]
[ * SUPPORT APPROXIMATELY 20 TERMINALS.
THEREFORE, IF MORE THAN * ]
[ * 20 TERMINALS ARE USED, ADDITIONAL TCPS MUST BE DEFINED. * ]
[ * * ]
[ ****************************************************************** ]
RESET TCP
SET TCP PROGRAM $[Link]
SET TCP GUARDIAN-LIB $[Link]
SET TCP PRI 135

211
SET TCP CPUS 5:15
SET TCP MAXTERMS 20
SET TCP MAXSERVERCLASSES 400
SET TCP MAXSERVERPROCESSES 400
SET TCP MAXTERMDATA 50000
SET TCP MAXREPLY 5600
SET TCP NONSTOP 0
SET TCP CODEAREALEN 131072
SET TCP TERMBUF 2024
SET TCP PROCESS $PTCP
SET TCP TCLPROG $[Link]
ADD TCP TCP-30

[ ****************************************************************** ]
[ * * ]
[ * SERVERS SHARED BY ALL PRODUCTS * ]
[ * * ]
[ ****************************************************************** ]

[ LOGICAL NETWORK CONFIGURATION FILE SERVER ]

RESET SERVER
SET SERVER CPUS 5:15
SET SERVER PROGRAM $[Link]
SET SERVER DELETEDELAY 20 MINS
SET SERVER TIMEOUT 60 SECS
SET SERVER PRI 160
SET SERVER NUMSTATIC 1
SET SERVER PROCESS $PLCN (ASSOCIATIVE ON)
SET SERVER ASSIGN LCONF1 \SYS1.$[Link].L1CONF
SET SERVER HOMETERM \SYS1.$SUDO
ADD SERVER SERVER-LCONF

[ NCPI SERVER FOR \SYS1.P1A^NODE ]

RESET SERVER
SET SERVER ASSIGN PRI-EVT, \SYS1.$0
SET SERVER ASSIGN NCSP, \SYS1.$[Link]
SET SERVER ASSIGN NCSS, \SYS1.$[Link]
SET SERVER ASSIGN NEF, \SYS1.$[Link].N1ANEF
SET SERVER ASSIGN NMAP, \SYS1.$[Link]
SET SERVER ASSIGN NCPCOM, $[Link]
SET SERVER ASSIGN NCP-IN, $[Link].N1ASTART
SET SERVER ASSIGN NCP-OUT, $S.#N1ASTRT
SET SERVER AUTORESTART 0
SET SERVER CPUS (2:1)
SET SERVER CREATEDELAY 1 SECS
SET SERVER DEBUG OFF
SET SERVER DELETEDELAY 18 HRS
SET SERVER HIGHPIN ON
SET SERVER HOMETERM \SYS1.$SUDO
SET SERVER LINKDEPTH 1
SET SERVER MAXLINKS 32
SET SERVER MAXSERVERS 1
SET SERVER NUMSTATIC 1
SET SERVER PARAM ENABLE-AUDIT "OFF"
SET SERVER PARAM ENABLE-SECURITY "ON"
SET SERVER PARAM PRI-TIM-LMT "300"
SET SERVER PARAM XN-LOCK "ON"
SET SERVER PARAM XN-TIMEOUT "1000"

212
SET SERVER PARAM RQST-TIMEOUT "32737"
SET SERVER PRI 140
SET SERVER PROCESS $P1AU (ASSOCIATIVE ON)
SET SERVER PROGRAM \SYS1.$[Link]
SET SERVER SECURITY "N"
SET SERVER TMF OFF
SET SERVER VOLUME \SYS1.$[Link]
ADD SERVER SERVER-NCPI-1A

[ NCPI SERVER FOR \SYS1.P1B^NODE ]

SET SERVER ASSIGN NEF, \SYS1.$[Link].N1BNEF

SET SERVER ASSIGN NCP-IN, $[Link].N1BSTART
SET SERVER ASSIGN NCP-OUT, $S.#N1BSTRT
SET SERVER CPUS (3:2)
RESET SERVER PROCESS
SET SERVER PROCESS $P1BU (ASSOCIATIVE ON)
ADD SERVER SERVER-NCPI-1B

[ NCPI SERVER FOR \SYS1.P2A^NODE ]

SET SERVER ASSIGN NEF, \SYS1.$[Link].N2ANEF

SET SERVER ASSIGN NCP-IN, $[Link].N2ASTART
SET SERVER ASSIGN NCP-OUT, $S.#N2ASTRT
SET SERVER CPUS (4:3)
RESET SERVER PROCESS
SET SERVER PROCESS $P2AU (ASSOCIATIVE ON)
ADD SERVER SERVER-NCPI-2A

[ NCP SERVER ]
RESET SERVER
SET SERVER ASSIGN PRI-EVT, \SYS1.$0
SET SERVER ASSIGN NMAP, \SYS1.$[Link]
SET SERVER ASSIGN PMON01, \SYS2.$PMON
SET SERVER ASSIGN PMON02, \SYS3.$PMON
SET SERVER CPUS (0:1)
SET SERVER CREATEDELAY 10 SECS
SET SERVER DELETEDELAY 12 HRS
SET SERVER HIGHPIN ON
SET SERVER HOMETERM \SYS1.$SUDO
SET SERVER LINKDEPTH 32
SET SERVER MAXLINKS 32
SET SERVER MAXSERVERS 3
SET SERVER NUMSTATIC 1
SET SERVER PARAM PRI-TIM-LMT "500"
SET SERVER PARAM REFR-ERR-TIMEOUT "500"
SET SERVER PARAM REFR-TIMEOUT "6000"
SET SERVER PARAM RQST-TIMEOUT "30000"
SET SERVER PARAM SERVERCLASS "SERVER-NCP"
SET SERVER PARAM SINTERVAL "180000"
SET SERVER PARAM TN-TIMEOUT "12000"
SET SERVER PARAM XN-TIMEOUT "3000"
SET SERVER PRI 140
SET SERVER PROCESS $PNC1
SET SERVER PROCESS $PNC2
SET SERVER PROCESS $PNC3
SET SERVER PROGRAM \SYS1.$[Link]
SET SERVER VOLUME \SYS1.$[Link]
ADD SERVER SERVER-NCP

[ NCS SERVER ]

213
RESET SERVER
SET SERVER CPUS 5:15
SET SERVER PRI 160
SET SERVER PROGRAM $[Link]
SET SERVER PROCESS $PRG1
SET SERVER PROCESS $PRG2
SET SERVER PROCESS $PRG3
SET SERVER LINKDEPTH 3
SET SERVER MAXLINKS 32
SET SERVER MAXSERVERS 3
SET SERVER NUMSTATIC 1
SET SERVER STARTUP "$PPMN"
SET SERVER TIMEOUT 2 MINS
SET SERVER CREATEDELAY 30 SECS
SET SERVER DELETEDELAY 10 MINS
SET SERVER HOMETERM \SYS1.$SUDO
SET SERVER VOLUME \SYS1.$[Link]
ADD SERVER SERVER-NCS

[ PATH SERVER ]
RESET SERVER
SET SERVER AUTORESTART 0
SET SERVER CPUS 5:15
SET SERVER PRI 160
SET SERVER PROGRAM $[Link]
SET SERVER PROCESS $PWS1.#PATH (ASSOCIATIVE ON)
SET SERVER LINKDEPTH 1
SET SERVER MAXLINKS 10
SET SERVER MAXSERVERS 1
SET SERVER NUMSTATIC 1
SET SERVER HIGHPIN ON
SET SERVER PARAM ETX NO
SET SERVER PARAM GENERIC NO
SET SERVER PARAM MODE PATH
SET SERVER TIMEOUT 20 SECS
SET SERVER CREATEDELAY 30 SECS
SET SERVER DELETEDELAY 1 MINS
SET SERVER HOMETERM \SYS1.$SUDO
ADD SERVER SERVER-PATH

[ ****************************************************************** ]
[ * * ]
[ * BASE FILE SERVERS * ]
[ * * ]
[ ****************************************************************** ]

CMDVOL \SYS1.$DATA.BA60OBJ

[ MENUHELP SERVER ]

RESET SERVER
SET SERVER CPUS 0:15
SET SERVER PROGRAM $[Link]
SET SERVER DELETEDELAY 20 MINS
SET SERVER TIMEOUT 60 SECS
SET SERVER PRI 160
SET SERVER HOMETERM \SYS1.$SUDO
ADD SERVER SERVER-MENUHELP

214
[ NETWORK CONTROL SECURITY PROFILE FILE SERVER ]

RESET SERVER
SET SERVER CPUS 7:8
SET SERVER PROGRAM $[Link]
SET SERVER DELETEDELAY 20 MINS
SET SERVER TIMEOUT 60 SECS
SET SERVER PRI 145
SET SERVER HOMETERM \SYS1.$SUDO
ADD SERVER SERVER-NCSP

[ NETWORK CONTROL SECURITY SPECIFICATION FILE SERVER ]

RESET SERVER
SET SERVER CPUS 3:4
SET SERVER PROGRAM $[Link]
SET SERVER DELETEDELAY 20 MINS
SET SERVER TIMEOUT 60 SECS
SET SERVER PRI 145
SET SERVER HOMETERM \SYS1.$SUDO
ADD SERVER SERVER-NCSS

[ SECURITY FILE SERVER ]

RESET SERVER
SET SERVER CPUS 0:15
SET SERVER PROGRAM $[Link]
SET SERVER DELETEDELAY 20 MINS
SET SERVER TIMEOUT 60 SECS
SET SERVER NUMSTATIC 1
SET SERVER PROCESS $PSEC (ASSOCIATIVE ON)
SET SERVER PRI 160
SET SERVER HOMETERM \SYS1.$SUDO
ADD SERVER SERVER-SEC

[ ****************************************************************** ]
[ * * ]
[ * THE FOLLOWING COMMANDS DEFINE 3270 TERMINALS CONNECTED TO * ]
[ * XPNET VIA TANDEM’S AM3270 PROCESS.
ONE SET OF COMMANDS MUST * ]
[ * BE INCLUDED IN THE PATHCONF FILE FOR EACH 3270 TERMINAL * ]
[ * CONNECTED TO THE SYSTEM VIA THE AM3270 PROCESS. * ]
[ * * ]
[ * THE #A QUALIFIER IS THE NAME ASSIGNED TO THE TERMINAL BY CUP. * ]
[ * * ]
[ ****************************************************************** ]

RESET TERM
SET TERM FILE $AM3270.#A
SET TERM INITIAL T3270-MEGA,TCLPROG $[Link]
SET TERM TCP TCP-30
ADD TERM TERM-A

[ ****************************************************************** ]
[ * * ]
[ * THIS FORM IS USED FOR TANDEM 6520/6530 TERMINALS.
THE NAME * ]
[ * USED IN THE SET TERM FILE COMMAND MUST BE THE SYSGEN NAME OF * ]
[ * THE TERMINAL. * ]
[ * * ]

215
 [ ****************************************************************** ]

RESET TERM
SET TERM FILE $TESTA
SET TERM INITIAL T6520-MEGA, TCLPROG $[Link]
SET TERM TCP TCP-30
SET TERM TYPE T16-6520:0
ADD TERM TERM-TESTA
[ ****************************************************************** ]
[ * * ]
[ * THE T6520-LOGON IS USED FOR BOTH TANDEM 6520 & 6530 TERMINALS. * ]
[ * * ]
[ ****************************************************************** ]

RESET PROGRAM
SET PROGRAM TCP TCP-30
SET PROGRAM TYPE T16-6520 ( INITIAL T6520-MEGA, TCLPROG $[Link], &
DISPLAY-PAGES 1)
SET PROGRAM TYPE IBM-3270 ( INITIAL T3270-MEGA, TCLPROG $[Link])
SET PROGRAM TMF OFF
ADD PROGRAM LOGON-XP31

PATHCOLD file
The PATHCOLD file (PATHCOLD) brings up the Pathway system and builds a new Pathway control file (PATHCTL)
from the Pathway configuration file (PATHCONF). PATHCOLD must be used whenever changes have been made to
the PATHCONF. For information on PATHCTL, see the appropriate HP NonStop Pathway manuals. A sample
PATHCOLD is shown below, followed by a line by line description of the commands in the file.

KILL $PPMN
ASSIGN PATHCTL, $[Link]
PATHMON/NAME $PPMN, NOWAIT, TERM $name, MEM 64, PRI 149, CPU 0/
PATHCOM/IN PATHCONF/$PPMN
PATHCOM/IN PATHSTRT/$PPMN

1. Kills the Pathway monitor process (PATHMON). The ACI Kill utility is located in the ACILIBI subvolume.
2. Defines the location where the Pathway object file (PATHCTL) is to be created.
3. Starts a new PATHMON process and assigns a PPD name of $PPMN. You may need to change the PPD name
to meet your site requirements. PPD naming conventions are described in XPNET components. If you do not
want to start a backup PATHMON process, you should set the CPU number the same as the BACKUPCPU
parameter in the PATHCONF file.
4. Starts a Pathway command language process (PATHCOM) to communicate with the named PATHMON process
and identifies the PATHCONF for the PATHCOM process to use. PATHCONF contains the PATHCOM
commands required to configure and start the Pathway subsystem, including the PATHCOM SET and ADD
commands for the TCPs, server processes, terminals, and logon programs.
5. Directs the PATHCOM process to process the PATHSTRT file (PATHSTRT). PATHSTRT starts the Pathway
TCP, the Logical Network Configuration file (LCONF) Server process, the Security Server process, the NCPI
Server processes, the NCP Server process, and the NCS Server process.

216
PATHCOOL file
The PATHCOOL file (PATHCOOL) brings up the Pathway system without reading the PATHCONF or building a new
PATHCTL. For information on the PATHCTL, see the appropriate HP NonStop Pathway manuals. A sample
PATHCOOL is shown below, followed by a line by line description of the commands in the file.

KILL $PPMN
ASSIGN PATHCTL, $[Link]
PATHMON/NAME $PPMN, NOWAIT, TERM $name, MEM 64, PRI 149, CPU 1/
PATHCOM $PPMN;START PATHWAY COOL!
PATHCOM/IN PATHSTRT/$PPMN

1. Kills the PATHMON process. The ACI Kill utility is located in the ACILIBI subvolume.
2. Defines the location of the existing Pathway object file (PATHCTL).
3. Starts a new PATHMON process and assigns a PPD name of $PPMN. You may need to change the PPD name
to meet your site requirements. PPD naming conventions are described in XPNET components. If you do not
want to start a backup PATHMON process, you should set the CPU number the same as the BACKUPCPU in
the PATHCONF file.
4. Starts the PATHCOM process to communicate with the named PATHMON process, followed by the PATHCOM
command to cool start Pathway. Cool starting Pathway means that the existing PATHCTL is used; a new
PATHCTL is not built.
5. Directs the PATHCOM process to process the PATHSTRT file. PATHSTRT starts the Pathway TCP, the Logical
Network Configuration File (LCONF) Server process, the Security Server process, the NCPI Server processes,
the NCP Server process, and the NCS Server process.

PATHSTRT file
The PATHSTRT file (PATHSTRT) contains PATHCOM commands to start Pathway TCP, the Server-Path interface,
the LCONF Server process, the Security Server process, the NCPI Server processes, the NCP Server process, and
the NCS Server process. PATHSTRT is named in the PATHCOLD and PATHCOOL obey files.

START TCP TCP-30

START SERVER-PATH
START SERVER-LCONF
START SERVER-SEC
START SERVER-NCPI-1A
START SERVER-NCPI-1B
START SERVER-NCPI-2A
START SERVER-NCP
START SERVER-NCS

SHUTDOWN file
The SHUTDOWN file brings down the Pathway system in an orderly manner, stopping all terminals, TCPs, and
server processes. A sample SHUTDOWN file is shown below, followed by a line by line description of the commands
in the file.

217
 PATHCOM/IN PATHSTOP/$PPMN
PATHCOM $PPMN;SHUTDOWN,WAIT
DELAY 15 SECONDS
KILL $PPMN
FUP DEALLOCATE PATHCTL

1. Starts a PATHCOM process to communicate with the named PATHMON process and identifies the PATHSTOP
file for the PATHCOM process to use. PATHSTOP is described later in this section.
2. Stops the Pathway subsystem.
3. Delays 15 seconds to allow shutdown to complete.
4. Kills the PATHMON process and the NCPI Server processes. The ACI Kill utility is located in the ACILIBI
subvolume.
5. Deallocates any unused space originally reserved for PATHCTL. (PATHCTL is always allocated 16 extents, but
typically only uses 1.)

PATHSTOP file
The PATHSTOP file (PATHSTOP) contains PATHCOM commands to stop the Pathway TCP, the LCONF Server
process, the Security Server process, the NCP Server process, and the NCS Server process. PATHSTOP is named
in the SHUTDOWN obey file.

STOP TCP TCP-30

FREEZE SERVER-PATH
STOP SERVER-PATH
STOP SERVER-PATH
FREEZE SERVER-LCONF
STOP SERVER-LCONF
STOP SERVER-LCONF
FREEZE SERVER-SEC
STOP SERVER-SEC
STOP SERVER-SEC
FREEZE SERVER-NCP
STOP SERVER-NCP
STOP SERVER-NCP
FREEZE SERVER-NCS
STOP SERVER-NCS
STOP SERVER-NCS

GOAFT file
The GOAFT file is an obey file used to bring up the logon screen on the terminal from which the file is executed. A
sample GOAFT file is shown below.

PATHCOM $PPMN; RUN LOGON-XP3.1

This file starts a PATHCOM process to communicate with the PATHMON process named in the PATHCOOL and
PATHCOLD obey files. Then it runs the logon program defined in the PATHCONF.

218
XPMON Environment Obey files
The XPNET system can use the HP NonStop XPMON environment to provide process configuration and control.
This section contains examples of several XPMON environment files.

The XPMON environment configuration and files efined in this section reflect the XPNET configuration described in
The XPNET system name and Examples of XPNET obey files. Note, however, that a separate XPMON configuration
must be defined for use by the XPNET node on the second HP NonStop system. Essentially, this XPMON
environment configuration would be a duplicate of the configuration and files described in this section, with
appropriate changes made to reflect the different HP NonStop system.

GOXMON file
The GOXMON file is an TACL obey file that starts the XPMON environment. The XPMON PPD name is defined in
this file, as well as same basic parameters.

clear all
KILL $XPMN
ASSIGN ALT-EVT,\K9.$0
ASSIGN NMAP,\K9.$[Link]
ASSIGN XPCONF,\K9.$[Link].XPCONF0
ASSIGN PRI-EVT,\K9.$0
ASSIGN TRA-EVT,\K9.$0
PARAM RQST-TIMEOUT "30000"
PARAM PRI-TIM-LMT "300"
PARAM ALT-TIM-LMT "300"
PARAM DISCOVERY "ON"
PARAM REFR-ERR-TIMEOUT "10"
PARAM MSGTRACE "OFF"
PARAM XN-TIMEOUT "2000"
PARAM TN-TIMEOUT "6000"
PARAM PRIMARY-XPMON "ON"
RUN $[Link] /NAME $XPMN, nowait, highpin on /

GOXNCXP file
The GOXNCXP file is a TACL file that starts the XNCGEN utility, which in turn uses the XPCONF file to configure the
XPMON environment.

?tacl routine
#frame
#push in_xnc_file out_xnc_prefix out_xnc_ver_len out_listing_file xpnet_subvol

XPCONF file
The XPCONF file is an XML file which contains data used by the XNCGEN utility to configure the XPMON
environment.

<?xml version="1.0"?>

219
<xpconf>
<srvclglobal name="gbl^ncpi">
<assign name="PRI-EVT"> <file>$0</file> </assign>
<assign name="ALT-EVT"> <file>$0</file> </assign>
<assign name="NCSP"> <file>\K9.$[Link] </file> </assign>
<assign name="NCSS"> <file>\K9.$[Link] </file> </assign>
<assign name="NMAP"> <file>\K9.$[Link] </file> </assign>
<param name="DEBUG">OFF</param>
<param name="RQST-TIMEOUT">32767</param>
<param name="XN-TIMEOUT">32767</param>
<param name="PRI-TIM-LMT">300</param>
<param name="ALT-TIM-LMT">300</param>
<param name="ENABLE-AUDIT">DETAIL</param>
<param name="ENABLE-SECURITY">OFF</param>
<param name="XN-LOCK">OFF</param>
<proattr name="PROGRAM">\K9.$[Link]</proattr>
<proattr name="PRI">175</proattr>
<proattr name="HOMETERM">$SUDO</proattr>
<proattr name="DEBUG">OFF</proattr>
<define name="=TCPIP^RESOLVER^NAME">
<attribute name="file">$[Link]</attribute>
</define>
<startup>
<defaultvs>\K9.$[Link]</defaultvs>
<in>$SUDO</in>
<out>$SUDO</out>
</startup>
</srvclglobal>
<serverclass name="server-ncpi-1A">
<get name="gbl^ncpi"></get>
<assign name="NEF"> <file>$[Link].N1ANEF</file> </assign>
<proattr name="PROCESS">$X1AU</proattr>
<proattr name="XPNET">P1A^NODE</proattr>
<proattr name="CPUS">1,2</proattr>
</serverclass>
<serverclass name="server-ncpi-1B">
<get name="gbl^ncpi"></get>
<assign name="NEF"> <file>$[Link].N1BNEF</file> </assign>
<proattr name="PROCESS">$X1BU</proattr>
<proattr name="XPNET">P1B^NODE</proattr>
<proattr name="CPUS">1,2</proattr>
</serverclass>
<serverclass name="server-ncpi-1C">
<get name="gbl^ncpi"></get>
<assign name="NEF"> <file>$[Link].N1CNEF</file> </assign>
<proattr name="PROCESS">$X1CU</proattr>
<proattr name="XPNET">P1C^NODE</proattr>
<proattr name="CPUS">1,2</proattr>
</serverclass>
<serverclass name="server-ncpi-1D">
<get name="gbl^ncpi"></get>
<assign name="NEF"> <file>$[Link].N1DNEF</file> </assign>
<proattr name="PROCESS">$X1DU</proattr>
<proattr name="XPNET">P1D^NODE</proattr>
<proattr name="CPUS">1,2</proattr>
</serverclass>
<serverclass name="server-ncp">
<get name="gbl^ncpi"></get>
<assign name="XPCONF"> <file>\K9.$[Link].XPCONF0</file></assign>
<param name="PRIMARY-XPMON">OFF</param>
<proattr name="PROGRAM">\K9.$[Link]</proattr>

220
 <proattr name="HOMETERM">$SUDO</proattr>
<proattr name="PROCESS">$XNC1</proattr>
<proattr name="NCPI1A">SERVER-NCPI-1A</proattr>
<proattr name="NCPI1B">SERVER-NCPI-1B</proattr>
<proattr name="NCPI1C">SERVER-NCPI-1C</proattr>
<proattr name="NCPI1D">SERVER-NCPI-1D</proattr>
</serverclass>
</xpconf>

PURGENET file
The PURGENET file is a TACL macro which purges all files that were created by the N24SETUP macro.

?TACL MACRO
KILL $XPMN
PURGE $[Link]
PURGE $[Link]
PURGE $[Link]
PURGE $[Link]
PURGE $[Link]
PURGE $[Link].N1ACONF
PURGE $[Link].N1BCONF
PURGE $[Link].N1CCONF
PURGE $[Link].N1DCONF
PURGE $[Link]
PURGE $[Link]
PURGE $[Link]
PURGE $[Link]
FUP PURGE $[Link].*
FUP PURGE $[Link].*
PURGE $[Link]

STOPXMON file
The STOPXMON file is a TACL obey file that stops the XPMON environment.

clear all
KILL $XPMN

Obey files for both environments

The following obey files are used in both the XPMON environment and the Pathway environment.

EMPSPLOCL file
Contains some filtering commands for EMSPERUS so that it will only display events logged by this XPNET and
Pathway system. Note that a more efficient means of filtering events is to use a compiled filter.

221
 PASS WHEN MANAGER = $XPMN
PASS WHEN MANAGER = $X1AN
PASS WHEN MANAGER = $X1BN
PASS WHEN MANAGER = $X1CN
PASS WHEN MANAGER = $X1DN
FAIL ALL OTHERS
PL * - 5 MIN
REALLOG

NEFLIST file
The NEFLIST file contains commands that enable you to generate a command file reflecting your current
configuration. This file is located on the XPNET subvolume.

comment ***************************************************************
comment *
comment XPNET 3.1 "NEFLIST" FILE *
comment *
comment ***************************************************************
comment *
comment This file contains a set of ONCF commands that can be obeyed *
comment from NCS or NCPCOM.
Running this file on an XPNET node will *
comment generate an output file that contains all the Network *
comment objects from that node.
This file can be used to document *
comment the on-line changes made to an XPNET node, or it could be *
comment edited and obeyed to create a new XPNET node. *
comment *
comment To run this file: *
comment Replace "\<system>.<node>" with the Tandem system name *
comment and the node name of the XPNET node to be saved. *
comment Replace "outfile" with a valid Tandem file name. *
comment If there are no tributary stations in the configuration *
comment for this node, the following message will be displayed *
comment in the outfile and can be ignored: *
comment Station \<system>.<node>.* info failed, no obj met *
comment filter criteria *
comment *
comment From an NCS or an NCPCOM prompt type: *
comment OBEY NEFLIST *
comment *
comment An NCS or NCPCOM prompt is displayed when all the commands *
comment are completed. *
comment *
comment ***************************************************************
assume node \<system>.<node>
info /out outfile/ node ,obeyform
info /out outfile/ link * ,obeyform
info /out outfile/ device * ,obeyform
info /out outfile/ process * ,obeyform
info /out outfile/ line * ,obeyform
info /out outfile/ station * ,obeyform,controller
info /out outfile/ station * ,obeyform,tributary
info /out outfile/ dest * ,obeyform,added

222
GONCP file
The following is a sample obey file that you can use to start the NCPCOM utility:

RUN $[Link]

This sample file specifies the volume and subvolume on which the NCPCOM utility is located. The volume and
subvolume must be included if the location of the NCPCOM utility is not included in the PMSEARCHLIST at your site
or if you are starting the utility from a location other than the volume and subvolume where the utility is located.
Because the location is included in the command, the RUN literal must be included also.

STRTLOG TACL Macro

The following is an example of a TACL macro you can use to start the EMSperus utility as a logging mechanism.

?TACL MACRO
== #########################################################
== # #
== # N O T E: THIS IS YOUR OBEY FILE TO START EMSPERUS #
== # FOR YOUR DVLP SYSTEM. #
== # %1% - THE TERMINAL NAME TO RUN EMSPERUS FROM#
== # %2% - THE EMSPERUS PPD NAME OTHER THAN STD. #
== #########################################################
#FRAME
PUSH out_loc ppd_nam
[#IF [#EMPTY %1%] |THEN|
#SET out_loc [#MYTERM]
|ELSE|
#SET out_loc %1%
]
[#IF [#EMPTY %2%] |THEN|
#SET ppd_nam $ppd-name
|ELSE|
#SET ppd_nam %2%
]
[#IF NOT [#EMPTY [#DEFINENAMES =_EMS_TEMPLATES]] |THEN|
DELETE DEFINE =_EMS_TEMPLATES
]
ADD DEFINE =_EMS_TEMPLATES, FILE $[Link]
[#IF [#PROCESSEXISTS [ppd_nam]] |THEN| KILL [ppd_nam]
]
#PUSH prog
[#IF [#FILEINFO /EXISTENCE/ $[Link]] |THEN|
#SET prog $[Link]
|ELSE|
#SET prog EMSPERUS
]
[prog] /IN EMSPIN, NOWAIT, TERM $SUDO, OUT [out_loc], PRI 125, NAME [ppd_nam]/
#UNFRAME

STOPLOG Obey file

The following is an example of an obey file that stops the EMSperus utility.

223
 KILL $ppd-name

In this example, the ppd-name variable is the PPD name of the EMSperus utility. The ACI Kill utility is located in the
ACILIBI subvolume.

224
Appendix B: Sample XPNET node configuration
This is a sample configuration for an XPNET node. This configuration contains SET and ADD commands to define
and add a node, links to 3 other nodes, 14 processes, 4 devices, 7 lines, and 7 stations. These commands can be
entered in an edit file, and the file can then be processed from a network control facility using the OBEY command.

ASSUME SYSNAME \SYS1

RESET NODE
SET NODE CPU 9
SET NODE BCPU 5
SET NODE PPRI 160
SET NODE BPRI 180
SET NODE QUETHRESHOLD 300
SET NODE BACKUPTYPE HOT
SET NODE STARTUP AUTOMATIC
SET NODE LOGFILE $0
SET NODE ALTLOGFILE $0
SET NODE LOGNQAT 40
SET NODE LOGNQMT 50
SET NODE LOGNQMI 90
SET NODE LOGEQAT 100
SET NODE LOGEQMT 150
SET NODE LOGEQMI 95
SET NODE UDQAT 8
SET NODE UDQMT 20
SET NODE UDQMI 90
SET NODE CJ ON
SET NODE CJA $DATA.P1ANCJA
SET NODE CJB $DATA.P1ANCJB
SET NODE CJC $DATA.P1ANCJC
SET NODE NOMTODISK ON
SET NODE NOMA $DATA.P1ANNOMA
SET NODE NOMB $DATA.P1ANNOMB
SET NODE NOMC $DATA.P1ANNOMC
SET NODE MONNOM ON
SET NODE MONQAT ON
SET NODE MONSTATES ON
SET NODE EXTPAGES 4096
SET NODE PROGRAM $[Link]
SET NODE STARTOPTIONS "\SYS1.$DATA.PRO1DATA.L1CONF"
SET NODE EVT^UNAVAIL ON
SET NODE EVT^OTHER ON
SET NODE SERVERCLASS SERVER-NCPI-1A
SET NODE PATHMON $PPMN
SET NODE MAXPROMSG 4096
SET NODE HIGHPIN ON
SET NODE PPD $P1AN
ADD NODE P1A^NODE

ASSUME NODE P1A^NODE

RESET LINK
SET LINK PPD $P1BN
SET LINK STARTUP AUTOMATIC
SET LINK QAT 20
SET LINK UCQUEUE LINKQUEUE
SET LINK UCRATE LINKRATE

225
SET LINK UCSTATE LINKSTATE
ADD LINK P1A^LINK^P1B

RESET LINK
SET LINK PPD $P2AN
SET LINK STARTUP AUTOMATIC
SET LINK QAT 20
SET LINK UCQUEUE LINKQUEUE
SET LINK UCRATE LINKRATE
SET LINK UCSTATE LINKSTATE
ADD LINK P1A^LINK^P2A

RESET LINK
SET LINK PPD \SYS2.$P1AN
SET LINK STARTUP AUTOMATIC
SET LINK QAT 20
SET LINK UCQUEUE LINKQUEUE
SET LINK UCRATE LINKRATE
SET LINK UCSTATE LINKSTATE
ADD LINK P1A^LINK^P1A

RESET PROCESS
SET PROCESS BCPU 2
SET PROCESS PROGRAM $[Link]
SET PROCESS PPD $AP01
SET PROCESS PRIORITY 170
SET PROCESS CPU 1
SET PROCESS STARTUP AUTOMATIC
SET PROCESS QAT 100
SET PROCESS UCQUEUE APROCQUEUE
SET PROCESS UCRATE APROCRATE
SET PROCESS UCSTATE APROCSTATE
SET PROCESS QMT 150
SET PROCESS SAVEABEND OFF
SET PROCESS QMI 85
SET PROCESS CLASS APROC:COPY1
SET PROCESS SERVICE TIME
ADD PROCESS P1A^APROC1

SET PROCESS PPD $AP02

SET PROCESS CPU 3
SET PROCESS CLASS APROC:COPY2
ADD PROCESS P1A^APROC2

SET PROCESS PPD $AP03

SET PROCESS CPU 4
SET PROCESS CLASS APROC:COPY3
ADD PROCESS P1A^APROC3

SET PROCESS PPD $AP04

SET PROCESS CPU 5
SET PROCESS CLASS APROC:COPY4
ADD PROCESS P1A^APROC4

RESET PROCESS
SET PROCESS BCPU 3
SET PROCESS PROGRAM $[Link]
SET PROCESS PPD $BP01
SET PROCESS PRIORITY 135
SET PROCESS CPU 2
SET PROCESS STARTUP DEMAND

226
SET PROCESS QAT 100
SET PROCESS UCQUEUE BPROCQUEUE
SET PROCESS UCRATE BPROCRATE
SET PROCESS UCSTATE BPROCSTATE
SET PROCESS QMT 150
SET PROCESS SAVEABEND OFF
SET PROCESS QMI 90
SET PROCESS CLASS BPROC:COPY1
SET PROCESS SERVICE AUTH
ADD PROCESS P1A^BPROC1

SET PROCESS PPD $BP02

SET PROCESS CPU 3
SET PROCESS CLASS BPROC:COPY2
ADD PROCESS P1A^BPROC2

SET PROCESS PPD $BP03

SET PROCESS CPU 4
SET PROCESS CLASS BPROC:COPY3
ADD PROCESS P1A^BPROC3

SET PROCESS PPD $BP04

SET PROCESS CPU 5
SET PROCESS CLASS BPROC:COPY4
ADD PROCESS P1A^BPROC4

SET PROCESS PPD $BP05

SET PROCESS CPU 6
SET PROCESS CLASS BPROC:COPY5
ADD PROCESS P1A^BPROC5

SET PROCESS PPD $BP06

SET PROCESS CPU 7
SET PROCESS CLASS BPROC:COPY6
ADD PROCESS P1A^BPROC6

RESET PROCESS
SET PROCESS BCPU 4
SET PROCESS PROGRAM $[Link]
SET PROCESS PPD $CP01
SET PROCESS PRIORITY 165
SET PROCESS CPU 8
SET PROCESS STARTUP AUTOMATIC
SET PROCESS QAT 70
SET PROCESS UCQUEUE OTHRPROCQUEUE
SET PROCESS UCRATE OTHRPROCRATE
SET PROCESS UCSTATE OTHRPROCSTATE
SET PROCESS QMT 100
SET PROCESS SAVEABEND OFF
SET PROCESS QMI 80
SET PROCESS CLASS OTHRPROC
SET PROCESS SERVICE REPORT1
ADD PROCESS P1A^CPROC

SET PROCESS PROGRAM $[Link]

SET PROCESS PPD $DP01
SET PROCESS CPU 4
SET PROCESS SERVICE REPORT2
ADD PROCESS P1A^DPROC

SET PROCESS PROGRAM $[Link]

227
SET PROCESS PPD $EP01
SET PROCESS PRIORITY 160
SET PROCESS CPU 1
SET PROCESS STARTUP DEMAND
SET PROCESS QAT 50
SET PROCESS QMT 80
SET PROCESS QMI 75
SET PROCESS SERVICE REPORT3
ADD PROCESS P1A^EPROC

SET PROCESS PROGRAM $[Link]

SET PROCESS PPD $FP01
SET PROCESS CPU 5
SET PROCESS SERVICE REPORT4
ADD PROCESS P1A^FPROC

RESET DEVICE
SET DEVICE RECVLEN 512
SET DEVICE XMITLEN 512
ADD DEVICE D1A^LU62

RESET DEVICE
SET DEVICE RECVLEN 650
SET DEVICE XMITLEN 650
ADD DEVICE D1A^OSI

RESET DEVICE
SET DEVICE INPUTFORMAT TXT
SET DEVICE OUTPUTFORMAT TXT
SET DEVICE POLLFORMAT EOT P1 P2
SET DEVICE RECVLEN 4095
SET DEVICE SELECTFORMAT EOT P1 P2
SET DEVICE XMITLEN 4095
ADD DEVICE D1A^PWS

RESET DEVICE
SET DEVICE RECVLEN 4095
SET DEVICE XMITLEN 4095
SET DEVICE ADD DESTSTRING 1,P1A^DPROC, 2,%hA0
SET DEVICE ADD DESTSTRING 2,P1A^EPROC, 2,%hA1
SET DEVICE ADD PROTOCOLSTRING 1,ITI,10,%hF1
SET DEVICE ADD PROTOCOLSTRING 2,ATALLA,10,%hF2
SET DEVICE ADD PROTOCOLSTRING 3,DATAFONO,10, "?"
ADD DEVICE D1A^X25

RESET LINE
SET LINE ATIMER 0
SET LINE BTIMER 0
SET LINE ERANALYSIS 30
SET LINE PORT $APC
SET LINE LCLLUNAME APCLU1
SET LINE PRTLUNAME PARTLU1
SET LINE UCRATE LU62LINRATE
SET LINE UCSTATE LU62LINSTATE
SET LINE UCQUEUE LU62LINQUEUE
SET LINE CLASS GROUP1
SET LINE PROTOCOL LU6.2
ADD LINE L1A^LU621

SET LINE CLASS GROUP2

ADD LINE L1A^LU622

228
RESET LINE
SET LINE ATIMER 0
SET LINE BTIMER 0
SET LINE DUPLEX HALF
SET LINE ERANALYSIS 30
SET LINE GIVETOKENS ON
SET LINE MICALL ON
SET LINE PORT $AX08
SET LINE UCRATE OSILINRATE
SET LINE UCSTATE OSILINSTATE
SET LINE UCQUEUE OSILINQUEUE
SET LINE CLASS GROUP1
SET LINE PROTOCOL OSI5
ADD LINE L1A^OSI1

SET LINE CLASS GROUP2

ADD LINE L1A^OSI2

RESET LINE
SET LINE ATIMER 0
SET LINE BTIMER 0
SET LINE DUPLEX HALFREM
SET LINE CINIT IMMEDIATE
SET LINE PORT $PWS1.#[Link]
SET LINE CMETHOD ACCEPT
SET LINE EXPDATA ROUTE
SET LINE FMM STATUS
SET LINE CLASS PATH
SET LINE PROTOCOL CTS
ADD LINE L1A^PWS

RESET LINE
SET LINE ATIMER 1
SET LINE BTIMER 0
SET LINE ERANALYSIS 30
SET LINE PORT $AX10
SET LINE VERDTE OFF
SET LINE WFCALL ON
SET LINE UCRATE X25LINRATE
SET LINE UCSTATE X25LINSTATE
SET LINE UCQUEUE X25LINQUEUE
SET LINE CLASS GROUP1
SET LINE PROTOCOL X.25
ADD LINE L1A^X251

SET LINE CLASS GROUP2

ADD LINE L1A^X252

RESET STATION
SET STATION AUTOPRI 200
SET STATION DESTINATION AUTH
SET STATION MODENAME MODEA
SET STATION LCLTPNAME TPREMOTE
SET STATION PRTTPNAME TPLOCAL
SET STATION UCQUEUE LU62STAQUEUE
SET STATION UCRATE LU62STARATE
SET STATION UCSTATE LU62STASTATE
SET STATION CLASS GROUP1
SET STATION DEVICE LU62^DEV
SET STATION LINENAME \SYS1.P1A^NODE.L1A^LU621

229
ADD STATION S1ALU621

SET STATION CLASS GROUP2

SET STATION LINENAME \SYS1.P1A^NODE.L1A^LU622
ADD STATION S1ALU622

RESET STATION
SET STATION DESTINATION TIME
SET STATION UCQUEUE OSISTAQUEUE
SET STATION UCRATE OSISTARATE
SET STATION UCSTATE OSISTASTATE
SET STATION CLASS GROUP1
SET STATION DEVICE OSI^DEV
SET STATION LINENAME \SYS1.P1A^NODE.L1A^OSI1
SET STATION USERDATA OFFSET 0 "OSI" %HFE 0 5 "LOCAL" %HFD 0 6 "REMOTE" %HFC
SET STATION USERDATA OFFSET 21 0 %H13 "CALLING REF CN-SPDU" %HFB 0 %H12
SET STATION USERDATA OFFSET 45 "COMMON REF CN-SPDU" %HFA 0 %H16 "ADDITI"
SET STATION USERDATA OFFSET 72 "ONAL REF CN-SPDU" %HF9 0 %H10 "USERDATA"
SET STATION USERDATA OFFSET 99 " CN-SPDU" %HF8 0 %H12 "CALLED REF AC-SP"
SET STATION USERDATA OFFSET 126 "DU"
ADD STATION S1AOSI1

SET STATION CLASS GROUP2

SET STATION LINENAME \SYS1.P1A^NODE.L1A^OSI2
ADD STATION S1AOSI2

RESET STATION
SET STATION DESTINATION P1A^EPROC
SET STATION CLASS PATH
SET STATION DEVICE D1A^PWS
SET STATION LINENAME \SYS1.P1A^NODE.L1A^PWS
ADD STATION S1APWS

RESET STATION
SET STATION DESTINATION P1A^DPROC
SET STATION UCQUEUE X25STAQUEUE
SET STATION UCRATE X25STARATE
SET STATION UCSTATE X25STASTATE
SET STATION CLASS GROUP1
SET STATION DEVICE X25^DEV
SET STATION LINENAME \SYS1.P1A^NODE.L1A^X251
ADD STATION S1AX251

SET STATION CLASS GROUP2

SET STATION LINENAME \SYS1.P1A^NODE.L1A^X252
ADD STATION S1AX252

230
Appendix C: Network control command security
This section provides information about command security profiles. It includes a description of network control
command security, the Network Control Security Profile file (NCSP), and the Network Control Security Specification
file (NCSS). The descriptions of the NCSP and NCSS screens include information about all the fields displayed on
the screens. The descriptions also define functions specific to the screens.

Network control commands

Network control command security is configurable. At its basic level, access to network control commands is
determined by access to a network control facility. If you have access to a network control facility, you can execute
any network control command. Two additional network control command security measures can be taken, either
separately or in conjunction with each other. These measures are to limit network control command access by
command and to audit network control commands.

Command access limitations allow you to specify for each user whether the user has access to each network control
command. When command access limitations are enabled, users are assigned security profiles in their records. The
security profile indicates, for each network control command, whether the user has access to the network control
command. More than one NCSS record can exist for each user. This enables independent security profiles for
individual XPNET nodes.

Command auditing creates an audit trail of network control command activity. When auditing is enabled by itself
(without command access limitations), an event message is generated each time a network control command is
executed. The event message identifies the user who issued the command, the XPNET node affected, the terminal
the command was issued from, and the command that was performed.

When command auditing and command access are used together, the security profile controls not only whether the
user can perform the command, but also whether execution of the command is audited. In this way, system
administrators can audit selected commands or users. For example, new network control operators could be
assigned a special security profile that gives audited access to some or all commands. Or, security profiles could be
created that allow users to execute inquiry commands without being audited, while commands that change the
system configuration are audited.

Enable command access limitations

Enable command access limitation using the ENABLE-SECURITY parameter in the definition for the NCPI Server
process in the PATHCONF for the Pathway environment, or XPCONF for the XPMON environment. The following
values are valid for the ENABLE-SECURITY parameter. The default is ON.

ON = Security is enabled.

OFF = Security is disabled.

DETAIL = Security is enabled, and invalid logon attempts are logged to

EMS.

If the value of this parameter is set to DETAIL, the NCPI Server process generates an event message when a SET
USER command fails because an invalid user name or password was entered or the password has expired.

231
If security is enabled, an additional parameter can be configured to govern whether security violation messages are
returned for commands that reference objects on an XPNET node to which the user does not have command
access. This parameter is the XN-LOCK parameter. Valid values are as follows. The default is ON.

ON = Security violation messages are not returned for objects on the

node to which the user does not have access.

OFF = Security violation messages are returned for each object on the
node to which the user does not have access.

If a user attempts to issue a command referencing multiple XPNET nodes and the user does not have command
access to one or more of the nodes, this parameter specifies if invalid security messages are generated for each
object. If the XN-LOCK parameter is set to OFF, a security violation message is generated for each object
referenced by the command. If the XN-LOCK parameter is set to ON, no security violation message is generated. In
essence, setting the XN-LOCK parameter to ON prevents the user from learning the names of objects on nodes to
which he or she does not have command access.

In addition, two files are required to limit network control command access. These files are the Network Control
Security Profile file (NCSP) and the Network Control Security Specification file (NCSS). Command access limitations
(Y for access, N for no access, A for audit access, U for unrestricted, and V for view unrestricted) are specified on
the NCSP screen. SEC screen 4 (which accesses the NCSS) allows you to specify the network control security
profile to be associated with a user’s security record.

Enable command auditing

Enable command auditing using the ENABLE-AUDIT parameter in the definition for the NCPI Server process in the
PATHCONF for the Pathway environment, or XPCONF for the XPMON environment. The following values are valid
for the ENABLE-AUDIT parameter. The default is OFF. By itself, command auditing does not require any setup in the
security files.

ON = Enables command auditing by generating one event message for

each command issued.

OFF = Disables command auditing.

DETAIL = Enables command auditing by generating one event message for

each object involved in a multiple-object command. Detail
auditing applies only to object management commands.

Network control security profile file

The Network Control Security Profile File (NCSP) allows you to set up network control security profile records. The
security profile records indicate whether each network control command can be executed and whether the command
is audited when it is executed. After a security profile is created and stored in the NCSP, it can be associated, on
SEC screen 4, with the security record for one or more users.

232
 Any changes made to an NCSP profile affect all users with that security profile named in their
security records. For example, if there are five users with the NCSP profile NET OPERATOR
NOTE specified in their security records and you increase the number of commands accessible to the
NET OPERATOR profile, all five users have increased access. To increase the access for only one
of the five users, you must assign a different security profile to that one user.

Access to network control commands depends on how your system is configured. The NCSP is only used when the
parameter ENABLE-SECURITY is set to the value ON in the declaration for each NCPI Server process in the
PATHCONF for the Pathway environment, or XPCONF for the XPMON environment. Setting the ENABLE-
SECURITY parameter to ON allows you to specify whether the user has access to the command (N = no access, Y
= access, and U = unrestricted). If the additional parameter ENABLE-AUDIT is set to ON or DETAIL, audited access
codes A = audited access and V = unrestricted are available. Possible command responses are as follows:

• If the user has access to the command, he or she can execute the command.
• If the user has no access to a command, he or she cannot execute the command. If the ENABLE-AUDIT
parameter is specified in the PATHCONF for the Pathway environment, or XPCONF for the XPMON
environment, each time the command is attempted, an event message is generated identifying the XPNET
node, command, user name, and the terminal from which the command was attempted.
• If the user has no access to a command and the ENABLE-AUDIT parameter is not specified in the PATHCONF
for the Pathway environment, or XPCONF for the XPMON environment, an event message is not generated
when the command is attempted.
• If the user has audit access to the command and the ENABLE-AUDIT parameter is specified in the PATHCONF
for the Pathway environment, or XPCONF for the XPMON environment, he or she can execute the command
and an event message is generated identifying the user and the command that was executed.
• If the user has audit access to the command and the ENABLE-AUDIT parameter is not specified in the
PATHCONF for the Pathway environment, or XPCONF for the XPMON environment, he or she can execute the
command, but an event message is not generated when the command is executed.

The NCSP screen is shown below, followed by descriptions of its fields and function keys. In the example, the first
page of node commands for the OPERATOR profile record is displayed on the screen.

233
PROFILE NAME
The name of a specific network control security profile.
Field Length: 1-16 alphanumeric characters
Required Field: Yes
Default Value: No default value

OBJECT TYPE
The type of object for which network control commands are displayed. The object type specified in this field must
be one of the following:
DEST
DEVICE
EXTERNAL
LINE
LINK
NODE
PROCESS
STATION
Field Length: 1-16 alphabetic characters
Required Field: Yes
Default Value: NODE

COMMAND
A network control command keyword. This field identifies the network control command for which access
information is being displayed.
Field Length: System-protected

234
OPTION
The name of an attribute, directive, or macro that is associated with the network control command displayed.
Field Length: System-protected

ACCESS
A code indicating the access level for the named command and attribute. Valid values are as follows:

Y = Access. A user with this access level can execute this command. No event messages are
generated when the command is executed.

N = No access. A user with this access level cannot execute this command. If the ENABLE-
AUDIT parameter is set to ON or DETAIL, each time thecommand is attempted, an event
message is generated indicating the XPNET node, command, user name, and the terminal
from which the command was attempted.

A = Audited access. A user with this access level can execute this command. If the ENABLE-
AUDIT parameter is set to ON or DETAIL, each time the command is executed, an event
message is generated indicating the XPNET node, command, user name, and the terminal
from which the command was executed. If the ENABLE-AUDIT parameter is set to OFF, this
setting is equivalent to the access code value Y.

U = Unrestricted access. A user is allowed to execute this command without a valid password.

V = View unrestricted. A user is allowed to execute an audited command without a valid

password.

R = Replicated. Used by the DR (disaster recovery) process to indicate which attributes are
replicated in both the primary and DR nodes.

R should only be used for DRPRO. If an R is specified it will be treated as a

"N" and cause any command with this access value to fail with a security
NOTE error. So different NCSP records (PROFILES) should be configured to
manage DRPRO replication and ONCF security. These could be in the
same or different NCSP files.

Field Length: 1 alphabetic character

Required Field: Yes
Default Value: N

DESCRIPTION
A text description of the command and attribute function.
Field Length: System-protected

Function keys
The function keys used on the NCSP screen are shown in the following table. The first column shows the function
keys. The second column describes the functions that can be accomplished with these keys on the NCSP screen.

235
Key Description
F1 VALIDATE DATA — Checks the data that has been entered on the screen for
errors.

F2 READ RECORD — Reads a record from the file in which the user is working.

F3 ADD RECORD — Adds a record to the file in which the user is working. The
record added must be unique within the file.

F4 DELETE RECORD — Deletes a record from the file in which the user is working.

F5 UPDATE RECORD — Changes a record already in the file in which the user is
working.

F6 READ NEXT RECORD — Reads the next record in the file in which the user is
working.

F8 CLEAR SCREEN — Clears any values on the screen in which the user is working
and replaces them with spaces or default values. This key impacts all screens
associated with the file currently being accessed, including the current screen,
any previous screens, and any remaining screens. Once this function has been
used, the update function cannot be completed until the read function has been
completed. The key fields are also cleared to spaces or replaced with default
values, so this information must be reentered before the record can be read.

F9 NEXT PAGE OF COMMANDS — Displays the next page of network control

command access information for the object type entered in the OBJECT TYPE
field.

F10 PRINT SCREEN — Sends the screen currently being displayed to the spooler
location indicated on the Logon screen.

F11 PREV PAGE OF COMMANDS — Displays the previous page of network control
command access information for the object type entered in the OBJECT TYPE
field.

F12 DISPLAY HELP — Displays the Help screen. The Help screen displayed depends
on the screen currently being viewed. The Help screen contains information about
function keys or menu options.

F13 CHANGE CURRENT LNET — Changes the current logical network while in a file.

236
Key Description
F16 EXIT OR GOTO — Displays the previous screen or menu or returns you to SEC
screen 4.

If you accessed the NCSP by pressing the Shift-F7 key on SEC screen 4, this key
returns you to SEC screen 4. When using the F16 key to return to SEC screen 4,
the FILE DESTINATION field must be left blank. The profile that was displayed on
the NCSP screen is then displayed on SEC screen 4. To add this profile to the
SEC, however, you must update the SEC record.

If you accessed the NCSP from a menu or by placing NCSP in the FILE
DESTINATION field, F16 takes you to the last menu displayed.

Shift-F2 RETRIEVE COMMANDS BY OBJECT TYPE — Displays the network control

commands for the object type entered in the OBJECT TYPE field.

A hyphen connecting two keys indicates the keys are pressed

NOTE simultaneously (for example, Shift-F2 indicates the Shift and F2
keys are pressed simultaneously).

Shift-F16 LOGOFF — Logs the user off the Pathway environment or the XPMON
environment. When this function is used while a user is accessing the
environment, a blank Logon screen is displayed. If the Logon screen is displayed
when this function is used, the Logon screen continues to be displayed or a TACL
prompt is displayed, depending upon how the terminal is set up.

Adding an NCSP record

You must add a new security profile record to the NCSP any time a user is given command access different from the
command access specified in an existing security profile.

The NCSP is a single record with a key of PROFILE NAME. Each object type is part of the same
NOTE
record, not a new record.

Perform the following steps to add an NCSP record:

1. Access the NCSP screen. There are two methods of accessing the NCSP, depending on the screen that you are
currently displaying.
◦ If you are displaying SEC screen 4, access the NCSP by pressing Shift-F7. The NCSP screen is displayed.
The profile name used on SEC screen 4 is carried to the PROFILE NAME field on the NCSP screen.
◦ If you are displaying any other screen, enter NCSP in the FILE DESTINATION field at the bottom of the CRT
access screen. From a menu screen, press the F1 key. From a file screen, press F16. The NCSP screen is
displayed and the PROFILE NAME field is blank.
2. Enter the new profile name in the PROFILE NAME field.
3. Press F3 to add the record. The object type defaults to NODE.

237
 4. Assign access to the node commands.
a. Enter the access code (N, Y, A, U, or V) you want to assign for each command in the ACCESS field. When
the access is assigned for all of the commands displayed, display the next page of node command
information by pressing F9.
b. Repeat the previous step until access has been assigned for all pages of node command information.
5. Assign access for the remaining object types and commands by performing the following steps:
a. Enter one of the following values in the OBJECT TYPE field and press Shift-F2:

DEST
DEVICE
EXTERNAL
LINE
LINK
PROCESS
STATION

b. Enter the access code (N, Y, A, U, or V) you want to assign for each command in the ACCESS field. When
the access is assigned for all of the commands displayed, display the next page of command information for
the current object type by pressing F9.
c. Repeat the previous step until you have assigned access for all pages of the current object type command
information.
d. Repeat steps 4a through 4c to assign access for the remaining object types.
6. Press F5. XPNET displays a message at the bottom of the screen to indicate whether the information you
entered has been updated successfully.

Updating an existing NCSP record

The command access given to an individual network operator or a group of network operators does not always
remain the same. A change in job function may require different access from what was initially assigned. Also, when
new network control commands are added to the system, command access needs to be assigned for the new
commands.

To update an existing NCSP profile, perform the following steps on the NCSP screen:

1. Enter the profile name of the security profile that needs updating in the PROFILE NAME field.
2. Press F2 to read the record. The object type defaults to NODE.
3. Update the access assigned to the node commands.
a. Enter the access code (N, Y, A, U, or V) you want to update for each command in the ACCESS field. When
the access is updated for all of the commands displayed, display the next page of node command
information by pressing F9.
b. Repeat the previous step until access has been updated for all pages of node command information.
4. Update the access assigned for the remaining object types and commands by performing the following steps:
a. Enter one of the following values in the OBJECT TYPE field and press Shift-F2:

DEST
DEVICE

238
 EXTERNAL
LINE
LINK
PROCESS
STATION

b. Enter the access code (N, Y, A, U, or V) you want to update for each command in the ACCESS field. When
the access is updated for all of the commands displayed, display the next page of command information for
the current object type by pressing F9.
c. Repeat the previous step until access has been updated for all pages of the current object type command
information.
d. Repeat steps 4a through 4c to assign access for the remaining object types.
5. Press F5. A message is displayed at the bottom of the screen to indicate whether the information you entered
has been updated successfully.

Copying an NCSP record

To copy an existing NCSP profile to another security profile, perform the following steps on the NCSP screen:

1. Enter the profile name of the security profile you want to copy from in the PROFILE NAME field.
2. Press F2 to read the record.
3. Edit the PROFILE NAME field by entering the new profile name.
4. Add the new security profile record by pressing F3.

Network control security specification file

SEC screen 4 enables you to specify the network control security profile to be associated with a user’s security
record. The security profile controls the access to and auditing of network control commands. The user’s security
records containing user name, XPNET node name, security profile name, and password are stored in the Network
Control Security Specification File (NCSS). The security profiles themselves are stored in the Network Control
Security Profile File (NCSP). This allows the same security profile to be assigned to multiple users. The security
profile must be added to the NCSP before a profile can be specified for a user.

Access to network control commands depends on how your system is configured. SEC screen 4 is used only when
the ENABLE-SECURITY parameter is set to ON in the declaration for the NCPI Server process in the PATHCONF
for the Pathway environment, or XPCONF for the XPMON environment.

Command access information can only be changed from the NCSP screen, which can be accessed from the Base
Product Menu, by pressing the Shift-F7 key from SEC screen 4, or by entering NCSP in the FILE DESTINATION
field and pressing the F16 key.

A user can have multiple security records each associated with unique security profiles for individual XPNET nodes.
For example, a new network operator could be assigned one security record associated with a security profile that
allows audited command access to a test network and another security record associated with a security profile that
allows only inquiry access in a production network.

In this example, the new network operator would have one security record with an associated security profile that
allows audited access to some or all commands for each object type within the XPNET node that is part of the test

239
network. This new network operator would have another security record that associated a different security profile
that allows the user to execute only inquiry commands within the XPNET node that is part of the production network.

If there is no need to create security profiles for individual XPNET nodes, ACI recommends creating a default
security profile. A security record with the value of 16 asterisks (*) for the NODE field acts as a default security
profile for XPNET nodes when a security profile for a specific XPNET node does not exist.

An example of SEC screen 4 is shown below. By default, a SUPER/SUPER user can execute all network control
commands. If the ENABLE-SECURITY parameter is set to ON, SUPER/SUPER requires an NCSS record. If
network control command auditing is enabled and SUPER/SUPER does not have an NCSS record, all commands
executed by SUPER/SUPER are audited on the network log. SEC screen 4 fields and functions are described
following the illustration.

The NET24-XPNET product does not require that every user have an NCSS record. However, if the
NOTE user has the ability to add security records for other users, ACI recommends that the user have an
NCSS record. A user who does not have an NCSS record cannot use the add like function.

ALIAS
A name that is associated with a uniquely identified user. This is the name that must be entered in the USER field
of the NCS screen and in the SET USER or SET LOGON command when using NCPCOM.

Field Length: 1-16 alphanumeric characters

Required Field: Yes
Default Value: No default value

240
NODE
The name of the XPNET node to which this security profile applies. This field can contain one of the following
three values:

• The symbolic name of an XPNET node (for example, P1A^NODE).

• The keyword EXTERNAL (for securing access to EXTERNAL entities).
• 16 asterisks (*) which act as the default profile for XPNET nodes when a profile for a specific XPNET node
cannot be found.

Field Length: 1-16 alphanumeric characters

Required Field: Yes
Default Value: No default value

NEW PASSWORD
A field that allows the entry of a new password for the identified user. The password cannot include spaces or
commas and cannot consist of a single repeated character unless set to all spaces. New passwords entered on
the NCSS screen do not follow the limitations set by the password requirements fields configured on the same
NCSS screen. A password set to all spaces is considered to be valid for issuing network control commands only
if security is not enabled. Passwords are case-sensitive.
If security is enabled and a new NCSS record is added for a user with the password requirements field MAX
DAYS BEFORE CHANGE having a nonzero value, the user is required to change their password with a SET
PASSWORD command before being allowed to perform any commands from NCS or NCPCOM.
If a record is updated with a new password when the current value in the MAX INVALID COUNT field is nonzero
or at the same time that you change the MAX INVALID COUNT field to a nonzero value, the new password is
applied to all records for this user name. If you change the password and the current value in the MAX INVALID
COUNT field is zero, the new password is applied only to the current record.

Field Length: 1-16 alphanumeric characters

Required Field: No
Default Value: Password from an existing security record for the identified user, or spaces if a security record
does not already exist.

COMMANDS PROFILE
The name of a network control security profile that is defined in the NCSP.

Field Length: 1-16 alphanumeric characters

Required Field: Yes
Default Value: No default value
USAGE RESTRICTIONS

START TIME
The time the user with the specified alias can begin accessing the XPNET Online Network Control Facility
(ONCF). Valid values range from 0000, which represents midnight, to 2359, which represents 11:59 p.m. The
value can contain the colon (that is, 23:59) or can be placed in the first four positions of the field (that is, 2359). If
a colon is not used, the system automatically displays the time with a colon when the field is added or updated.

Field Length: 3-5 numeric characters with embedded colon (:)

Required Field: Yes
Default Value: 00:00

241
DAYS: MO, TU, WE, TH, FR, SA, SU
These fields represent the days of the week for allowing or restricting user access to the XPNET Online Network
Control Facility (ONCF).

MO = Monday

TU = Tuesday

WE = Wednesday

TH = Thursday

FR = Friday

SA = Saturday

SU = Sunday

Valid values are as follows:

Y = Yes, allow the user access to

perform ONCF commands on that
day of the week.

N = No, do not allow the user access to

perform ONCF commands on that
day of the week.

Field Length: 1 alphabetic character

Required Field: Yes
Default Value: N

END TIME
The time after which the user with the specified alias cannot access the XPNET Online Network Control Facility
(ONCF). Valid entries range from 0000, which represents midnight, to 2359, which represents 11:59 p.m. The
value can either contain the colon (that is, 23:59) or can be placed in the first four positions of the field (that is,
2359). If a colon is not used, the system automatically displays the entry with a colon when this field is added or
updated. If the default value of 00:00 is entered in both this and the START TIME field, the specified user cannot
log on to the BASE24 system. To give the specified user 24-hour access to the BASE24 system, enter 0000 or
00:00 in the START TIME field and 2359 or 23:59 in this field.

Field Length: 3-5 numeric characters with embedded colon (:)

Required Field: Yes
Default Value: 00:00

242
INACTIVITY LIMIT FOR AUTO LOGOFF
The number of minutes of NCS or NCPCOM inactivity that is allowed before the user is automatically logged off.
A user who is logged off because of this timer must perform a valid SET USER or SET LOGON command from
NCPCOM or re-enter their password on the NCS screen to reinstate the ONCF session. The range of valid
values is 0-999 minutes. A value of 0 specifies that the user is not automatically logged off for inactivity.

Field Length: 1-3 numeric characters

Required Field: No
Default Value: 0

INACTIVITY LIMIT FOR AUTO LOCKOUT

The number of days of ONCF user inactivity that is allowed before the user is automatically locked out of the
ONCF system. If the user is locked out because of this timer, the NCSS LOCKED OUT field is set to the value Y
(yes) and ONCF access is not be granted until the NCSS record is updated with a value of N (no) in the LOCKED
OUT field. Updating the LOCKED OUT field to the value N resets the LAST ACCOUNT ACTIVITY field with the
current day’s date. The range of valid values is 0-999 days. A value of 0 specifies that the user will not be
automatically locked out for inactivity.

Field Length: 1-3 numeric characters

Required Field: No
Default Value: 0

LOCKED OUT
Indicates whether a user is locked out of the ONCF system. Valid values are as follows:

Y = Yes, the user is locked out of the

ONCF system and cannot enter any
commands.

N = No, the user is not locked out of the

ONCF system.

This field is automatically updated to the value Y when a nonzero value is configured in the INACTIVITY LIMIT
FOR AUTO LOCKOUT field, the inactivity limit is exceeded by the user, or the user subsequently attempts to
perform an ONCF command. In order to restore the user’s access privileges, the NCSS record must be read and
updated with a value of N in the LOCKED OUT field. The LOCKED OUT field can be updated from the NCSS at
any time in order to lock out a user or restore user access privileges.

Field Length: 1 alphabetic character

Required Field: Yes
Default Value: N

LAST ACCOUNT ACTIVITY

The date of the most recent ONCF command activity performed by the user. When an NCSS record is added,
this field is set to the current date. It is also reset to the current date when the LOCKED OUT field is updated with
a value of N. This date is in the format YYMMDD and cannot be directly modified on the NCSS AFT screen.

Field Length: System-protected

243
ACCOUNT EXPIRATION
The last date the user is allowed access to the ONCF system. If a valid date is configured in this field, the user is
not allowed to perform any ONCF commands after the date indicated. This date must be entered in YYMMDD
format. A value of zeroes indicates that the user’s account does not expire.

Field Length: 6 numeric characters

Required Field: No
Default Value: 000000
PASSWORD REQUIREMENTS

MIN LENGTH
The minimum number of characters required for a new password entered by a user in a SET PASSWORD
command. This requirement does not affect passwords updated directly on the NCSS screen. The range of valid
values is 0-16. This value cannot be greater than the value for MAX LENGTH. A value of 0 specifies that a
minimum length requirement is not to be applied to new passwords entered in SET PASSWORD commands.

Field Length: 1-2 numeric characters

Required Field: No
Default Value: 0

MIN ALPHA CHARS

The minimum number of alphabetic characters (A-Z, a-z) required for a new password entered by a user in a
SET PASSWORD command. This requirement does not affect passwords updated directly on the NCSS screen.
The range of valid values is 0-16. The MIN ALPHA CHARS and MIN NUMERIC CHARS field values together
cannot exceed 16. A value of 0 specifies that a minimum number of alphabetic characters will not be required in
new passwords entered in SET PASSWORD commands.

Field Length: 1-2 numeric characters

Required Field: No
Default Value: 0

MIN DAYS BEFORE CHANGE

The minimum number of days which must pass before the SET PASSWORD command can be reissued by the
user to change their password. The range of valid values is 0-364. If a nonzero value is entered, it must be less
than the value entered in the MAX DAYS BEFORE CHANGE field. A value of 0 specifies that the user is not
restricted for how frequently the SET PASSWORD command can be performed and the password reset.

Field Length: 1-3 numeric characters

Required Field: No
Default Value: 0

MAX LENGTH
The maximum number of characters allowed for a new password entered by a user in a SET PASSWORD
command. This requirement does not affect passwords updated directly on the NCSS screen. The range of valid
values is 0-16. This value cannot be less than the value for MIN LENGTH. A value of 0 specifies that a maximum
length requirement is not applied to new passwords entered in SET PASSWORD commands.

Field Length: 1-2 numeric characters

Required Field: No
Default Value: 0

244
MIN NUMERIC CHARS
The minimum number of numeric characters (0-9) required for a new password entered by a user in a SET
PASSWORD command. This requirement does not affect passwords updated directly on the NCSS screen. The
range of valid values is 0-16. The MIN ALPHA CHARS and MIN NUMERIC CHARS field values together cannot
exceed 16. A value of 0 specifies that a minimum number of numeric characters is not required in new
passwords entered in SET PASSWORD commands.

Field Length: 1-2 numeric characters

Required Field: No
Default Value: 0

MAX DAYS BEFORE CHANGE

The number of days until the password expires. The range of valid values is 0-365. If a nonzero value is entered,
it must be greater than the value entered in the MIN DAYS BEFORE CHANGE field. A value of 0 specifies that
the password does not expire.

Field Length: 1-3 numeric characters

Required Field: NO
Default Value: 30

PASSWORD HISTORY
The number of previous passwords that are remembered by the ONCF security system for the user. The user
cannot perform a SET PASSWORD command using any of the previous passwords retained in the system. The
range of valid values is 0-9 passwords. A value of 0 specifies that previous passwords are not remembered by
the ONCF security system.

Field Length: 1 numeric character

Required Field: No
Default Value: 0

MAX INVALID COUNT

The maximum number of consecutive invalid password attempts allowed. The range of valid values is 0-9. If this
field contains the value zero, no commands are denied because of the number of invalid password attempts. If a
record is added when this field is set to a value greater than zero, all records for the user name must have the
same password and the same value for this field. If either field is inconsistent among the records with the same
user name, an error message is displayed. If you update this field to a nonzero value, the changed value is
applied to all records for the user name. If this field is changed to the value zero, the MAX INVALID COUNT field
(and a new password, if entered at the same time) is updated in all records for the user name without checking
the consistency of the NEW PASSWORD and MAX INVALID COUNT fields.

Field Length: 1 numeric character

Required Field: No
Default Value: 0

CURRENT INVALID COUNT

The current number of invalid password attempts since the last successful password entry. From the NCPCOM
utility, the SET USER command and any other command entered with an invalid password increases the value of
this field by one. From the NCS screen, any command entered with an invalid password increases the value of
this field by one. When the value of the CURRENT INVALID COUNT field is increased but is less than the value
of the MAX INVALID COUNT field, an event message is displayed indicating that the user name or password is
invalid. If the value of the CURRENT INVALID COUNT field is equal to or greater than the value of the MAX

245
 INVALID COUNT field, the NCPI Server process displays an event message, does not attempt to verify the
password, and automatically denies all commands. These event messages are logged only when the ENABLE-
SECURITY parameter in the NCPI Server process definition is set to DETAIL. A successful password entry
resets this field to zero.

Field Length: 1 numeric character

Required Field: No
Default Value: 0

Function keys
The function keys used on SEC screen 4 are shown in the following table. The first column shows the function keys.
The second column describes the functions that can be accomplished with these keys on SEC screen 4.

Key Description
F1 VALIDATE DATA — Checks the data that has been entered on the screen for
errors.

F2 READ RECORD — Reads a record from the file in which the user is working.

F3 ADD RECORD — Adds a record to the file in which the user is working. The
record added must be unique within the file.

F4 DELETE RECORD — Deletes a record from the file in which the user is working.

F5 UPDATE NCSS RECORD — Enters the data currently displayed on the screen. If
the data has been entered over previous data, this function changes the old data
to the new data.

F6 READ NEXT RECORD — Reads the next record in the file in which the user is
working.

F7 GOTO NEW PAGE — Displays a different screen in the same record in which the
user is working. The screen to be displayed must be identified in the NEW PAGE
field at the bottom of the screen.

F10 PRINT SCREEN — Sends the screen currently being displayed to the spooler
location indicated on the Logon screen.

F11 RETURN TO BASE (PAGE 1) — Returns you to SEC screen 1.

F12 DISPLAY HELP — Displays the Help screen. The Help screen displayed depends
on the screen currently being viewed. The Help screen contains information about
XPNET function keys or menu options.

246
Key Description
F13 CHANGE CURRENT LNET — Changes the current logical network while in a file.

F14 GO TO FIID/REGN/BRCH INFO — Displays the first page of SEC screen 2 if you
have read access to screen 2. Otherwise, an error message is displayed.

F15 GO TO SCREEN ACCESS INFO — Displays the first page of SEC screen 3 if you
have read access to screen 3. Otherwise, an error message is displayed.

F16 EXIT OR GOTO FILE — Displays the previous level menu or screen. This key has
several purposes. It is used to exit XPNET or the file currently being accessed.

Shift-F7 GOTO NCS PROFILE SCREEN — Displays the NCSP screen, if you have read
access to the NCSP. Otherwise, an error message is displayed. If the PROFILE
NAME field contains a profile name, the record for that profile is read.

Shift-F15 ADD SECURITY RECORDS LIKE CURRENT USER — Adds security records
identical to those of the current user, unless the user who is logged on is SUPER/
SUPER. These records consist of all records for that user in the SEC and NCSS.
The ALIAS and USER NUMBER fields must be changed in order to add the new
record. The system checks the entered alias against existing records to make
sure it is not a duplicate.

Shift-F16 LOGOFF — Logs the user off the Pathway or XPMON environment. When this
function is used while a user is accessing the environment, a blank Logon screen
is displayed. If the Logon screen is displayed when this function is used, the
Logon screen continues to be displayed or a TACL prompt is displayed,
depending on how the terminal is set up.

Adding an NCSS record

Perform the following steps to add an NCSS record for a user:

1. Access SEC screen 1. There are two methods of accessing SEC screen 1, depending on the screen that you
are currently displaying.
◦ If you are currently displaying a menu screen, enter SEC in the FILE DESTINATION field at the bottom of
the CRT access screen and press F1.
◦ If you are currently displaying a file screen, enter SEC in the FILE DESTINATION field at the bottom of the
CRT access screen and press F16.
2. In the ALIAS field, enter the user name of the user for whom you want to add an NCSS record.
3. Press F2 to read the specified user’s security record.
4. Press Shift-F7 to access SEC screen 4.
5. In the NEW PASSWORD field, enter the user password you want to associate with this NCSS record. You must
re-enter the password when the record is added to verify that no typing errors were made on the first entry.

247
 The default value for the NEW PASSWORD field is spaces. You do not re-enter the password if the default is
used. The user can set the password by issuing a SET PASSWORD command from a network control facility.

6. In the MAX DAYS BEFORE CHANGE field, enter the number of days until the password expires. When the
password expires, the user must enter a new password. A value of 0 specifies that the password will not expire.
7. In the NODE field, enter the name of an XPNET node that you want to associate with this NCSS record or enter
all asterisks to give the user access to all nodes. ACI recommends that you use a single NCSS record with a
NODE field of asterisks (*) for each user unless there is sufficient reason to enter NCSS records for each node.
8. In the PROFILE field, enter the name of the profile you want to associate with this NCSS record. To view the list
of available profile names, perform the following steps:
a. Press Shift-F7 to go to the NCSP.
b. Press F6 from the NCSP to display the first profile name.
c. Press F6 again to view subsequent profile names.
d. Once you have selected the appropriate profile name, press the F16 key to return to the NCSS. This step
places the selected profile name in the PROFILE field on the NCSS.
9. In the START TIME and END TIME fields, enter valid start and end times for ONCF user activity.
10. In the DAYS fields, enter the value Y for the days of the week during which ONCF user activity is allowed.
11. As required by customer security policies, enter values in other fields within the USAGE RESTRICTIONS and
PASSWORD REQUIREMENTS sections of the screen.
12. Press F3 to add the NCSS security record.

If you entered a password in step 5, you must reenter the password. Reenter the password and press F3 again.

Security errors and warnings

Some errors and warnings received for network control commands are directly related to the network control security
configuration. If security is enabled, the following responses are returned for the indicated errors.

SET PASSWORD errors

Minimum length is <length>

• The new password entered is too short, based on the configuration of NCSS field MIN LENGTH in the password
requirements section
• The minimum length required is displayed

Maximum length is <length>

• The new password entered is too long, based on the configuration of NCSS field MAX LENGTH in the password
requirements section
• The maximum length allowed is displayed

<num> alpha characters required

• The new password does not have enough alphabetic characters (a-z, A-Z), based on the configuration of NCSS

248
 field MIN ALPHA CHARS in the password requirements section
• The required number of alphabetic characters is displayed

<num> numeric characters required

• The new password does not have enough numeric characters (0-9), based on the configuration of NCSS field
MIN NUMERIC CHARS in the password requirements section
• The required number of numeric characters is displayed

New password must be different

• It is not allowed to select a new password which is identical to the password currently in use
• Select a different password

Cannot reuse password

• The new password matches a previous password which has been recently used by this user
• NCSS field PASSWORD HISTORY in the password requirements section dictates how many previous
passwords are remembered by the network control security system

Not allowed at this time

• the minimum number of days required between user-initiated password changes have not yet passed
• a frequency for password changes by the user is configured in the NCSS field MIN DAYS BEFORE CHANGE in
the password requirements section

Other security errors

Invalid security

This is a general security failure response which may be returned for any of the following reasons:

• The user alias entered in the SET USER or SET LOGON command is not a valid user
• The password that was entered in the SET USER or SET LOGON command is not the correct password
• The user and password may be correct, but the user does not have access to perform the attempted command

Password expired

• The maximum number of days allowed between password changes has been met or exceeded
• If possible, a SET PASSWORD command must be initiated by the user to change the password
• If the SET PASSWORD command is not allowed, the user must contact the security administrator to have the
user’s password reset
• The number of days allowed before a password expires is configured in the NCSS field MAX DAYS BEFORE
CHANGE in the password requirements section

Password not set for user

249
 • A new NCSS record has been added for this user or the password has been reset to spaces by a security
administrator
• A SET PASSWORD command is required by the user to select their password before any other commands can
be performed

Inactivity limit exceeded

• The user’s network control terminal (NCS or NCPCOM) has been inactive for the maximum number of minutes
allowed, as configured in the NCSS field INACTIVITY LIMIT FOR AUTO LOGOFF
• In order to initiate more network control commands, the user must take one of the following actions depending
on the type of network control terminal being used:
• If using the NCS screen, the user must re-enter their password in the PASSWORD field
• If using NCPCOM, the user must issue a new SET USER or SET LOGON command in order to re-enter their
password

No access at this time

• The user has attempted to perform a network control command outside of the user’s allowed time window or on
a day that is not allowed for the user
• NCSS fields START TIME and END TIME define the time of day when the user is allowed to enter network
control commands
• NCSS DAYS fields (MO, TU, WE, TH, FR, SA, SU) define the days of the week when the user is allowed to
enter network control commands

Access not allowed

• The user has been locked out from performing network control commands on the system
• The lockout may happen for one of the following reasons:
◦ The user has not initiated a valid network control logon for the maximum number of inactive days allowed,
as configured in the NCSS field INACTIVITY LIMIT FOR AUTO LOCKOUT.
◦ The security administrator has set the NCSS field LOCKED OUT to “Y” (yes) to indicate the user is locked
out of the network control system.
• The user must contact the security administrator to have the LOCKED OUT field reset to “N” (no).

250
Appendix D: X.25 Network Inquiry (XNI) screen
The X.25 Network Inquiry (XNI) subsystem is used to send supervisory inquiries into data networks. Current support
is available for users of the DATAPAC RAPID service in Canada. Using the X.25 Network Inquiry system with
RAPID, the user can send RAPID READ messages on selected user circuits. Statistical data received in response to
the RAPID READ message is then formatted and displayed on the XNI screen.

This section describes the XNI screen.

XNI screen description

The XNI screen is used to specify the symbolic station name of the remote terminal or pollable controller for which
statistics are required. The XNI screen is shown here, followed by descriptions of its fields.

USER
The name that uniquely identifies you as an operator. Depending on how your system security is set up, this can
be the same name that you entered on the Logon screen or it can be a different name specifically for use in
executing XNI commands.

Each time you issue a command from this screen, your user name and password are used to verify your access
to the command.

Field Length: 1–16 alphanumeric characters

Required Field: Yes, if security is enabled
Default Value: The user name previously entered

251
PASSWORD
The password associated with the name entered in the USER field. XPNET requires each user to select a
confidential password to ensure that user names are not employed by unauthorized individuals. Each user name
and password combination must be unique within the system.

As you enter each character of your password, the cursor moves one position to the right; however, as a security
precaution, the characters you enter are not displayed on the screen. The password field is case-sensitive.

Each time you issue a command from this screen, your user name and password are used to verify your access
to the command.

Field Length: 1–16 alphanumeric characters

Required Field: Yes, if security is enabled
Default Value: The password previously entered

SYSNAME
Identifies the HP NonStop system for which the entered commands are to be carried out.

Field Length: 1–7 alphanumeric characters

Required Field: Yes
Default Value: No default value

NODE
Identifies the XPNET node for which the entered commands are to be carried out. The XPNET node name is the
name configured in the Network Environment File (NEF).

Field Length: 1–16 alphanumeric characters

Required Field: Yes
Default Value: No default value

STATION
The symbolic station name of the remote terminal or pollable controller for which statistics are required.

Field Length: 1–16 alphanumeric characters

Required Field: Yes
Default Value: No default value

Function keys
The function keys used on the NCS screen are described in the following table. Throughout XPNET manuals,
references to these function keys include only XPNET function keys. Specific keyboards may require the use of a
combination of keys to achieve the functionality.

The first column of the table below shows the XPNET key. The second column describes the functions that can be
accomplished with these function keys.

Key Description
F1 ENTER DATA - Checks the data entered on the screen for errors, and enters the
data into the system.

252
Key Description
F3 PREVIOUS PAGE - Pages backwards through the command buffer. The NCS
facility maintains a buffer of the last ten screens of commands and responses.

F4 NEXT PAGE - Pages forward through the command buffer. The NCS maintains a
buffer of the last ten screens of commands and responses. F4 also retrieves the
next screen of responses to multiple object commands.

For more information on F4, see NCS response displays and NCS command
buffer.

F5 NEXT OBJECT - Displays the first screen of information for the next object in a
multiple-object command.

F10 PRINT SCREEN - Sends the screen currently displayed to the spooler location
indicated on the Logon screen.

F12 HELP SCREEN - Displays the Help screen. The Help screen displayed depends
on the screen currently being viewed. The Help screen contains information about
XPNET function keys or menu options.

F16 EXIT - This key has several purposes. It exits the Pathway subsystem or the file
currently being accessed. It also allows you to move between logical networks
and files. For more information on how to move between logical networks and
files, see the BASE24 CRT Access Manual. This function key is operable on the
Help screen for files to enable you to change files or logical networks.

Shift-F16 LOGOFF - Logs the user off this Pathway subsystem. When this function is used
while accessing Pathway, a blank Logon screen is displayed. If the Logon screen
is displayed when this function is used, the Logon screen continues to be
displayed or a TACL prompt is displayed, depending on how the terminal is set
up.

XNI operations
RAPID READ messages are initiated using the XNI screen. This is done by entering, in the STATION field, the
symbolic station name of the remote terminal or pollable controller for which statistics are required. Pressing F1 after
the symbolic station name is entered causes the application to construct a message, which it then routes to the
specified station. Provided the station for which statistics are requested is controlled by the RAPID protocol, a
RAPID READ message is formatted and sent into the network by the protocol. The protocol then waits for a RAPID
PARAM response from the network. When the RAPID PARAM message is received by the protocol, it reformats the
message and routes it back to the correct application.

Statistical responses
The response to a network inquiry to the RAPID service, initiated using the XNI screen, is shown below. This

253
information is formatted into two categories on the screen: LINE AND POLLABLE DEVICE STATUS and POLLABLE
DEVICE STATISTICS.

The following responses can be displayed in the LINE AND POLLABLE DEVICE STATUS field:

00 (Line Up, Device Up )

01 (Line Up, Device Down )

02 (Line Up, Device Disabled )

03 (Line Up, Device Refused )

04 (Line Up, Device Suspended (flow) )

05 (Line Up, Device Suspended (interrupt) )

06 (Line Up, Device Suspended (procedure) )

10 (Line Down )

11 (Line Disabled )

254
12 (Line Refused )

The items in the POLLABLE DEVICE STATISTICS fields are the names used by Telecom Canada. Refer to the
Telecom Canada publication entitled Point of Sale (POS), End-to-End Protocol for more information.

Statistics request failures

Below is an example of the screen that is displayed when statistics cannot be obtained for a desired terminal.

The failure code included in the message is the standard XPNET process message failure code that accompanies a
returned request. Typical values are as follows:

Response Code Description Explanation

104 (timeout) There was no response from the RAPID service.

105 (down) The selected terminal is marked down.

112 (disconnected) There is no virtual circuit to the remote terminal.

114 (invalid) The station specified is not controlled by an X.25 end-to-end

protocol or the type of supervisory access requested is not
supported by the protocol in use.

255
Appendix E: Unknown destinations (#DIAG-
DEST)
On certain occasions when invalid messages are received that cannot be processed (and generally where it is not
possible to fail the message back to the source), the network routes the message to the XPNET internal diagnostic
destination, #DIAG-DEST. The last five messages which have been routed to #DIAG-DEST are retained in an
internal XPNET queue within the respective node.

When a message is routed to #DIAG-DEST, EMS event 6367 is logged by the XPNET process to indicate that a
message was routed to this destination. Event 6367 is designed to be logged no more than once a minute and
displays the number of messages routed to #DIAG-DEST since the last 6367 event was logged.

LOG LCT: 13:42:16.904 SSID: [Link].3000 EVT NR: 06367 GENERATOR: XPNET
MGR: \<sys>.$AN1A Message received for #DIAG-DEST from SKELSIM.
3 message(s) received for #DIAG-DEST in this interval.

The following NCP command also can be performed to determine whether there are any messages present in the
internal #DIAG-DEST queue for a specific node:

> STATUS DEST #DIAG-DEST

There are several methods for retrieving messages from the #DIAG-DEST internal queue. Many users are not aware
that the #DIAG-DEST destination exists until event 6367 is generated. Therefore, initial planning is not required to
see the most recent five messages which have been routed to #DIAG-DEST. With some initial planning, users can
configure their network to capture all messages routed to #DIAG-DEST.

To retrieve the messages currently present in the #DIAG-DEST internal queue, the following options are available:

1. Enable XPNET NODE auditing with the following commands:

ALTER NODE <NODE NAME>, AUDITA $[Link].FILE1

ALTER NODE <NODE NAME>, AUDIT ON
CONTROL NODE <NODE NAME>, SBIT 17
CONTROL NODE <NODE NAME>, SBIT 18

See the following note regarding these switch bit (SBIT) settings. For either of these commands, the messages
queued to #DIAG-DEST are written to the current audit file once. XPNET NODE auditing can then be turned off
and the messages can be read from the audit file using the NETADRD utility.

2. Perform the following command to write the messages to a file in XPNET audit file format.

CONTROL DEST #DIAG-DEST, QWRITE<filename>

The messages can be read from the audit file using the NETADRD utility.

Even though the messages are written to an audit file using one of the above methods, the last
NOTE five messages sent to #DIAG-DEST remain in the internal queue to provide additional
assistance for user-reported problems.

256
3. Configure a process to provide the DIAG-DEST service. This process can use the NET24-XPNET Audit Process
object to write the message to an audit file. See NET24-XPNET audit process for more information about the
NET24-XPNET Audit Process.
4. The CONTROL DEST command with the QVIEW directive can be used to display these messages to the
network control terminal. To display an abbreviated view of queued messages, use the following command:

CONTROL DEST #DIAG-DEST, QVIEW

5. Configure the external audit process to use the #DIAG-DEST service by setting the EXTAUDDIAGDEST
attribute. See NET24-XPNET audit process for more information about the NET24-XPNET External Audit
Process.

257
Appendix F: NET24-XPNET audit process
The NET24-XPNET Audit Process (AUDPRO) application object is provided on the XPNET subvolume and can be
configured as a process within XPNET, specifically to provide the DIAG-DEST service, but with other potential uses
as well.

AUDPRO is an application process that writes messages it receives to its own audit file. The AUDPRO audit file is a
file totally separate from the XPNET audit file. Some optional configuration of the process is allowed using LCONF
assigns and params. It also contains a procedure hook, which allows user modifications for processing these
messages.

Because the auditing process can cause severe degradation in system performance, two different methods are
available. You can switch back and forth between both audit logic methods to determine the best solution for your
network (they are mutually exclusive, only one version can be enabled at a time). An additional attribute, AUDITIO,
can be used with the ALTER NODE command to specify various buffering options which can improve performance.

• The Internal audit process is set up by selecting one of the following AUDITIO options: BUFFERED, WAIT, or
NOWAIT. The audited information is sent to the AUDITA, AUDITB or AUDITC files, with the AUDITIO attribute
determining when the information is sent.
• The External audit process is set up by selecting the AUDITIO option of EXTERNAL. Messages to be audited by
the XPNET node process will be sent to a cloned External Audit process via the internal #AUDIT-SERVICE
dynamic service. Sending these messages to an external service improves system performance.

Internal audit process

A spooler listing of the code is provided in the AUDPLIST file. To display the contents of this source file listing, you
must go into PERUSE and enter the following command at the prompt followed by the Enter key, where volume is
the volume where the XPNET subvolume resides:

_ j $[Link]

The AUDPRO audit file is not created until there is a message generated that must be written to the file. The
following EMS event is generated when the audit file is created:

LOG LCT: 15:22:28.904 SSID: [Link].3000 EVT NR: 02029 GENERATOR: P1A^AUDPRO
MGR: \<sys>.$AN1A AUDPRO has created and opened new audit file
\<sys>.$<vol>.PRO1AUDS.A0403000.

The process opens a new audit file for the message’s date when necessary. The following EMS events are
generated when the AUDPRO process is started and a new AUDPRO audit file is created:

258
 LOG LCT: 10:01:58.130 SSID: [Link].3000 EVT NR: 02007 GENERATOR: P1A^AUDPRO
MGR: \<sys>.$AN1A NET24-XPNET Audit Process (AUDPRO)initialization complete.
Audit File Location = \<sys>.$<vol>.PRO1AUDS, Audit File Max Pages = 50, Audit
File Max Size = 102400 bytes, EMS Collector = \<sys>.$0, auto-shutdown = YES.

LOG LCT: 10:02:03.367 SSID: [Link].3000 EVT NR: 02029 GENERATOR: P1A^AUDPRO
MGR: \<sys>.$AN1A AUDPRO has created and opened new audit file
\<sys>.$<vol>.PRO1AUDS.A0404000.

If an audit file fills up, it will be closed and a new file created. At the end of the day, by default, the last audit file
opened is closed and the AUDPRO process is stopped. The following EMS event will be generated when the
AUDPRO process is stopped:

LOG LCT: 00:10:37.604 SSID: [Link].3000 EVT NR: 02009 GENERATOR: P1A^AUDPRO
MGR: \<sys>.$AN1A NET24-XPNET Audit Process (AUDPRO) being shutdown.

The NETADRD utility can be used to read the message written to the AUDPRO audit file. An open audit file must be
closed before it can be read (see the CLOSEFILE command below). If an AUDPRO audit file is closed and another
message is generated and destined for the AUDPRO process, the AUDPRO process will create and open the next
version of the AUDPRO audit file and the following EMS event will be generated:

LOG LCT: 10:25:14.641 SSID: [Link].3000 EVT NR: 02029 GENERATOR: P1A^AUDPRO
MGR: \<sys>.$AN1A AUDPRO has created and opened new audit file
\<sys>.$<vol>.PRO1AUDS.A0404001.

If necessary, the AUDPRO audit file can be pre-created using the FUP command as follows:

FUP CREATE <fnamf>, EXT <pages>, TYPE U, FORMAT 1, MAXEXTENTS 64

Pre-creating the AUDPRO audit file allows the files to be opened more quickly by AUDPRO. AUDPRO opens a pre-
created file if it contains the index of the next file to be used for the current date, if it is empty and not opened by any
other application.

To run AUDPRO, configure an XPNET process using one of the following process configurations:

Option A: Messages Routed to a SERVICE PROVIDER

259
 RESET PROCESS
SET PROCESS LIBRARY $[Link]
SET PROCESS PROGRAM $[Link]
SET PROCESS PPD $P1AP (optional)
SET PROCESS PRIORITY 130 (set as desired)
SET PROCESS CPU 1 (set as desired)
SET PROCESS STARTUP DEMAND
SET PROCESS SAVEABEND ON
SET PROCESS SERVICE DIAG-DEST
SET PROCESS STARTOPTIONS "$[Link].L1CONF" (see note)
ADD PROCESS \<sys>.P1A^NODE.P1A^AUDPRO

Option B: Messages Routed to a PROCESS

RESET PROCESS
SET PROCESS LIBRARY $[Link]
SET PROCESS PROGRAM $[Link]
SET PROCESS PPD $P1AP (optional)
SET PROCESS PRIORITY 130 (set as desired)
SET PROCESS CPU 1 (set as desired)
SET PROCESS STARTUP DEMAND
SET PROCESS SAVEABEND ON
SET PROCESS STARTOPTIONS "$[Link].L1CONF" (see note)
ADD PROCESS \<sys>.P1A^[Link]-DEST

Configuration of the Logical Network Configuration File (LCONF) filename in the STARTOPTIONS
NOTE attribute is required only if the default values for the assigns and params are not acceptable to the
user.

The MAXPROMSG attribute for the XPNET node must be set at 32000 for the AUDPRO process to start
successfully.

LCONF Assign:

AUDPRO-PRIMARY-EMS-COLLECTOR

Assigns the name of a primary EMS collector to record events. The default primary EMS collector used by AUDPRO
is the same collector as used by the XPNET node.

LCONF Params:

AUDPRO-AUDIT-FILE-VOL-SUBVOL

A volume and subvolume location specifying where the AUDPRO process is to place new audit files it creates. The
default location is the same as the volume/subvolume as the network environment file (NEF) for the respective
XPNET node.

The file name will be Ammddnnn, using the following values:

• mm = The current month, from the message timestamp

• dd = The current day of the month, from the message timestamp

260
 • nnn = A file index, 000 – 999, for this date

Text: $DATA01.PRO1AUDS

AUDPRO-AUDIT-FILE-PAGES

The number of pages that the AUDPRO process uses when creating new audit files. The default is 50 pages (100K
bytes). A maximum of 62580 and minimum of 10 pages can be configured.

AUDPRO-AUTO-SHUTDOWN

Indicates if the AUDPRO is to shut itself down at the end of the day (midnight). The default is YES. Valid values are
as follows:

• YES = Automatically shut down at the end of the day.

• NO = Do not automatically shut down at the end of the day.

The AUDPRO process supports several commands which can be delivered from NCPCOM / NCS.

All commands support the WAIT directive so that command results can be displayed at the user’s terminal instead of
through EMS events.

CLOSEFILE

Closes the AUDPRO audit file that is currently open and displays status information for that file.

Examples:

deliver process p1a^audpro, "closefile", wait

deliver process diag-dest, "closefile", wait

Response:

Audit file closed:

Filename = \<sys>.$<vol>.PRO1AUDS.A0404000
Messages in File = 1
Bytes Used = 124
Percentage Used = 1%

INFO

Displays information that was configured for the AUDPRO process.

Example:

261
 deliver process p1a^audpro, "info", wait

deliver process diag-dest, "info", wait

Response:

AUDPRO Configuration Information:

Audit File Location = \<sys>.$<vol>.PRO1AUDS
Audit File Max Pages = 50
Audit File Max Size (bytes) = 102400
EMS Collector = \<sys>.$0
Alternate EMS Collector = $0
Auto-shutdown = YES

STATUS

Displays status information for the last audit file that was used.

Example:

deliver process p1a^audpro, "status", wait

deliver process diag-dest, "status", wait

Response:

Audit file status (last file used):

Filename = \<sys>.$<vol>.PRO1AUDS.A0404000
Status = OPEN
Messages in File = 1
Bytes Used = 124
File Size (bytes) = 102400
Percentage Used = 1%

WARMBOOT

Reads in new configuration from the LCONF and resets the configuration according to those new assign or param
values. The new configuration is then displayed.

Example:

deliver process p1a^audpro, "warmboot", wait

deliver process diag-dest, "warmboot", wait

262
Response:

AUDPRO Warmboot command was successful:

Audit File Location = \<sys>.$<vol>.PRO1AUDS
Audit File Max Pages = 50
Audit File Max Size (bytes) = 102400
EMS Collector = \<sys>.$0
Alternate EMS Collector = $0
Auto-shutdown = YES

If you are an existing XPNET customer and have just received a current version of the XPNET subvolume, follow
these steps to view EMS events recorded by the AUDPRO application.

1. Volume to $volume. SCRIBE

2. EDIT the TMPLIN file and add the following lines:

==XPNET Audit Process subsystem templates

file $<vol>.[Link]

3. Execute the following command to create new TMPLRES and TMPLNRES files:`OBEY TMPLMAKE`
4. Execute the GOINST macro by executing the following command:

TACL / IN GOINST, OUT $S.#EMSINS, NOWAIT, NAME $ppd-name/

External audit process

A clone satellite process module (EAUDPRO) supports the external audit functionality. This process’s configuration
is automatically added to each NODE’s NEF when the N24SETUP macro is run to create the initial XPNET system.
A clone process is the same as AUTOMATIC except it runs in the same CPU as the XPNET node primary PID so it
can share its extended memory segment (read only) to access configuration and status information.

263
 NODE 10 > INFO PROCESS P1A^AUDP, DETAIL
PROCESS: \SYS1.P1A^NODE.P1A^AUDP ENABLED
PROGRAM $[Link] TYPE NSK
LIBRARY $[Link]
HOMETERM
DESTINATION AUTOPRI 128
DEVICENAME WARMPRI 128
XNCALIAS MSGPRO NORMAL
PPD $VQAAD

STARTUP CLONE
ADOPT OFF
CPU -1 BCPU -1
:
:

PROCESS: P1A^AUDP
SENDTIMER 10 TCPIPPRO
PROTOCOL TCPC AWAITTIMER 15
LOCALPORT 0 LOCALADDR
REMOTEPORT1 0 REMOTEADDR1
REMOTEPORT2 0 REMOTEADDR2
REMOTEPORT3 0 REMOTEADDR3
CONNTYPE COMMAND TCPRETRIES 0
RTSINIT IMMEDIATE
CONNCONFIG $[Link] DRPPD <<<<
CONNCONFIG used to enable TLS
NCSPFILE PROFILE
DRSAFPRI DRSAFBACK
DRSAFPAGES 2048 DR ON

To enable the external audit process, first set the following NODE attributes:

EXTAUDPRI
Specifies the primary Audit file Volume and Subvol

EXTAUDBACK
Specifies the backup Audit file Volume and Subvol

EXTAUDDIAGDEST
Specifies whether the #DIAG-DEST service is used for the External Audit Process

EXTAUDPAGES
Number of 2048 byte pages to use when allocating the Audit File

EXTAUDSTATINT
External Audit Statistics Interval in seconds

EXTAUDIO
External Audit I/O - ALWAYS, BACKUP, NONE) Controls if audit records are written to disk.

EXTAUDFILECDE
Guardian File code to use for Audit file

264
EXTAUDTCPIP
Should the external audit process send audit messages over TCP - used with EXTAUDIO

EXTAUDRETDAYS
Number of Days to retain audit files

EXTAUDQAT
QAT for External Audit Services #AUDIT-CONTROL and #AUDIT-SERVICE

EXTAUDQMI
QMI for External Audit Services #AUDIT-CONTROL and #AUDIT-SERVICE

EXTAUDQMT
QMT for External Audit Services #AUDIT-CONTROL and #AUDIT-SERVICE

5 > INFO NODE P1A^NODE, AUDINFO

NODE: \SYS1.P1A^NODE
AUDITA $[Link]
AUDITB $[Link]
AUDITC $[Link]
ADEXTENT 100 ADMAXEXTENTS 16
LASTAT OFF SASTAT OFF

AUDIT ON AUDITIO EXTERNAL

REALTIMEAUD OFF
AUDERROR CONTINUE ON AUDIT SWITCH ERROR
:
:

EXTAUDPRI $SPAN01.P1ANAUDP
EXTAUDBACK $SPAN02.P1ANAUDB EXTAUDDIAGDEST ON
EXTAUDPAGES 100 EXTAUDSTATINT 10 EXTAUDIO ALWAYS
EXTAUDFILECDE 1300 EXTAUDTCPIP ON EXTAUDRETDAYS 7
EXTAUDQAT 0 EXTAUDQMI 0 EXTAUDQMT 0

See the NET24-XPNET Network Control Command Reference for additional details about these attributes.

Once these attributes are configured as desired, perform the following commands to invoke external audit:

ALTER NODE <node>, AUDIT OFF

ALTER NODE <node>, AUDITIO EXTERNAL
ALTER NODE <node>, AUDIT ON

There are no other configuration changes required. The SBIT, IAUDIT, OAUDIT, IBAUDIT settings/configuration is
the same for both types of auditing and should be transparent to the user.

See External audit process and audit files for information about how the audit files are named and created.

The STATISTICS NODE, DETAIL information is unchanged regardless of which version of auditing is active. The

265
external audit process sends status and statistical information to the node at EXTAUDSTATINT intervals and when
the filename changes.

The same is true for STATUS. The external audit process sends status and statistical information to the node at
EXTAUDSTATINT intervals and when the filename changes.

NODE 4> STATUS NODE, DETAIL

NODE: \SYS1.P1A^NODE PPD: \SYS1.$P1AN
STATE: STARTED STARTUP: STARTED
PRIMARY PID: 1, 1757 BACKUP PID: 2, 1054 (HOT)
LINES STARTED: 6 LINKS STARTED: 0
PROCESSES STARTED: 6 STATIONS STARTED: 6
START PRIORITY: 0 MEASURE: OFF
DESTS INUSE: 18 DESTS ADDED: 4
TOTAL MSGS QUEUED: 0 CURRENT QUEUE MEM: 0
UNKNOWN DEST QUEUE: 0 UNAVAIL SERV QUEUE: 0
#DIAG-DEST QUEUE: 0
ELOG QUEUE: 0 NLOG QUEUE: 0
ELOG STATE: NORMAL NLOG STATE: NORMAL
EXT POOL INCREMENTED: PAGES 0 NUM OF TIMES 0
EXTENDED POOL TOTAL 133120000 FREE 130799128 PERCENT USED 2%
LMSG POOL TOTAL 0 FREE 0 PERCENT USED 0%
MORE>>> 5 +
NODE: \SYS1
NEF: \SYS1.$SPAN01.P1ANDATA.N1CNEF
PROGRAM: \SYS1.$[Link]
LICENSE: \SYS1.$SPAN01.XPNET34.LI170831 EXPIRATION: 2050-12-30
CJFILE: $SPAN01.P1ANCJA.CJ00004 LOCK: OFF

AUDIT FILE: $SPAN01.P1ANAUDP.AUD00009

:
:
:

To switch back to internal audit, perform the following commands:

ALTER NODE <node>, AUDIT OFF

ALTER NODE <node>, AUDITIO <WAIT, NOWAIT, BUFFERED>
ALTER NODE <node>, AUDIT ON

266
Appendix G: OSS KILL Process
When stopping an XPNET process (via NCPCOM) configured in the OSS space, the Java process doesn’t stop
gracefully. A SIGKILL is sent which causes an immediate termination. The OSS process needs a SIGTERM to be
sent so it is allowed to run some final processing logic before it exits.

From HP, "A Guardian native process can use most of the signals functions in the OSS API to send, receive, and
handle signals but only for the purpose of exercising control over itself. A Guardian native process cannot send a
signal to or receive a signal from another Guardian or OSS process using the kill() function.

Solution:

An OSS C program was written to run under XPNET that works in conjunction with the ONCF STOP PROCESS
logic to use the kill() function to control another OSS process by sending a SIGTERM signal to it using the
kill()function."

Enhancement in action:

This allows customers to do an orderly shutdown of OSS Java processes if desired. If the operator does an ABORT
PROCESS <oss process name> the logic will work as it did previously and immediately terminate the process. The
N24SETUP macro will now create an obey file ( GOOSSXM ) to create the XNCONF required to configure the new
OSS KILL process:

?tacl routine
#frame
#push in_xnc_file out_xnc_prefix out_xnc_ver_len out_listing_file xpnet_subvol
==
== XNCGEN (XNConf Gen Utility)
==
== This routine supports versioning of the output XNConf file using an output
== XNC file prefix and output XNC version length (supplied below).
== Alter the five ?SET statements below to meet your needs.
== The <in-xnc-file> is input to XNCGEN and must exist.
== An output XNC file named <out-xnc-prefix><first-free-version> is created.
==
==input XNC xml file (MISC)
#SET in_xnc_file OSCONF
==output XNC file & prefix
#SET out_xnc_prefix OSCONF
==output XNC version len (1/3)
#SET out_xnc_ver_len 1
==listing file (default=hometerm)
#SET out_listing_file
==xpnet release subvolume
#SET xpnet_subvol $SYSACI.XPNET41
==
==begin routine (do not make alterations after this point)
==
[xpnet_subvol].cgengo &
[xpnet_subvol].XNCGEN [in_xnc_file] [out_xnc_prefix] [out_xnc_ver_len] &
[out_listing_file]
#unframe
The NETSETUP will also create a sample OSCONF file as input for the GOOSSXM obey
file.
<?xml version="1.0"?>
<xnconf>

267
 <!--
** OSS process section
-->
<ossglobal name="gbl^oss">
<define name="=_DEFAULTS">
<class>defaults</class>
<attribute name="volume">$[Link]</attribute>
</define>
</ossglobal>
<ossprocess name="osspro">
<get name="gbl^oss"></get>
<!--
** NSKi process section
-->
<env name="_RLD_FIRST_LIB_PATH">
/usr/tandem/nssjava/jdk180_h80/jre/lib/oss/pthreads
</env>
<env name="_RLD_LIB_PATH">
/usr/tandem/nssjava/jdk180_h80/jre/lib/oss/server
</env>
<!--
** NSKx process section
<env name="_RLD_FIRST_LIB_PATH">
/usr/tandem/nssjava/jdk180_l80/jre/lib/oss/pthreads
</env>
<env name="_RLD_LIB_PATH">
/usr/tandem/nssjava/jdk180_l80/jre/lib/oss/server
</env>
-->
<cwd>
/user/sysaci/xpnet/xpnetkill
</cwd>
<program>
/user/sysaci/xpnet/xpnetkill/kill_pro_00.o
</program>
<stderr>
<file>stderr</file>
<mode>504</mode>
</stderr>
<stdout>
<file>stdout</file>
</stdout>
</ossprocess>
</xnconf>

The N24SETUP Macro will automatically create a DEVICE and PROCESS entry for this new OSS KILL ONCF
process in each of the NEF source files.

RESET DEVICE
SET DEVICE XNCONF $[Link].OSCONF0
ADD DEVICE \SYS1.P1A^NODE.D1A^OSS^CNTL
RESET PROCESS
SET PROCESS DEVICE D1A^OSS^CNTL
SET PROCESS LIBRARY $[Link]
SET PROCESS XNCALIAS OSSPRO
SET PROCESS TYPE OSSK
SET PROCESS PPD $O1AOS
ADD PROCESS \SYS1.P1A^NODE.P1A^OSS^CNTL

268
To install the OSS KILL process, FTP it from the XPNET41 subvolume to your PC. Unzip it and FTP the resulting
object to the location desired in the OSS space, point the XNCONF’s <cwd> and <program> areas to point to this
location. Run the XNCAGO tacl macro and update your device’s XNCONF file name to point to the newly updated
XNCONF.

Once the new OSS KILL process is configured and started, it will be utilized to send the proper signals when a
STOP PROCESS, of another OSS process command is executed. This will allow a Java process running in OSS to
stop gracefully if that process is configured correctly in the NEF file. The OSS KILL process must have a process
TYPE of OSSK (instead of OSS or NSK).

SET PROCESS TYPE OSSK

If the PROCESS TYPE is OSS and the OSS KILL process is not started, STOP PROCESS will work as it did
previously and immediately terminate the process. In the above add process example, if an OSS process named
P1A^OSS is stopped from NCPCOM and the OSS KILL process P1A^OSS^CNTL is started, it is sent the notification
and it will execute the KILL() command with a SIGTERM signal to P1A^OSS.

269