NET24-XPNET 4.1 - Installation Guide
NET24-XPNET 4.1 - Installation Guide
NET24-XPNET™
[Link]
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 document is intended to be used as a guide for the installation and configuration of a NET24 system. This
document does not cover migration from previous XPNET releases to release 4.1.
Audience
This document may be used by new NET24 customers who are setting up their systems for the first time, as well as
current customers who wish to migrate their XPNET 4.1 systems over to the new NET24 Pathway file maintenance
system (that is, customers who no longer need the BASE24 Pathway file maintenance system).
Notation conventions
The following list summarizes the conventions for syntax presentation in this document.
Notation Meaning
UPPERCASE Indicates command keywords and reserved words that you must enter
exactly as shown.
Braces {} Braces enclose required syntax items. A group of items enclosed in braces
represents a list of selections from which you must choose one.
2
Notation Meaning
xpobj Represents the symbolic name of an XPNET node, line, station, process,
dest, link, or device. Wildcard characters can be used with the xpobj. Valid
characters and combinations of wildcard characters are:
or text
or *text
or text*
or ?text
or text?
or text?text
September 2021
February 2020
December 2017
3
NET24-XPNET installation overview
This document is intended to be used as a guide for the installation and configuration of a NET24 system. This
document may be used by new NET24 customers who are setting up their systems for the first time, as well as
current customers who wish to migrate their XPNET 4.1 systems over to the new NET24 Pathway file maintenance
system (that is, customers who no longer need the BASE24 Pathway file maintenance system). This document does
not cover migration from previous XPNET releases to release 4.1. Customers migrating from XPNET 3.4 to XPNET
4.1 should refer to the NET24-XPNET 4.1 Implementation Guide for detailed migration instructions.
This document is intended to provide a fairly complete explanation of the installation and configuration of an NET24-
XPNET 4.1 system. Other documentation on specific issues may be found in the various NET24-XPNET manuals
available from ACI.
The Pathway system provides the mechanism to make user updates to various files in the NET24 system.
Starting with the XPNET 3.4 release, there was a Pathway replacement, XPMON, which allows customers to
eliminate the requirement to license and install Pathway from Hewlett-Packard just for XPNET. Pathway was a
requirement for BASE24 customers to access and manage application data files as well as XPNET security and
ONCF command and control. Pathmon was also utilized to start and manage some of the objects/processes
required by XPNET (SVNCP, SVNCPI). However, BASE24-eps was implemented with a multi-platform design and
Pathway was not used to manage the application database files. XPNET is required to run applications on the HP
NonStop including BASE24-eps, so the customer had to license Pathway from HP just for XPNET
The command and control system provides users direct access to configure and control a NET24 system.
The XPNET message routing platform uses a Message Queuing Architecture (MQA) to provide the ability to route
messages between endpoints in the system. Endpoints may be communications lines, user applications directly
attached to and managed by XPNET or any other application which can connect to XPNET via the line/station or
process interfaces.
The user applications provide user-specific processing for messages within the NET24 system.
4
5
Each of the elements in the above diagram is described in the following notes:
The Pathway, or XPMON, file maintenance environment includes the Logon and Virtual Menu screens which provide
access to the screens used for file maintenance functions (that is, adding, updating and deleting records) and to the
Network Control Supervisor (NCS) screen. File maintenance support is provided for the following files:
All file maintenance changes are logged to the Online Maintenance File (OMF) for auditing purposes. The NSEC
server is accessed by the Logon and Virtual Menu requesters in order to validate screen access for the user making
file maintenance changes.
NCPCOM, the NCS requester and server, the NCP server, the NCPI server and XPNET are standard 4.1 XPNET
modules. The NCPI server accesses the NCSS and NCSP files to validate command security for operators initiating
6
XPNET commands from the NCPCOM and user interfaces. Each NCPI server allows communication to one XPNET
node in the network. The NMAP file defines the access path for each XPNET node in the system. Each XPNET
node will have one NEF file associated with it which will hold all of the data associated with the configuration of the
node.
The XPNET node provides facilities to communicate with external applications using various HP NonStop supported
protocols such as asynchronous (ATP6100 and 6100 MPS-B), byte-synchronous (CP6100), SNA, LU 6.2, X.25, OSI
and TCP/IP. There is also support for communicating with:
User applications are those programs which perform customer-specific functions and rely on XPNET for process
configuration, control and message routing. These applications use the XNLIB or SKELB API library functions for
interfacing with XPNET. The LCONF file is provided as a standard means of storing parameters and file assigns
required by the user applications. The API library includes standard routines for opening the LCONF and reading
param and assign records.
External applications are those programs running in the OSS or Guardian space which XPNET starts and monitors
but with which XPNET does not participate in messaging as it does with other configured satellite processes. An
XPNET CTS/External protocol application, such as the TCP/IP Server module (TCPSRV object on the XPNET
subvolume) is an example of a process which can be run as an external process in XPNET 4.1.
The following diagram shows a simplified illustration of how multiple XPNET nodes can be configured and controlled
across multiple HP NonStop Servers with a single point of control (NCPCOM).
7
8
BASE24-eps will be enhanced in the future to access XPMON directly versus using JPATHSEND.
NOTE There are JRequestor functions in JToolkit to perform FILE_OPEN and WRITEREADX which will
be required to interface directly with XPMON.
Hardware-specific variations
References to Inspect imply platform-specific versions of the Inspect product, such as eInspect or xInspect on the
HP NonStop NS-series platform which is required for debugging TNS/E native 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 Sudoterm on the NS-series platform. The
Sudoterm utility is still available for use on earlier platforms (for example, the NonStop S-series).
On the HP NonStop NS-series platform, the HP Object Code Accelerator (OCA) utility is used to accelerate non-
native objects. On earlier platforms (the NonStop S-series) the HP AXCEL utility is used to perform this function.
9
NET24 installation for new customers
Assumptions
This section assumes that a new NET24 customer is not installing other ACI Pathway-based products in their
XPNET environment. If another product is being installed, the Pathway configuration will be quite different from that
described and built in this section. Customers may still use the N24SETUP macro as a starting point, but the NET24-
LOGON program (used for logging onto the NET24-specific Pathway system), as well as the NET24-specific
Pathway servers in the Pathway configuration, will not be used by these customers.
To augment the information in this section, the configuration of an example NET24 system will be portrayed. For the
example, it will be assumed that the NET24 code is being installed on an HP NonStop system named \SYS1 and a
volume named $TEST. To continue the example, the NET24 network configuration steps will assume that a network
named "TEST" with three XPNET nodes (P1A^NODE, P1B^NODE and P1C^NODE) is to be built on that same HP
NonStop system and volume.
[Link]
XNLIB
XPNET
SCRIBE
RDEBUG
ACIUTILS
ACILIBI
If the Performance Monitoring subsystem is also installed, then the following subvolumes should
also be installed:
NOTE
APMSCNTL APMSOBJ
10
Link the network
The standard NETB file builds an object file with HIGHPIN OFF. If the XPNET process is required to run high, and all
application processes running under the XPNET process allow a high PIN opener, then the appropriate line in the
NETB file should be altered to set HIGHPIN ON.
With XPNET 4.1, all protocol modules are shipped to each customer and the license created for the customer and
installed on the XPNET subvolume unlocks the appropriate protocols when XPNET is started. With this licensing
scheme, the customer can link into XPNET all protocols they have licensed, as well as any protocol they might use
in the foreseeable future. Edit the [Link] file to include the protocols required by your installation, then obey
the NETBC file to build a NETWORK object file.
If you are using an HP NonStop™ NS-series server (H-series NonStop™ OS or newer), TNS objects installed for
XPNET 4.1 must be accelerated using HP’s Object Code Accelerator (OCA) utility. TACL routines have been
provided to perform these acceleration procedures.
11
◦ OCAPWR – TACL routine used to accelerate the PWR object
◦ OCAPWS – TACL routine used to accelerate the PWS object
◦ OCAQFI – TACL routine used to accelerate the QFI object
◦ OCATCPC – TACL routine used to accelerate the TCPCLI object
◦ OCATCPS – TACL routine used to accelerate the TCPSRV object
◦ OCAUDP – TACL routine used to accelerate the UDP object
• OCASMPL – sample OCA TACL routine which can be adapted to OCA accelerate a user application based on
the XNLIB sample (SMPL) application skeletons that are present on the XNLIB subvolume
• OCAXNLIB – TACL routine used to accelerate the XNLIB run-time library object
If you are using an HP NonStop™ NS-series server (L-series NonStop™ OS or newer), TNS objects installed for
XPNET 4.1 must be accelerated using HP’s Object Code Accelerator for TNS/X (OCAX) utility. TACL routines have
been provided to invoke the OCAX utility for the objects which should be accelerated.
12
◦ OXAPATH – TACL routine used to accelerate the PATH object
◦ OXAPWR – TACL routine used to accelerate the PWR object
◦ OXAPWS – TACL routine used to accelerate the PWS object
◦ OXAQFI – TACL routine used to accelerate the QFI object
◦ OXATCPC – TACL routine used to accelerate the TCPCLI object
◦ OXATCPS – TACL routine used to accelerate the TCPSRV object
◦ OXAUDP – TACL routine used to accelerate the UDP object
• OXASMPL – sample OXA TACL routine which can be adapted to OCAX accelerate a user application based on
the XNLIB sample (SMPL) application skeletons that are present on the XNLIB subvolume
• OXAXNLIB – TACL routine used to accelerate the XNLIB run-time library object
After the LI yymmdd license file has been installed on the XPNET subvolume, run the LIVERIFY utility on the
XPNET subvolume to verify the license. If there are any errors with the license, contact your ACI customer account
representative to obtain a valid license.
For example:
to
13
#SET n24setup_location_subvol $[Link]
Two files (TMPLIN and TMPLMAKE) are provided with the SCRIBE subvolume to merge all template files provided
on ACI release subvolumes into one file (TMPLNRES) on the SCRIBE subvolume. The GOINST step (below)
merges TMPLNRES, SPANNRES, and CUSTNRES creating B24NRES and then merges B24NRES and HP
NonStop templates to build EMSNRES.
The TMPLIN file must be edited to change file statements to reference the volumes where the XPNET 4.1 software
has been installed. All of the files are prefixed with $VOL, so if all XPNET 4.1 release subvolumes were restored to
the same volume, the change can be accomplished with one "change all" edit command. File statements are present
in TMPLIN for the Performance Monitoring subsystem, but have been commented out. If you have the Performance
Monitoring subsystem, these statements should be included (that is, the comment should be edited out).
Once the TMPLIN file has been prepared, the TMPLNRES and TMPLRES files should be created by obeying
TMPLMAKE.
Check the output from TMPLMAKE for errors. If a file is not found, "ERROR 16 --The template file was not found"
will print. If the error is due to the inclusion of non-installed optional subsystems (for example, Performance
Monitoring), the TMPLNRES and TMPLRES files are built correctly with templates from all other files. If any other
errors occur, correct them and OBEY TMPLMAKE again.
Once the TMPLNRES and TMPLRES files are built, these templates are merged with other ACI templates by using
the GOINST file on the SCRIBE subvolume as shown below.
VOLUME $[Link]
TACL /IN GOINST, OUT $S.#EMSINS, NOWAIT, NAME $TEEM/
This step may take an extended period of time depending on your system, possibly an hour. Check the output of the
GOINST step for errors. If errors occurred, correct them and repeat the GOINST step. If any of the following
warnings occur, they can be ignored:
14
*** WARNING 42 -- SSID abbreviation MON is duplicated:
*** WARNING 22 -- Subsystem number ACI.411 has more
than one name or abbreviation:
*** WARNING 22 -- Subsystem number ACI.724 has more
than one name or abbreviation:
In order for your test system to use the template file just built, be sure to include the ADD DEFINE
=_EMS_TEMPLATES statement to any distributor or EMSPERUS startup files. If you have special HP NonStop
logons for test systems, you could add the following define to the TACLCSTM files for those logons instead.
If an event customer extension file is required to display probable cause and recommended action on specific events
(via EMSPERUS or HP NonStop’s VIEWPOINT), then the following steps should be followed to build this file.
(EMSPERUS allows access to an EVENTCX file name using the "OPEN EVENT DETAIL" command and allows
viewing of the contents of that file with the "EVENT DETAIL" command. See the HP NonStop ViewPoint Manual for
information about how VIEWPOINT uses the EVENTCX file.)
A utility on the SCRIBE subvolume, CXUTIL, reads specially formatted comments from ACI EMS template files and
creates the EVENTCX file. Instructions on how to use the CXUTIL program are provided in the file named CXREAD,
which is also on the SCRIBE subvolume.
The CXUTIL program will prompt for the EVENTCX file and TEMPLATE SOURCE file. If the current template
OBJECT file does not contain the subsystem found in the template SOURCE file, the program will prompt for the
subsystem number. If the EMSNRES has been built correctly, and the required define added, the program should
not prompt for the subsystem number. (Although subsystem numbers should not be needed, they may be found in
the SCRIBE file named EMCLDDLS.) The template file names supplied with this release and the associated
subsystem literal names are provided below. For more information on these EMS template files, see the NET24-
XPNET Network Control Operations Guide.
network
$[Link] (ACI-SSN-XPNET-L)
server-ncp
$[Link] (ACI-SSN-XPSVNCP-L)
xpmon
$[Link] (ACI-SSN-XPXMON-L)
15
server-ncpi
$[Link] (ACI-SSN-XPSNCPI-L)
server-path
$[Link] (ACI-SSN-XPNTCTSS-L)
audpro process
$[Link] (ACI-SSN-XPAUDPRO-L)
$[Link] (ACI-SSN-XPSSRV-L)
$[Link] (ACI-SSN-XPPMON-L)
Update the EVENTCX file with the NETWORK, server-ncp, server-ncpi and server-path events as shown below. If
any optional modules (for example, Performance Monitoring) are being installed, update the EVENTCX as
appropriate.
The file named TCPMTPLS should not be included when building the EVENTCX file, as this will
cause the network records to be deleted since the network subsystem id is used in this file.
FUP COPY can be used to combine $[Link] and the site EVENTCX into one file for use by
EMSPERUS and ViewPoint.
EMS filters can be created to filter messages generated by programs writing event messages to the EMS system.
The filtering of event messages allow users the flexibility to see only those EMS events which might be of concern to
them. There are a number of good examples of valid EMS filters on the SCRIBE subvolume (the FILT*S edit files).
16
NET24 system (system components, naming conventions, utility programs, and so on).
Once again, the network being configured in the examples will have the name "TEST" and will be located on the
\SYS1.$TEST volume. The system will consist of three XPNET nodes, A, B and C. The logical network ID will be "1".
The HP NonStop userid of the owner of system will be 100,100.
Pathway was a requirement for BASE24 customers to access and manage application data files as well as XPNET
security and ONCF command and control. Pathmon was also utilized to start and manage some of the
objects/processes required by XPNET (SVNCP, SVNCPI). However, BASE24-eps was implemented with a multi-
platform design and Pathway was not used to manage the application database files. XPNET is required to run
applications on the HP NonStop including BASE24-eps, so the customer had to license Pathway from HP just for
XPNET.
NET24/XPNET was modified to remove Pathway dependency for database access, command and control tasks.
Pathway is not being replaced. Rather users will be allowed to interact with applications using either the Pathway
environment, or newly developed XPMON.
For example:
See SBA Profile file maintenance for an explanation of each define in the N24DEFS file. For the purpose of this
example, N24DEFS would be edited to set the defines to the following values (obviously, the actual values you give
these defines will depend on your unique situation):
MIGRATION-ONLY : NO
REPLACE-ALL-FILES : NO
XPNET-CODE-LOCATION : $[Link]
NONSTOP-SYSTEM-NAME : \SYS1
NONSTOP-VOLUME-NAME : $TEST
NETWORK-NAME : TEST
PPD-PREFIX : T
OPTIONAL-DATA-LOCATION : N/A
OPTIONAL-TPLT-LOCATION : N/A
DEFAULT-HOMETERM : $SUDO
OWNER-USERID : 100,100
EMS-COLLECTOR : $TCOL
SCRIBE-CODE-LOCATION : $[Link]
ONCF-SECURITY : OFF
NUMBER-OF-NODES : 3
STARTING-NODE-ID : A
LOGICAL-NET-ID : 1
XPMON-ONLY : NO
17
Run the N24SETUP macro
The N24SETUP macro is located on the XPNET subvolume. To run the macro the current volume must be where
your N24DEFS file is located.
For example:
Since the MIGRATION-ONLY define was set to "NO" in the N24DEFS file, the macro will create the full complement
of files on subvolumes TESTCNTL, TESTDATA and TESTTPLT. The files created are as listed and explained in SBA
Profile file maintenance. Here is a quick list of them:
TESTCNTL(Pathway)
XN40CNTL(XPMON)
TESTDATA(Pathway)
XN40DATA(XPMON)
18
Run EMSPERUS
At this point, EMSPERUS can be started in order to observe any EMS events which may be emitted as you start the
different components of your NET24 system. A TACL macro, STRTLOG, is provided in order to allow you to start
EMSPERUS. If you are using an EMS collector other than $0, the STRTLOG macro contains the commands
necessary to start the collector (log files will be placed on the TESTLOG subvolume, for this example).
For example:
the STRTLOG initiates a very simple mechanism for viewing EMS events using ACI’s EMSPERUS
utility.
• EMSPERUS invokes the EMSPLOCL file (also on the CNTL subvolume) which contains
EMSPERUS filtering commands (PASS WHEN and FAIL ALL OTHERS) to restrict the events
NOTE that are displayed to just those concerning this NET24 system’s XPNET nodes and PATHMON
process.
• Note, however, that this method of filtering messages is quite inefficient. For NET24 systems
that could potentially have to filter a large number of messages (which most likely includes all
NET24 production systems), this type of filtering should not be used. Several alternatives to
using the command line filtering would be:
1. Write the required filter using HP NonStop’s EMS filter language and then compile it using HP NonStop’s EMF
utility for compiling EMS filters. Compiled filters can be invoked in EMSPERUS using the CHANGE FILTERFILE
command. Note again that the SCRIBE subvolume contains many examples of valid filters (files named FILT*S)
that can be used.
An alternative to using EMSPERUS is to start an EMS distributor process using HP NonStop’s EMSDIST utility.
Using a distributor allows you to do more than simply display messages. An example of how this would be done
can be found in the GOEMSD file on the SCRIBE subvolume.
2. If a dedicated EMS collector is used for a single NET24 system and no further filtering is required on the system,
the command line filters (PASS WHEN and FAIL ALL OTHERS) can be removed from the EMSPLOCL file. In
this manner, all messages for only this NET24 system are displayed since it is the only network using the
specified collector.
This section provides only a small amount of information regarding EMS event processing. For more
information, refer to the NET24-XPNET Event Management Manual.
19
SERVER-NCP – the Network Control Point server for the XPNET command and control system.
SERVER-NCPI-< ln > < node-id - the Network Control Point Interface server for the XPNET command and control
system. One of these is added for each XPNET node in the system (for example, this example system will have
SERVER-NCPI-1A, SERVER-NCPI-1B and SERVER-NCPI-1C).
SERVER-N24LNCF - the Logical Network Configuration File (LCONF) file maintenance server. This server requires
the following ASSIGN statements in its definition:
This server also allows an optional ASSIGN statement for the default LNCF/LCONF filename:
If the LNCF ASSIGN statement is present it allows the specified default LNCF filename to appear on the LCONF
file maintenance screen 1 so that a filename does not need to be manually entered.
SERVER-N24NCSP - the Network Control Security Profile file maintenance server. This server requires the following
ASSIGN statements in its definition:
SERVER-N24NCSS - the Network Control Security Specification file maintenance server. This server requires
the following ASSIGN statements in its definition:
SERVER-N24SEC - the NET24 Security file server for Pathway security. This server requires the following
ASSIGN statements in its definition:
This server also accepts an optional PARAM statement, OMF-FILE-RETENTION, which sets the number of
OMF files that will retained on an ongoing basis by the system. Valid values are 0-99 (the N24SETUP macro will
set it to 10). Since a new OMF is created for each day that the NET24 Pathway system is used, this param
allows for the automatic cleanup of these files. If this param is not present in the SERVER-N24SEC definition,
the file retention defaults to zero, meaning OMF files will not be automatically deleted.
SERVER-NCS - the Network Control Supervisor server is used for command and control in conjunction with the
20
NCS screen. Customers using the NCPCOM utility will not need to use the NCS network control screen. If the NCS
is required, note that the server definition does not require any ASSIGN statements. See the NET24-XPNET
Network Control Operations Guide for more information about the NCS screen since it is covered only minimally in
this document. NCPCOM is considered more functional and useful as an Online Network Control Facility (ONCF)
program for controlling the network.
The PATHCONF also contains one PROGRAM entry, LOGON-NET24. When the GONET24 file is obeyed from
TACL, this program brings up the NET24 Logon screen to allow the user to gain access to the Pathway file
maintenance functions.
After all editing of the PATHCONF has been completed, the user will implement the PATHCONF as the Pathway
configuration by obeying the PATHCOLD file.
For example:
Obeying the PATHCOLD file starts a PATHMON process and configures it using the PATHCONF, subsequently
creating a PATHMON configuration file, [Link].
Note also that when the EMS-COLLECTOR define in the N24DEFS file is set to something other than $0, lines are
present at the beginning of the PATHCOLD obey file to start the specified collector if it is not already running.
Once the PATHCOLD obey file is finished running, your Pathway environment is configured and running as
PATHMON process $TPMN (in this example).
This will consist of a SERVER-NCP definition to configure the attributes for the secondary copy of the XPMON
process that will be started. In addition a SERVER-NCPI-xx will need to be configured for each XPNET node on the
XPNET system on that HP NonStop node.
If changes are needed, the edit file will need to be updated and a new XPCONF<n> file will need to be created.
There is no functional equivalent of PATHCOM to make on-line changes to the XPMON environment. The
XPCONF<n> file can be renamed to the in use file and the XPMON process can be stopped and started or else the
ASSIGN XPCONF <filename> will need to be updated in the SERVER-NCP definition in the XPCONF source
(before GOXNCXP is obeyed) and the GOXMON file before the XPMON processes are stopped and started.
NCSP - the Network Control Security Profile file maintenance. There will be an executable file on the XPNET subvol
that will be name XPNCSP. This is a “stand alone” version that will bring up the NCSP maintenance screens. This
process will bring in the XPNET 4.1 version of the following files:
21
• NCSP - Network Control Security Profile file
• NCSS – Network Control Security Specification file
• OMF - Online Maintenance File for auditing
• OMFT - Online Maintenance File Template
Within the $[Link] file the following example can be followed to include the NCSP file.
Example:
<?xml version="1.0"?>
<xpconf>
<srvclglobal name="gbl^ncpi">
<assign name="PRI-EVT"> <file>$Y0</file> </assign>
<assign name="ALT-EVT"> <file>$0</file> </assign>
<assign name="NCSP"> <file>\OMA3T02.$[Link] </file> </assign>
<assign name="NCSS"> <file>\OMA3T02.$[Link] </file> </assign>
<assign name="NMAP"> <file>\OMA3T02.$[Link] </file> </assign>
NCSS - the Network Control Security Specification file maintenance. There will be an executable file on the XPNET
subvol that will be name XPNCSS. This is a “stand alone” version that will bring up the NCSS maintenance screens.
This process will bring in the XPNET 4.1 version of the following files:
SBAS - the Service Based Architecture Security file maintenance. There will be an executable file on the
XPNET subvol that will be name XPSBAS. This is a “stand alone” version that will bring up the NCSS
maintenance screens. This process will bring in the XPNET 4.1 version of the following files:
SBAP - the Service Based Architecture Security Profile file maintenance. There will be an executable file on the
XPNET subvol that will be name XPSBAP. This is a “stand alone” version that will bring up the NCSS
maintenance screens. This process will bring in the XPNET 4.1 version of the following files:
NCPCOM is considered more functional and useful as an Online Network Control Facility (ONCF) program for
controlling the network. See the NET24-XPNET Network Control Operations Guide for more information about
22
the NCS screen.
For example:
For example:
<serverclass name="server-ncp">
<get name="gbl^ncpi"></get>
<assign name="XPCONF"> <file>\
SYS1.$TEST.XN40CNTL.XPCONF0
</file></assign>
For example:
23
TACL 3> type GOXMON
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 /
This starts a XPMON process and configures it using the XPCONF file.
When the EMS-COLLECTOR define in the N24DEFS file is set to something other than $[Link]
NOTE
the STRTLOG to view the EMS log real time.
Once the GOXNCXP and GOXMON obey files have finished running, your XPMON environment is configured and
running as process $XPMN (in this example).
At the NCPCOM prompt enter the GATE command to access the XPMON process:
At the NCPCOM prompt the user can switch between Pathway and XPMON by executing either
NOTE PATH $PPD or GATE $PPD. Objects made in Pathway can communicate with objects created in
XPMON. See the NET24-XPNET Network Control Operations Guide for more details.
24
For example:
The logon screen allows room for a username and password (not case sensitive) to be entered. Note that the first
time anyone logs onto the system after it has been created, the username to use is "SUPER/SUPER" and the
password is "00000000" (all zeroes). The first thing that will need to be done is to change the password. This is done
by setting the CHANGE PASSWORD field to "Y", entering a password value in the NEW PASSWORD field and then
pressing F1. You will be asked to verify the value which you can do by retyping it in the NEW PASSWORD field and
pressing F1 again.
Now you are logged onto the Pathway file maintenance system as SUPER/SUPER. You can secure other users for
access to the Pathway system by adding records for them in the NSEC file (accessed from the Virtual Menu screen).
NET24-XPNET command and control security records can be added to the NCSS and NCSP files. Enter records for
the profiles first (NCSP) and then add the users (NCSS) for those profiles.
Params and file assigns required by user applications can be added to the LCONF through the LNCF/LCONF menu
selection.
See the appendices in this publication for full details on all of the Pathway file maintenance screens.
Once all the desired records have been added to the NET24 files, you can logoff the NET24 Pathway system. You
will, however, leave the PATHMON running since the NET24-XPNET command and control servers also run under
that PATHMON process.
Nodes
This step will explain how to start the NET24 command and control system and configure your XPNET nodes using
the configuration file(s) provided. The user interface into the command and control environment is provided by the
NCPCOM utility (located on the XPNET subvolume). For full details on all functions of the NCPCOM utility, refer to
the NET24-XPNET Network Control Command Reference Manual.
To bring up the NCPCOM utility, obey the GONCP file on the CNTL subvolume.
For example:
If command security has been turned on (the ONCF-SECURITY define in the N24DEFS file was set to "ON" or
"DETAIL"), it will be necessary to perform a SET USER command as the first command before any other commands
can be initiated. A valid username as entered in an NCSS record must be used for the SET USER command.
For example:
25
1> PATH $PPMN
2> SET USER <username><return>
PASSWORD: <password><return>
Alternatively, the SET LOGON command performs the same function as SET USER, except the SET LOGON
command does not actually validate the user until the next/first network command is performed by the user.
The password is entered as hidden text (not echoed back to the screen) for security purposes. If the NCSS record
was added with a password of blanks, you will need to set a new password for your username with the SET
PASSWORD command, and then re-logon with the SET USER command and the new password. Please note that
this password is case sensitive.
Once logged on, you will continue with the configuration of the NET24 system. The NODECONF on the CNTL
subvolume will be used to configure your XPNET nodes. NODECONF contains a superset of all of the entries in the
NnnCONF files (N1ACONF, N1BCONF and N1CCONF for this example) that are created on the CNTL subvolume.
These files may be edited and altered as desired prior to implementing the configuration (for example, to change
CPU or priority settings, QAT, QMI, and so on).
For example:
For this example configuration, obeying this file will create the following objects in your NET24 system:
NODE \SYS1.P1A^NODE
LINK \SYS1.P1A^NODE.P1A^LINK^P1B
LINK \SYS1.P1A^NODE.P1A^LINK^P1C
PROCESS \SYS1.P1A^NODE.P1A^PROCESS
NODE \SYS1.P1B^NODE
LINK \SYS1.P1B^NODE.P1B^LINK^P1A
LINK \SYS1.P1B^NODE.P1B^LINK^P1C
PROCESS \SYS1.P1B^NODE.P1B^PROCESS
NODE \SYS1.P1C^NODE
LINK \SYS1.P1C^NODE.P1C^LINK^P1A
LINK \SYS1.P1C^NODE.P1C^LINK^P1B
PROCESS \SYS1.P1C^NODE.P1C^PROCESS
The LINK objects that are added provide the mechanism for all of the nodes in the system to communicate with each
other so that messages can be routed between them. The PROCESS objects that are added are basically dummy
entries that can be used as templates to create other PROCESS objects for your user applications.
The nodes are configured to start automatically, so once the obey file is finished, barring any errors, the initial
configuration of your NET24 system is completed, with all of the XPNET nodes and LINK objects in the started state.
26
the configuration of those objects will vary greatly from customer to customer. At this point, the user can add these
objects to their XPNET node in order to fulfill all of their external communications requirements.
PROCESS objects may also be added at this time for each user application that will be running in the system. Note
that the dummy PROCESS objects have the STARTOPTIONS attribute configured with the LnCONF filename. This
is only necessary if the user applications will be using the params and file assigns from the LCONF in their
processing. Additionally, if all processes will be using the LCONF, the STARTOPTIONS attribute on the NODE
objects can be configured with the LnCONF filename, removing the requirement that it be set for each PROCESS
object.
1. If using the Pathway environment, the SERVER-NCP entries in the PATHCONF must be updated with a
PMONnn ASSIGN statement in order to recognize SERVER-NCPs on other HP NonStop nodes. The syntax for
the setting of the PMONnn ASSIGN for the SERVER-NCP entry is:
2. If using the XPMON environment, the GOXMON file and the SERVER-NCP entries in the XPCONF must be
updated with a XMONnn ASSIGN statement in order to recognize SERVER-NCPs on other HP NonStop nodes.
The syntax for the setting of the XMONnn ASSIGN for the SERVER-NCP entry is:In the GOXMON file the
syntax is:
ASSIGN XMON
nn
,
\<system>.<XPMON PPD>
<serverclass name="server-ncp">
<assign name="XMONnn"> <file>\<system>.$XPMN</file></assign>
The nn is simply a numeric index (for example, 01) that allows multiple XMON assigns to be added to the server.
Note that it is only necessary to update the PATHCONFs/XPCONFs on those HP NonStop nodes where the
NCPCOM interface will be run. This is best explained with an example.
Assume NET24 systems, named TEST, are created using the N24SETUP macro on HP NonStop nodes \SYS1
(nodes A and B) and \SYS2 (nodes C and D). If the NCPCOM interface will always only be run from the
TESTCNTL subvolume on \SYS1, then the SERVER-NCP entry in the \SYS1 PATHCONF is the only one that
needs to have the PMON assign added to it. The line added to the SERVER-NCP entry in the
27
[Link] on \SYS1 would be (assuming $TPMN is the PPD name of the PATHMON process on
\SYS2):
Pathway
XPMON
GOXMON
ASSIGN XMON01,\SYS2.$TPMN
XPCONF
However, if the NCPCOM interface will be run from the TESTCNTL subvolume on either HP NonStop
system, then the SERVER-NCP entries in both PATHCONFs must be updated with a PMON assign
statement, each referencing the PATHMON PPD on the other system.
Pathway
XPMON
GOXMON
ASSIGN XMON01,\SYS1.$TPMN
XPCONF
3. Appropriate LINK entries must be added to the configuration for each XPNET node so that they can
communicate with the required XPNET nodes on other HP NonStop systems.
For example, if Nodes A and B are on \SYS1 and nodes C and D are on \SYS2, if it is desired to have nodes A
and C linked together, then LINK object P1A^LINK^P1C should be added to node A’s configuration and LINK
object P1C^LINK^P1A should be added to node C’s configuration. If necessary, refer to the NET24-XPNET
Network Control Command Reference Manual for the attributes of a LINK object.
28
NET24 Pathway migration for existing customers
This section will describe the steps that need to be taken by an existing NET24-XPNET 3.4 customer to convert their
Pathway file maintenance system to the new NET24 Pathway system. This new Pathway system provides a
complete file maintenance system with only those functions required by NET24 customers.
Assumptions
It is assumed that any customer wishing to perform these steps has received and installed a current version of
XPNET code containing all of the new NET24-specific Pathway requesters and servers. To verify that the new code
is installed, check for the existence of the NET24 servers on your XPNET subvolume.
For example:
• SVLNCF24
• SVNCSP24
• SVNCSS24
• SVNSEC24
Additionally, new entries should be found in the SCOBOL POBJ* objects on the XPNET subvolume. Performing a
SCUP INFO [Link](*) command should show the following entries (amongst others) in the output:
• T3270/T6520-N24LNCF
• T3270/T6520-N24LOGON
• T3270/T6520-N24MENU
• T3270/T6520-N24NCS
• T3270/T6520-N24NCSP
• T3270/T6520-N24NCSS
• T3270/T6520-N24SEC
If those files are not present, a current copy of XPNET code must be requested from ACI and installed before
proceeding.
To augment the information in this section, the migration of an example NET24 system will be portrayed. For the
example, it will be assumed that the NET24 system to be migrated is on a HP NonStop system named \SYS1 and a
volume named $TEST. The network name used for the system will be "TEST". It will be assumed that the HP
NonStop userid of the owner of the current system is 100,100 and that the EMS collector being used is $0.
29
Migration steps
The following steps take the user through the process of migrating a NET24 system on a single HP NonStop node.
Though the NET24 system may span multiple HP NonStop nodes, there ideally should only be one set of security
files (NSEC, NCSS, NCSP) for a single NET24 system. If NET24 Pathway file maintenance access is required from
other HP NonStop nodes, then these steps must be repeated for each CNTL subvolume which contains a
PATHCONF that is to be configured to provide Pathway access.
For example:
See N24DEFS file for an explanation of each define in the N24DEFS file. For the purpose of this example, the
N24DEFS would be edited to set the defines to the following values (obviously, the actual values you give these
defines will depend on your unique situation):
MIGRATION-ONLY : YES
REPLACE-ALL-FILES : NO
XPNET-CODE-LOCATION : $[Link]
XNLIB-CODE-LOCATION : $[Link] <- location of XNLIB code
NONSTOP-SYSTEM-NAME : \SYS1
NONSTOP-VOLUME-NAME : $TEST
NETWORK-NAME : TEST
PPD-PREFIX : T
OPTIONAL-DATA-LOCATION : N/A
OPTIONAL-TPLT-LOCATION : N/A
DEFAULT-HOMETERM : $SUDO
OWNER-USERID : 100,100
EMS-COLLECTOR : $0
SCRIBE-CODE-LOCATION : $[Link]
ONCF-SECURITY : OFF
NUMBER-OF-NODES : 3
STARTING-NODE-ID : A
LOGICAL-NET-ID : 1
XPMON-ONLY : OFF
30
Run the N24SETUP macro
The N24SETUP macro is located on the XPNET subvolume. To run the macro, the current volume must be where
your N24DEFS file is located.
For example:
Since the MIGRATION-ONLY define was set to "YES" in the N24DEFS file, only those files needed to migrate to the
new Pathway system are created on subvolumes TESTCNTL, TESTDATA and TESTTPLT. The files created are as
listed and explained in SBA Profile file maintenance. Here is a list of them:
TESTCNTL
GONET24 MIGPCONF
TESTDATA
NSEC NSEC0
TESTTPLT
AYYMMDDX LCONF
As noted above, a template for the new LCONF file was created on the TPLT subvolume (TESTTPLT, in this
example) by the N24SETUP macro. The new LCONF file to be used should be created using FUP.
The records from the current LCONF should now be loaded into the new LCONF using the FUP COPY command
with "PAD 0" specified.
31
TACL 3> FUP COPY L1CONF, LN1LCONF, PAD 0
The "PAD 0" option causes the new fields in the new LCONF records to be filled with binary zeroes, which are valid
values for those fields. No other conversion of this file is necessary.
The LCONF files will not be renamed until the new LCONF Pathway file maintenance access is in place.
SERVER-N24LNCF - the Logical Network Configuration File (LCONF) file maintenance server. This server requires
the following ASSIGN statements in its definition:
This server also accepts an optional ASSIGN statement for the default LNCF/LCONF filename:
If the LNCF ASSIGN statement is present it allows the specified filename to appear on the LCONF file
maintenance screen 1 so that a filename does not need to be manually entered.
SERVER-N24NCSP - the Network Control Security Profile file maintenance server. This server requires the following
ASSIGN statements in its definition:
SERVER-N24NCSS - the Network Control Security Specification file maintenance server. This server requires
the following ASSIGN statements in its definition:
32
The size of the NCSS records increased in XPNET 4.1 to support the new SHA256 password
NOTE hash algortihm. The correct file must be used with the corresponding server object or else
Cobol run time errors will occur.
SERVER-N24SEC - the NET24 Security file server for Pathway security. This server requires the following ASSIGN
statements in its definition:
This server also accepts an optional PARAM statement, OMF-FILE-RETENTION, which sets the number of
OMF files that will retained on an ongoing basis by the system. Valid values are 0-99 (the N24SETUP macro will
set it to 10). Since a new OMF is created for each day that the NET24 Pathway system is used, this param
allows for the automatic cleanup of these files. If this param is not present in the SERVER-N24SEC definition,
the file retention defaults to zero, meaning OMF files will not be automatically deleted.
SERVER-NCS - the Network Control Supervisor server is used for command and control in conjunction with the
NCS screen. Customers using the NCPCOM utility will not need to use the NCS network control screen. If the NCS
is required, note that the server definition does not require any ASSIGN statements. See the NET24-XPNET
Network Control Operations Guide for more information about the NCS screen since it is covered only minimally in
this document. NCPCOM is considered more functional and useful as an Online Network Control Facility (ONCF)
program for controlling the network.
MIGPCONF also contains one PROGRAM entry, LOGON-NET24. When the GONET24 file is obeyed from TACL,
this program brings up the NET24 Logon screen to allow the user to gain access to the Pathway file maintenance
functions.
After editing of the MIGPCONF file is complete, it is ready to be incorporated into the current PATHCONF. Edit the
PATHCONF and insert the PROGRAM and SERVER entries from MIGPCONF at the desired place in the
PATHCONF. This will involve using some sort of cut and paste method (or the use of the GET function of HP
NonStop’s EDIT utility) to insert the SERVER entries from MIGPCONF into the appropriate places (for example, in
alphabetical order within the other SERVER entries) in the PATHCONF and also to insert the LOGON-NET24
PROGRAM entry in the appropriate place (for example, in alphabetical order within the other PROGRAM entries).
At this point the PATHMON process must be shutdown (you should be able to shutdown the PATHMON using the
SHUTDOWN obey file without affecting the running XPNET nodes) so that a PATHCOLD can be performed to
implement the new Pathway configuration.
For example:
After this step is complete, the PATHMON should be up and running with the new configuration.
33
Add security records for the Pathway system
The new NET24 Pathway can now be brought up using the GONET24 file.
For example:
The logon screen allows room for a username and password (not case sensitive) to be entered. Note that since
there are no records yet in the NSEC file, the first time anyone logs onto the system after it has been created they
must use a username of "SUPER/SUPER" with a password of "00000000" (all zeroes). The first thing that will need
to be done is to change the password. This is done by setting the CHANGE PASSWORD field to "Y", entering a
password value in the NEW PASSWORD field and then pressing F1. You will be asked to verify the value which you
can do by retyping it in the NEW PASSWORD field and pressing F1 again.
Now you are logged onto the NET24 Pathway file maintenance system as SUPER/SUPER and the Virtual Menu
screen is displayed. You can secure other users for access to the Pathway system by adding records for them in the
NSEC file (accessed from the Virtual Menu screen).
NET24-XPNET command and control security files can be updated through the NCSS and NCSP selections on the
Virtual Menu screen. These files still contain all the records that were previously present with the old Pathway
system. No changes need to be made to these files for the purpose of this migration.
LCONF params and file assign records required by user applications are now accessed through the LNCF/LCONF
selection on the Virtual Menu screen.
See the appendices in this publication for full details on all of the Pathway file maintenance screens.
PATHCONF entries:
34
• UPFR - User/Product File Relation File
• T3270-MEGA/T6520-MEGA
• T3270-SEC/T6520-SEC
35
Appendix A: NET24 Pathway System Logon
screen
The NET24 Logon screen is brought up by changing the volume to the CNTL subvolume and obeying the GONET24
file. The screen is shown below, followed by a description of the data fields and the function keys supported. You
must enter data in at least two of these fields, ALIAS and PASSWORD, in order to gain access to the NET24
Pathway file maintenance system.
Field descriptions
ALIAS
The name that uniquely identifies the user to the NET24 Pathway system. This name must match an alias in the
NET24 Security (NSEC) file or access is denied.
Field Length
1–16 alphanumeric characters
Required Field
Yes
Default Value
None
PASSWORD
The password for this alias. The NET24 Pathway system requires each user to select a confidential password to
ensure that aliases are not used by unauthorized individuals. Each alias and password combination must be
unique within the NET24 Pathway system. Please note that this password is not case sensitive.
The password must be changed at the time interval your institution specifies in the PASSWORD EXPIRATION
field on the NSEC screen (see NSEC file maintenance). The new password cannot be the same as the old
password. A password must be at least two bytes in length. It cannot consist of a single character repeated
several times. You should keep a written record of your password in a confidential place. If you forget your
36
password and do not have a record of it, contact your supervisor. They must clear your password, enabling you
to log on to the NET24 Pathway system and choose a new password.
As you enter each character of this field, the cursor moves one position to the right; however, as a security
precaution, the characters you enter are not displayed on the screen.
The first time you try to log on with a new alias, you should enter eight spaces in this field, using the space bar
(logging on initially as SUPER/SUPER is the exception, requiring eight zeroes in this field). You should then enter
your new password via the CHANGE PASSWORD (Y/N) and NEW PASSWORD fields.
If an attempt to log on to the NET24 Pathway system fails because you entered your password incorrectly, enter
your password again; you do not need to space over the incorrect password because the system clears this field
with every logon attempt.
A maximum number of consecutive failed logon attempts can be set via the MAX LOGON
ATTEMPTS field on the NSEC screen. If a user attempts to log on to the NET24 Pathway
system the number of times specified in this field and fails with each consecutive attempt, the
system locks out the user. If a user is locked out, they must see a supervisor who can logon to
the NET24 Pathway system and reset the CURR LOGON ATTEMPTS field to zero in that user’s
NSEC record.
Required Field
Yes
Default Value
None
If you do not want to change your password, let this field default to the value N. When the value N is left in this
field, the NET24 Pathway system does not check the NEW PASSWORD field.
Field Length
1 alphanumeric character
Required Field
No
Default Value
N
NEW PASSWORD
The new password that takes effect on the next logon. You cannot reenter your old password as your new
password because your new password must be different than your old password. You can change your password
37
at any time. The NET24 Pathway system prompts you to change your password at the time interval specified in
the PASSWORD EXPIRATION field in the NSEC for each user.
As you enter each character, the cursor moves one position to the right; however, as a security precaution, the
characters you enter are not displayed on the screen. The NET24 Pathway system requires you to enter your
new password twice. After entering your new password the first time, a screen message asks you to verify the
new password by entering it again. Again note that this password is not case sensitive.
The new password must be at least two bytes in length. It cannot consist of a single character repeated several
times. The NET24 Pathway system upshifts all entries as data is validated. For example, if you enter the
password Abc, when the password is validated, it is validated as ABC.
Field Length
1–8 alphanumeric characters
Required Field
Yes, when you have entered the value Y in the CHANGE PASSWORD field.
Default Value:
None
SCREEN PRINTER
The location to which screen images are sent for printing when you perform the PRINT SCREEN function (using
the F10 key). You can change the printer location by entering a new name over the letters NET24 in the default
value $S.#NET24. The new name must specify a valid spooler job name or printer location for the PRINT
SCREEN function to work.
Field Length
1–16 alphanumeric characters
Required Field
No
Default Value
$S.#NET24
Function keys
F1 ENTER DATA
This key performs the logon function to validate the alias and password and log the user onto the NET24
Pathway system. This key is also used to initiate the changing of the password during which it must be pressed
twice, once after each of two entries (initial and validating entries) of the new password value.
F10 PRINT
Print the current screen to the location specified in the SCREEN PRINTER field.
SF16 LOGOFF
Logoff the NET24 Pathway system
38
Appendix B: NSEC file maintenance
The NET24 Security (NSEC) file contains one record for each user to be secured for read, add, delete and/or update
access within the NET24 Pathway system. The Pathway screen for the NSEC file is shown below, followed by a
description of the data fields and the function keys supported.
Field descriptions
ALIAS
A name that uniquely identifies a user in the NET24 Pathway system. This is the name that will be entered in the
ALIAS field on the NET24 Logon screen.
Field Length
1–16 alphanumeric characters
Required Field
Yes
Default Value
No default value
GROUP NUMBER
The group number identifying the group to which the username entered in the ALIAS field is assigned. The group
number field is intended to identify a particular group of NET24 users. Valid entries range from 0 through 255.
The GROUP NUMBER and USER NUMBER fields form an alternate key to the NSEC.
Field Length
1–3 numeric characters
Required Field
Yes
39
Default Value
The group number of the user currently accessing this screen.
USER NUMBER
A number identifying a specific user within the group identified in the GROUP NUMBER field. Valid entries range
from 0 through 255.
Field Length
1–3 numeric characters
Required Field
Yes
Default Value
0
GROUP NAME
A name identifying the group number of the specified alias. This optional field is informational only.
Field Length
1–20 alphanumeric characters
Required Field
No
Default Value
No default value
USER NAME
A name identifying the user number of the specified alias. This optional field is informational only.
Field Length
1–20 alphanumeric characters
Required Field
No
Default Value
No default value
40
The SUPER/SUPER logon is also controlled by this field; therefore, a user logging on as
SUPER/SUPER cannot be locked out of the NET24 Pathway system the same as any other
user. To enable a SUPER/SUPER user to log on once they have been locked out, another user
who has access to the NET24 Security File (NSEC) must reset the CUR LOGON ATTEMPTS
field on this screen to zero for the SUPER/SUPER security record.
Field Length
2 numeric characters
Default Value
05
LOGOFF INTERVAL
The number of seconds this particular user can remain inactive in the NET24 Pathway
system before being automatically logged off back to the NET24 Logon screen. Valid
values for the LOGOFF INTERVAL field are 00000 through 32767.
A value of 00000 in the LOGOFF INTERVAL field will effectively keep the user from logging on
to the NET24 Pathway system and low values (for example, less than 100) may prohibit users
from doing meaningful work.
Field Length
5 numeric characters
NOTE
Required Field
No
Default Value
01200
Field Length
2 numeric characters
Required Field
No
Default Value
00
41
PASSWORD EXPIRATION
The number of days after which this NET24 Pathway user must change their password. Valid values are 000
through 365. A value of 000 indicates that users are not required to change their passwords. When the password
expires, the next time the user logs onto the NET24 Pathway system they will be required to change their
password before access to the system is granted.
Field Length
3 numeric characters
Required Field
No
Default Value
030
NET24 Pathway system screen access fields – An entry is listed for each of eight Pathway screens in the NET24
Pathway system. The columns specify the type of file access allowed for this user for each of those screens: R =
READ, A = ADD, D = DELETE, U = UPDATE. Set the file access as desired for each user. Valid values for these
fields are Y (Yes) or N (No, the default value).
Function keys
F1 VALIDATE DATA
Checks the data currently displayed on the screen for errors.
F2 READ RECORD
Reads a record from the NSEC for the specified alias.
F3 ADD RECORD
Adds a record, with the values as shown on the screen, to the NSEC for the specified alias. It is not possible to
add a record that already exists.
F4 DELETE RECORD
Deletes the NSEC record for the specified user.
F5 UPDATE RECORD
Updates an NSEC record with the new field data that has been entered on the screen.
F8 CLEAR SCREEN
Clears all fields in which data can be entered, replacing them with spaces or default values.
42
F12 DISPLAY HELP SCREEN
Displays a list of valid function keys for the current screen.
F16 EXIT
Returns the user to the NET24 Virtual Menu screen.
Shift-F16 LOGOFF
Logs the user off the NET24 Pathway system, returning them to the Logon screen.
43
Appendix C: NCSP file maintenance
The Network Control Security Profile (NCSP) allows security profile records to be configured. Security profile records
indicate whether each NET24-XPNET 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 the
NCSS screen, with the security record for one or more users.
• Any changes made to an NCSP profile affects all users with that security profile named in their
NCSS record.
NOTE • For example, if there are five users with the NCSP profile NET OPERATOR specified in their
NCSS 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 or DETAIL in the declaration for each NCPI Server process in
the PATHCONF. Setting the ENABLE-SECURITY parameter to ON or DETAIL allows you to specify whether the
user has access to the command (N = no access, Y = access, and U = unrestricted). If the additional NCPI Server
parameter ENABLE-AUDIT is set to ON or DETAIL, audited access codes A = audited access and V = unrestricted
are available.
For more information on how the ENABLE-SECURITY and ENABLE-AUDIT parameters work with the NCPI servers,
please reference the NET24-XPNET Network Control Operations Guide.
Also note that when the NCSP is updated for a profile currently in use, the modified command security for that profile
is implemented immediately in the NET24 command and control system.
The NCSP screen is shown below, followed by a description of the data fields and the function keys supported.
Field descriptions
44
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
OPTION
The name of an attribute, directive, or macro that is associated with the network control command displayed.
45
Field Length
System-protected
ACCESS
A code indicating the access level for the named command and attribute. Valid values are as follows:
Y
Access allowed. 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. Each time the command 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 (without audit). A user with this access level can execute this command if they are using
a valid username. The user does not have to enter a password to perform the command. No event messages
are generated when the command is executed.
V
View unrestricted. A user with this access level can execute this command if they are using a valid username.
The user does not have to enter a password to perform the 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 U.
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
46
F1 VALIDATE DATA
Checks the data that has been entered on the screen for errors.
F2 READ RECORD
Reads a record from the NCSP for the specified profile name.
F3 ADD RECORD
Adds a record, with the values as shown on the screen, to the NCSP for the specified profile name. It is not
possible to add a record that already exists.
F4 DELETE RECORD
Deletes the NCSP record for the specified profile name.
F5 UPDATE RECORD
Updates an NCSP record with the new field data that has been entered on the screen.
F8 CLEAR SCREEN
Clears all fields in which data can be entered, replacing them with spaces or default values.
F16 EXIT
If the NCSP screen was accessed directly from the NET24 Virtual Menu screen, pressing F16 returns the user to
the NET24 Virtual Menu screen. If the NCSP screen was accessed directly from the NCSS screen (using the
Shift-F7 function), pressing F16 returns the user to the NCSS screen.
A hyphen connecting two keys indicates the keys are pressed simultaneously (for example,
NOTE
Shift-F2 indicates the Shift and F2 keys are pressed simultaneously).
47
Shift-F16 LOGOFF
Logs the user off the NET24 Pathway system, returning them to the Logon screen.
48
Appendix D: NCSS file maintenance
The Network Control Security Specification (NCSS) allows the configuration of a user for the NET24 command and
control system and allows a network control security profile to be associated with that user. 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 NCSS. The security profiles themselves
are stored in the Network Control Security Profile (NCSP) file. 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 in the
NCSS.
Access to network control commands depends on how your system is configured. The NCSS file is used only when
the ENABLE-SECURITY parameter is set to ON or DETAIL in the declaration for the NCPI Server process in the
PATHCONF.
When an NCSS record with a valid security profile is displayed (a record is added or read), the first page of the
security profile information for that profile is displayed on the NCSS screen. However, command access information
cannot be changed from the NCSS screen. Command access information can only be changed from the NCSP
screen, which can be accessed from the NET24 Virtual Menu.
If there is no need to create security profiles for individual XPNET nodes for a user, it is recommended that default
profiles are used for all nodes. A security record with the value of 16 asterisks (*) for the NODE field acts as a default
security profile for the specified user for all XPNET nodes when a security profile for a specific XPNET node does
not exist.
The NCSS screen is shown below, followed by a description of the data fields and the function keys supported.
Field descriptions
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.
49
Field Length
1-16 alphanumeric characters
Required Field
Yes
Default Value
No default value
NODE
The name of the XPNET node to which this security profile applies. This field can contain one of the following
three values:
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
50
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
MO
Monday
TU
Tuesday
WE
Wednesday
TH
Thursday
51
FR
Friday
SA
Saturday
SU
Sunday
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
52
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
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.
53
Field Length
1 alphabetic character
Required Field
Yes
Default Value
N
This date is in the format YYMMDD and cannot be directly modified on the NCSS AFT screen.
Field Length
System-protected
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
54
Default Value
0
Field Length
1–2 numeric characters
Required Field
No
Default Value
0
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
55
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
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
56
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
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 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
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.
57
F4 DELETE RECORD
Deletes a record from the file in which the user is working.
F16 EXIT
Returns the user to the NET24 Virtual Menu screen.
Shift-F16 LOGOFF
Logs the user off Pathway. When this function is used while a user is 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.
58
Appendix E: SBA User Security File maintenance
The Service Based User Security (SBSS) allows the configuration of a user for the NET24 command and control
system and allows a service based security profile to be associated with that user. The security profile controls the
ability to route messages to SBA/BSI. The user’s security records contain the user group, user number, security
profile name, and user update type. The security profiles themselves are stored in the SBA Security Profile (SBAP)
file. This allows the same security profile to be assigned to multiple users. The security profile must be added to the
SBAP before a profile can be specified for a user in the SBAS.
Field descriptions
SBAS FILENAME
The fully qualified filename for the SBAS contained within the current network.
SBAP FILENAME
The fully qualified filename for the SBAP contained within the current network.
GROUP NUMBER
The group number identifying the group to which the username entered in the ALIAS field is assigned. The group
number field is intended to identify a particular group of NET24 users. Valid entries range from 0 through 255.
The GROUP NUMBER and USER NUMBER fields form an alternate key to the NSEC.
Field Length
1–3 numeric characters
Required Field
Yes
Default Value
The group number of the user currently accessing this screen.
USER NUMBER
A number identifying a specific user within the group identified in the GROUP NUMBER field. Valid entries range
from 0 through 255.
59
Field Length
1–3 numeric characters
Required Field
Yes
Default Value
0
ACCESS TYPE
This field represents the type of file maintenance that was last applied to the record. Valid values are:
A
ALLOW - User has access to the SBA service defined in the various SBA profiles specified in the SBAP
records. Initially there will be up to 20 profile records that can be associated with a specific user. With each
profile allowing 250 services, this will allow control of up to 5000 SBA services.
D
DENY - User will be denied access to the SBA service defined in the various SBA profiles specified in the
SBAP records. Again there will be up to 20 profile records that can be associated with a specific user. With
each profile allowing 250 services, this will allow control of up to 5000 SBA services (this can be increased in
the future if needed).
E
EVERYTHING - User has access to ALL SBA services - no profile records required. XPNET security is
enough.
N
NONE - User has access to NO SBA services - no profile records required
Function keys
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.
60
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 and replaces them with spaces or default values.
F16 EXIT
Returns the user to the NET24 Virtual Menu screen.
A hyphen connecting two keys indicates the keys are pressed simultaneously (for example,
NOTE
Shift-F7 indicates the Shift and F7 keys are pressed simultaneously).
Shift-F16 LOGOFF
Logs the user off Pathway. When this function is used while a user is 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.
61
Appendix F: SBA Profile file maintenance
The Service Based Profile (SBAP) allows the configuration of a user for the NET24 command and control system
and allows a service based security profile to be associated with that user. The security profile controls the access to
and auditing of network control commands. The profile records contain the profile name and a list of services
available for that profile. The security profiles themselves are stored in the SBA Security Profile (SBAP) file. This
allows the same security profile to be assigned to multiple users. The security profile must be added to the SBAP
before a profile can be specified for a user in the SBAS.
Field descriptions
SBAS FILENAME
The fully qualified filename for the SBAS contained within the current network.
SBAP FILENAME
The fully qualified filename for the SBAP contained within the current network.
PROFILE NAME
The name of a profile that has a list of services that will be available to that profile. This name will be listed in the
SBAS Security record that will assign the profile to a user group and number.
Field Length
1–16 alphanumeric characters
Required Field
Yes
Default Value
Spaces or Null
62
SBA SERVICE LIST
List of available services made available that will be associated with a single profile name.
Function keys
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.
F8 CLEAR SCREEN
Clears any values on the screen and replaces them with spaces or default values.
F16 EXIT
Returns the user to the NET24 Virtual Menu screen.
A hyphen connecting two keys indicates the keys are pressed simultaneously (for example,
NOTE
Shift-F7 indicates the Shift and F7 keys are pressed simultaneously).
Shift-F16 LOGOFF
Logs the user off Pathway. When this function is used while a user is 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.
63
Appendix G: LCONF file maintenance
LCONF – Menu and Printing screen
The LCONF Menu provides the initial point of access to the Logical Network Configuration File (LCONF) and allows
several general operations to be performed. These operations include the following:
This section describes the LCONF Menu screen and its function keys, along with the various procedures that you
can perform from the screen.
Field descriptions
LNCF FILE-NAME
The fully qualified file name of the LNCF/LCONF to be accessed.
Field Length
1–35 alphanumeric characters
Required Field
Yes
Default Value
The value from the LNCF ASSIGN statement configured for the SERVER-N24LNCF server class in the
PATHCONF.
64
ITEM TYPE
A code indicating the type of screen to access or the type of information to be sent to the printer. Values are as
follows:
• A = Assign
• E = Edit
• P = Param
NOTE The Shift-F10 report function is not valid when used in conjunction with the value E.
Field Length
1 alphabetic character
Required Field
Yes, except when printing a report.
Default Value
A
REPORT LOCATION
The spooler, terminal, or file location to which report information is sent.
Field Length
1–35 alphanumeric characters
Required Field
No
Default Value
$S.#LNCF
Function keys
F1 VALIDATE DATA
Checks the data that has been entered on the screen for errors. If the data is OK, the assign, param or edit
screen is displayed depending on the value in the ITEM TYPE field.
65
F8 CLEAR SCREEN
Clears any values on the screen in which the user is working and replaces them with spaces or default values.
F9 NEXT SCREEN
Displays the next LCONF screen. A valid LCONF filename must be entered on screen 1 before this function can
be performed. Pressing this key on the first LCONF screen takes the user to the second screen (Assign).
F16 EXIT
Returns the user to the NET24 Virtual Menu screen.
A hyphen connecting two keys indicates that the keys are to be pressed simultaneously. For example, Shift-F10
indicates that the Shift and F10 keys are pressed at the same time.
Shift-F16 LOGOFF
Logs the user off the NET24 Pathway system, returning them to the Logon screen.
The LCONF Assign screen is shown below, followed by a description of the data fields and the function keys
supported.
66
Field descriptions
APPLICATION GROUP
Historically, this field holds the symbolic name of a process or server class in the NET24-XPNET system that will
read this specific assign record from the LCONF. However, this field may hold any value that could distinguish or
group assigns of the same name as long as applications are programmed to key off the specified value when
reading the LCONF. If an assign record is a default assign for more than one process or server, a value of
"****************" can be entered in this field.
The value entered in the APPLICATION GROUP field becomes part of the key to the assign
record. This allows for defining multiple versions of a particular assign record with unique
NOTE settings for the individual processes, programs, or server classes that use them. This also
means that the value of this field cannot be changed for a given record. To change the value of
this field, a new record must be created and the old record deleted.
Field Length
0–16 alphanumeric characters
Required Field
No
Default Value
****************
ASSIGN NAME
The name of the assign, generally an abbreviation for the file’s name (for example, the assign name for the
Transaction Log File would be TLF). A logical file name consists of alphanumeric characters and the special
symbols "^", "_" and "-". The name must begin with an alphabetic character and end with an alphanumeric
character.
67
Field Length
1–32 alphanumeric and special characters
Required Field
Yes, except when using the F6 key.
Default Value
No default value
LOCATION/ID
L — The value associated with the assign. This field may contain the name of a valid HP NonStop disk file (fully
qualified) or PPD name.
Field Length
0–35 alphanumeric characters
Required Field
Yes, when using the F3 and F5 keys.
Default Value
No default value
TEMPLATE FILE
The fully qualified file name of the template file associated with this assign. Template files are intended to be
used by programs to routinely create and recreate files. The template file would be used as a model for
establishing the attributes of the new file.
If the file name is not fully qualified, the LCONF server will attempt to use the system, volume and subvolume in
which the LCONF is located as the default. Note that template files are generally stored on the network’s
nnnnTPLT subvolume (where "nnnn" is the network name).
Field Length
0–35 alphanumeric characters
Required Field
No
Default Value
No default value
COMMENTS
A free-format area for assign descriptions or miscellaneous documentation for informational purposes.
Information in this field is left-justified.
Field Length
0–64 alphanumeric characters
68
Occurs
4 times
Required Field
No
Default Value
No default value
USER FIELD
A special use text field available to be used for additional information required for assigns. For example, if there
is an assign in the LCONF for a security device a model number of the device may be entered in this field
Field Length
0–35 alphanumeric characters
Required Field
No
Default Value
No default value
Function keys
F1 VALIDATE DATA
Checks the data that has been entered on the screen for errors. If the search (Shift-F2) function has been
invoked, pressing F1 initiates the search for the next matching assigns record.
F2 READ RECORD
Displays the LCONF assign record information for the specified key, which consists of the APPLICATION
GROUP and ASSIGN NAME fields. The LCONF file being accessed is the one specified on the first LCONF
screen.
F3 ADD RECORD
Adds the specified assign record to the LCONF file in which the user is working. The record added must have a
unique key (APPLICATION GROUP and ASSIGN NAME fields) within the file.
F4 DELETE RECORD
Deletes the specified assign record from the LCONF file in which the user is working.
F5 UPDATE RECORD
Updates the specified assign record in the LCONF file in which the user is working.
69
F7 GOTO NEW PAGE
Displays a different LCONF screen. The screen to be displayed must be identified in the NEW PAGE field at the
bottom of the screen.
F8 CLEAR SCREEN
Clears any values on the screen and replaces them with spaces or default values.
F9 NEXT SCREEN
Displays the next LCONF screen. Pressing this key on the second LCONF screen takes the user to the third
screen (Param).
F10 PRINT
Sends the screen currently being displayed to the spooler location indicated on the Logon screen.
F16 EXIT
Returns the user to the NET24 Virtual Menu screen. If the search (Shift-F2) function has been invoked, pressing
F16 discontinues the search, and pressing F16 a second time invokes the exit function.
A hyphen connecting two keys indicates that the keys are to be pressed simultaneously. For
NOTE
example, Shift-F2 indicates that the Shift and F2 keys are pressed at the same time
Shift-F16 LOGOFF
Logs the user off the NET24 Pathway system, returning them to the Logon screen.
70
• Updating a param record
• Adding a param record
• Deleting a param record
• Printing a param record
The LCONF Param screen is shown below, followed by a description of the data fields and the function keys
supported.
Field descriptions
APPLICATION GROUP
Historically, this field holds the symbolic name of a process or server class in the NET24-XPNET system that will
read this specific param record from the LCONF. However, this field may hold any value that could distinguish or
group params of the same name as long as applications are programmed to key off the specified value when
reading the LCONF. If the param is applicable to more than one process or server, a value of "****************" can
be entered in this field.
The value entered in the APPLICATION GROUP field becomes part of the key to the param record. This allows
for defining multiple versions of a particular param record with unique settings for the individual processes,
programs, or server classes that use them. This also means that the value of this field cannot be changed for a
given record. To change the value of this field, you must create a new record and then delete the old one.
Field Length
0–16 alphanumeric characters
Required Field
No
Default Value
****************
71
PARAM NAME
The name of the param. A logical param name consists of alphanumeric characters and the special symbols "^",
"_" and "-". The name must begin with an alphabetic character and end with an alphanumeric characte
Field Length
1–32 alphanumeric and special characters — r.
Required Field
Yes, except when using the F6 key.
Default Value
No default value
TEXT
The value associated with the param. The value for this field can be any string of characters and spaces.
Field Length
0–70 characters
Required Field
Yes, when using the F3 and F5 keys.
Default Value
No default value
COMMENTS
A free-format area for param descriptions or miscellaneous documentation for informational purposes.
Information in this field is left-justified.
Field Length
0–64 alphanumeric characters
Occurs
4 times
Required Field
No
Default Value
No default value
Function keys
F1 VALIDATE DATA
Checks the data that has been entered on the screen for errors. If the search (Shift-F2) function has been
invoked, pressing F1 initiates the search for the next matching param record.
72
F2 READ RECORD
Displays the LCONF param record information for the specified key, which consists of the APPLICATION
GROUP and PARAM NAME fields. The LCONF file being accessed is the one specified on the first LCONF
screen
F3 ADD RECORD
Adds the specified param record to the LCONF file in which the user is working. The record added must have a
unique key (APPLICATION GROUP and PARAM NAME fields) within the file.
F4 DELETE RECORD
Deletes the specified param record from the LCONF file in which the user is working.
F5 UPDATE RECORD
Updates the specified param record in the LCONF file in which the user is working.
F8 CLEAR SCREEN
Clears any values on the screen and replaces them with spaces or default values.
F9 NEXT SCREEN
Displays the next LCONF screen. Pressing this key on the third LCONF screen takes the user to the fourth
screen (Edit).
F10 PRINT
Sends the screen currently being displayed to the spooler location indicated on the Logon screen.
F16 EXIT
Returns the user to the NET24 Virtual Menu screen. If the search (Shift-F2) function has been invoked, pressing
F16 discontinues the search, and pressing F16 a second time invokes the exit function.
73
Shift-F2 SEARCH FOR MATCH
Initiates a search for params that contain the character string entered in the PARAM NAME field. To discontinue
the search before it has reached the end of the file, use the F16 function.
A hyphen connecting two keys indicates that the keys are to be pressed simultaneously. For
NOTE
example, Shift-F2 indicates that the Shift and F2 keys are pressed at the same time.
Shift-F16 LOGOFF
Logs the user off the NET24 Pathway system, returning them to the Logon screen.
Updates from this screen affect the LOCATION/ID and TEMPLATE FILE fields in the assign records.
The LCONF Edit screen is shown below, followed by a description of the data fields and the function keys supported.
Field descriptions
Field Length
2–8 alphanumeric characters
74
Required Field
No
Default Value
No default value
TO
The new system name. The system name must begin with a backslash (\). The second character must be an
alphabetic character and can be followed by up to six additional characters.
Field Length
2–8 alphanumeric characters
Required Field
No
Default Value
No default value
Field Length
2–7 alphanumeric characters
Required Field
No
Default Value
No default value
TO
The new volume name. The volume name must begin with a dollar sign ($). The second character must be an
alphabetic character and can be followed by up to five alphanumeric characters.
Field Length
2–7 alphanumeric characters
Required Field
No
Default Value
No default value
75
Field Length
4 alphanumeric characters
Required Field
No
Default Value
No default value
TO
The first four characters of the new subvolume name. Only the first four characters of the subvolume name can
be changed. The subvolume name must begin with an alphabetic character, followed by three alphanumeric
characters.
Field Length
4 alphanumeric characters
Required Field
No
Default Value
No default value
Function keys
F8 CLEAR SCREEN
Clears any values on the screen and replaces them with spaces.
F9 NEXT SCREEN
Displays the next LCONF screen. Pressing this key on the fourth LCONF screen takes the user to the first screen
(Menu and Printing).
F10 PRINT
Sends the screen currently being displayed to the spooler location indicated on the Logon screen.
76
F11 PREVIOUS SCREEN
Displays the previous LCONF screen. Pressing this key on the fourth LCONF screen takes the user to the third
screen (Param).
F16 EXIT
Returns the user to the NET24 Virtual Menu screen.
Shift-F16 LOGOFF
Logs the user off the NET24 Pathway system, returning them to the Logon screen.
A hyphen connecting two keys indicates that the keys are to be pressed simultaneously. For
NOTE
example, Shift-F16 indicates that the Shift and F16 keys are pressed at the same time.
77
Appendix H: N24DEFS file
The N24DEFS file contains a number of defines that will be used by the N24SETUP macro to appropriately
configure the NET24 network that will be created. These are defined as follows:
MIGRATION-ONLY distinguishes the NET24 setup of a new NET24 customer from one that has already been
running XPNET 3.4 and desires to install the new NET24-specific Pathway. This definition directly affects the types
of files that are created by the N24SETUP macro. New NET24 customers will use a value "NO" for this define, while
customers who wish only to migrate their existing XPNET 3.4 networks to the new NET24-specific Pathway will set it
to "YES".
Setting MIGRATION-ONLY to "YES" causes only the following files to be created (where "nnnn " would be the
network name):
nnnn CNTL.GONET24
New Pathway logon obey file.
nnnn [Link]
New N24-specific PATHCONF entries.
nnnn [Link]
New NET24 Pathway security data file.
nnnn DATA.NSEC0
Alternate key file for NSEC.
nnnn [Link]
OMF file template.
nnnn [Link]
New LCONF file template.
Setting MIGRATION-ONLY to "NO" causes the full complement of configuration, data and obey/macro files to be
created:
AAREADME
Contains an explanation of all of the files that were created by the N24SETUP macro.
EMSPLOCL
Contains some filtering commands for EMSPERUS so that it will only display events logged by this XPNET and
Pathway system.
GOOSSXM
TACL obey file that executes the XNCGEN (XNConf Gen Utility). This routine supports the versioning of the
output OSCONF file using an output OSCONF file prefix and output OSCONF 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 OSCONF file named <out-xnc-prefix><first-free-version> is created.
78
OSCONF
OSS KILL Process XML configuration file source. See section 2.1 in the XPNET 4.1 Release notes for additional
details.
GONET24
TACL obey file for bringing up the NET24 Pathway logon screen. Provides access for updating records in the
following files: NSEC, NCSS, NCSP and LCONF.
GONCP
TACL obey file for starting the NCPCOM user interface for the XPNET system.
GOXMON
TACL obey file for that is used start the XPMON environment for this network, using the XPCONF file (created by
the N24SETUP process when the “XPMON-ONLY” flag is set to “YES” in the N24DEFS file)
GOXNCXP
TACL obey file that executes the XNCGEN (XNConf Gen Utility). This routine supports the versioning of the
output XPCONF 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.
LnCONF
The Logical Network Configuration File for this logical network.
NnnCONF
A network configuration obey file that can be obeyed within NCPCOM to build the specified node (for example,
N1ACONF builds NODE P1A^NODE, adds a single PROCESS entry and adds a LINK entry to every other
NODE in the configuration)
NODECONF
A network configuration obey file that can be obeyed within NCPCOM to build all NODEs, PROCESSes and
LINKs in this NET24 system configuration.
PATHCOLD
TACL obey file that is used to cold start the Pathway environment for this network, using the PATHCONF file for
the Pathway configuration (the PATHCTL file is created when the network is cold started).
PATHCONF
Pathway configuration file source for this network
XPCONF
XPMON XML configuration file source for a XPMON configured network.
PATHCOOL
TACL obey file that is used to 'cool' start the Pathway environment for this network, using the PATHCTL file
(created by previously obeying the PATHCOLD file) for the Pathway configuration.
PATHSTOP
Pathway obey file for stopping static servers. This file is run from within the SHUTDOWN file.
79
PATHSTRT
Pathway obey file for starting static servers. This file is run from within the PATHCOLD and PATHCOOL files.
PURGENET
TACL obey file used to purge files that have been created by the N24SETUP macro.
SHUTDOWN
TACL obey file used for shutting down the PATHMON process used for this network.
STOPLOG
TACL macro for stopping the EMS collector if $0 is not being used as the primary collector.
STRTLOG
TACL macro for starting EMSPERUS and seeing event messages written by the network to the primary EMS
collector. If the EMS collector is not $0, the collector will be started if necessary.
NnnNEF
Network environment data file for each node in the configuration
NCSP
Network Control Security Profile file
NCSS
Network Control Security Specification file
NCSS0
Alternate key file for NCSS
NMAP
Network Map file
NMAP0
Alternate key file for NMAP
NMAP1
Alternate key file for NMAP
NSEC
NET24 Screen Security Access file
NSEC0
Alternate key file for NSEC
SBAS
Service Based Architecture User Security Specification
80
SBAP
Service Based Architecture Profile
AYYMMDDX
Online Maintenance File template
LCONF
Logical Network Configuration File template
NEF
Network Environment File template
REPLACE-ALL-FILES
Allows the user to decide if the N24SETUP macro should create all new files or not. Setting this define to "YES"
causes the N24SETUP macro to create all of the files it needs, purging any files that may already exist before it
creates new ones. Setting this define to "NO" causes the macro to leave any existing files in place and only
create new files if they do not already exist. The macro will give a list of the files that previously existed and
whether they were purged or not, depending on the setting of this define.
XPNET-CODE-LOCATION
Defines the volume and subvolume location of the XPNET code on the user’s system (in general, the subvolume
name is always "XPNET").
NONSTOP-SYSTEM-NAME
Defines the name of the HP NonStop node where the new NET24 network files are to be created.
NONSTOP-VOLUME-NAME
Defines the name of the HP NonStop disk volume where the new NET24 network files are to be created.
NETWORK-NAME
Defines the four character name of network that is to be created (for example, PROD, TEST, and so forth). This
name, among other things, will define the first four characters of each subvolume that is created for this network.
PPD-PREFIX
Defines the character which will be used to precede the standard PPD names for processes defined in the
NET24 system. For example, the PPD-PREFIX might be set to "T" for a test system which would result in the
PPD of the PATHMON to be $TPMN, the PPD of the SERVER-NCP to be $TNCx (where x is a numeric value
that distinguishes the multiple copies of SERVER-NCP that can be running), the PPD of SERVER-NCPI-1A to be
$T1AU, and the PPD of XPNET node A to be $T1AN.
OPTIONAL-DATA-LOCATION
Optionally defines a separate location that will hold the network’s NET24 security data files (NSEC, NCSS and
NCSP). This define must specify a valid HP NonStop system, volume and subvolume (for example,
\SYS1.$[Link]) or contain a value of "N/A" if it is not being used.
This define should be used when a single set of security files are needed for a NET24 system which will span
multiple HP NonStop nodes. If it is used, it will cause the NSEC, NCSS and NCSP not to be created on the DATA
subvolume for the system currently being configured and will set the assigns for the NSEC, NCSS, NCSP and
81
OMF(AYYMMDDX) in the PATHCONF SERVER entries to point to the optional data location specified.
OPTIONAL-TPLT-LOCATION
Optionally defines a separate location that will hold the network’s NET24 security template for the OMF
(AYYMMDDX). This define must specify a valid HP NonStop system, volume and subvolume (for example,
\SYS1.$[Link]) or contain a value of "N/A" if it is not being used.
This define should be used when a single set of security files are needed for a NET24 system which will span
multiple HP NonStop nodes. If it is used, it will cause the OMF template file not to be created on the TPLT
subvolume for the system currently being configured and will set the OMFT assigns for various SERVER entries
in the PATHCONF to point to the optional data location specified.
DEFAULT-HOMETERM
Defines the name of the home terminal where the PATHMON, all Pathway servers, all XPNET-related processes
and the EMS collector, if one is specified, are to run.
OWNER-USERID
Defines the HP NonStop user-id (that is, group and user number) of the owner of the Pathway objects
(PATHWAY, SERVERS and PROGRAMS) defined in the PATHCONF. Note that a valid HP NonStop userid does
not have any embedded spaces.
EMS-COLLECTOR
Defines the PPD name of the EMS collector that the NET24 components will write EMS events to. Setting this
define to something other than $0 causes the appropriate lines to be added to the PATHCOLD, PATHCOOL and
STRTLOG files to start the unique alternate collector if it is not already running (note that when the collector is
started, event log files will be created on the nnnnLOG subvolume, where "nnnn" is the network name). Also, if
$0 is not being used, N24SETUP will create a STOPLOG macro on the CNTL subvolume that allows you to kill
the collector as needed.
Please refer to the NET24-XPNET Event Management Manual for more information on alternate collectors.
SCRIBE-CODE-LOCATION
Defines the volume and subvolume location of the SCRIBE code on the user’s system (in general, the
subvolume name is always "SCRIBE").
ONCF-SECURITY
Defines the setting of the ENABLE SECURITY parameter on the NCPI servers. Valid values are OFF, ON or
DETAIL.
NUMBER-OF-NODES
Defines the number of XPNET nodes that are to be created for this NET24 network configuration. The SETUP
macro allows for 26 alphabetically named networks to be created per logical network ID. Therefore, valid values
for this define are 1-26.
STARTING-NODE-ID
Defines the alphabetic character of the first node being created. Valid values are A-Z.
For example, if STARTING-NODE-ID was set to "C", NUMBER-OF-NODES was set to "3" and LOGICAL-NET-ID
was set to "2", then the system would be configured to support nodes P2C^NODE, P2D^NODE AND
P2E^NODE.
82
LOGICAL-NET-ID
Defines the number of the logical network that is to be created.
Valid values are 1-9.
NET24 users may or may not wish to use the concept of logical networks within their NET24 systems. If it is not
to be used, this define should simply be left as "1".
XPMON-ONLY
Provides the ability to substitute the current Pathway process with the ACI equivalent of XPMON. The default for
this flag is always “OFF”.
But if this is set to on, Pathway will be disabled and XPMON will be put in place.
See Configure XPMON environment for more details on what is expected for the new XPMON environment.
83
Appendix I: Using logical networks with NET24
A logical network is composed of one or more XPNET nodes that access a common database. The concept of a
logical network resulted from the need to have multiple databases of similar files accessed by different user
applications within the same expanded NET24-XPNET system (or, more accurately, SPANNET system, the
predecessor to NET24-XPNET). For example, within the card processing environment for a bank there may be
distinct settlement entities that require separate databases. Each distinct settlement entity would be configured as a
logical network and the bank could process their transactions and settle their accounts as desired, keeping log files
and account files separated as necessary.
Prior to XPNET 3.0, the logical network concept was built into the configuration of the SPANNET/XPNET system.
With XPNET 3.1 and newer, the NET24-XPNET platform has separated itself from built-in logical network
configuration requirements. The use of logical networks with NET24-XPNET is still possible, but is now entirely
dependent on the user applications that are using the NET24-XPNET platform.
The Logical Network Configuration File (LCONF or LNCF) is the primary NET24 component in the configuration of a
logical network. The LCONF holds file assigns and processing parameters that would be used by a specific set of
applications. Generally, the file assigns in a single LCONF point to files on a specific network data subvolume.
Therefore, each logical network configured would be defined by the LCONF file that it used.
The STARTOPTIONS attribute on the XPNET NODE or PROCESS objects allows the configuration of the name of
the LCONF that should be used by the user’s applications. The LCONF filename configured in the STARTOPTIONS
attribute is sent down to user applications in the startup message for the PROCESS. The STARTOPTIONS attribute
for an individual PROCESS object takes precedence over that configured for the NODE. Utilities are provided in the
XNLIB API for the user application to retrieve the LCONF filename from the startup message, open the LCONF and
read the assigns and params from the file.
Additionally, the naming conventions used for nodes and other objects (processes, stations, lines, and links) in the
NET24-XPNET system enhance the visibility of the logical network configuration within your system. Generally, the
second character in the symbolic name of these objects identifies the logical network it belongs to (for example
P1A^NODE, P2A^PROCESS1, and so forth). The NET24-XPNET Network Control Operations Guide provides good
information on naming conventions for a NET24-XPNET system.
Below is a diagram that gives a small example of how logical networks might be configured over multiple NET24-
XPNET nodes and HP NonStop nodes in a test system.
• \SYS1.$[Link].L1CONF
• \SYS2.$[Link].L2CONF
84
85
Appendix J: XPMON Network Control Security
Specification (NCSS) screen
The NET24 Network Control Security Specification screen is brought up by voluming to the subvolume and typing
“XPNCSS” since it is and executable file with a file code of 100. The screen is shown below, followed by a
description of the function keys supported. In order to gain access to the NET24 Network Control Security
Specification file maintenance system you must have the proper NCSS, NCSP, OMF Template and OMF Data Files
listed on this screen. Normally the NCSS and NCSP files will be in the xxxxDATA subvolume that is created during
the network setup process. The OMF Template will be in the OMFTPLT subvolume and the OMF Data file will
OMFDATA subvolume.
The location of the files defaults to the volume/subvol the program is run from. You can specify the location of the file
locations by using ASSIGNs.
num
Where < num > is the number of seconds before the screen times-out and exits back to TACL. If not specified,
defaults to 5 minutes.
86
Appendix K: XPMON Network Control Security
Profile (NCSP) screen
The NET24 Network Control Security Profile screen is brought up by voluming to the subvolume and typing
“XPNCSP” since it is and executable file with a file code of 100. The screen is shown below, followed by a
description of the function keys supported. In order to gain access to the NET24 Network Control Security
Specification file maintenance system you must have the proper NCSS, NCSP, OMF Template and OMF Data Files
listed on this screen. Normally the NCSS and NCSP files will be in the xxxxDATA subvolume that is created during
the network setup process. The OMF Template will be in the OMFTPLT subvolume and the OMF Data file will
OMFDATA subvolume.
The location of the files defaults to the volume/subvol the program is run from. You can specify the location of the file
locations by using ASSIGNs.
num
Where < num > is the number of seconds before the screen times-out and exits back to TACL. If not specified,
defaults to 5 minutes.
87
The “F1” function key will allow will allow access to the NCSS file maintenance screen. The “F16” function key will
exit the NCSS file maintenance area. The print location is also listed and the can be obtained by entering the
command “peruse” from and TACL prompt and searching for #NCSS.
Upon entering the NCSS file maintenance area the screen will look like the following:
Since the XPMON NCSP maintenance process follows the same guidelines as does the Pathway version, see
NCSP file maintenance for more detailed instructions.
88
Appendix L: XPMON SBA Service Profile
Security (SBAP) screen
The NET24 SBA Security Profile screen is brought up by changing the volume to the subvolume and typing
“XPSBAP” since it is and executable file with a file code of 100. The screen is shown below, followed by a
description of the function keys supported. In order to gain access to the NET24 Network Control Security
Specification file maintenance system you must have the proper NCSS, NCSP, OMF Template and OMF Data Files
listed on this screen. Normally the NCSS and NCSP files will be in the xxxxDATA subvolume that is created during
the network setup process. The OMF Template will be in the OMFTPLT subvolume and the OMF Data file will
OMFDATA subvolume
The location of the files defaults to the volume/subvol the program is run from. You can specify the location of the file
locations by using ASSIGNs.
num
Where < num > is the number of seconds before the screen times-out and exits back to TACL. If not specified,
defaults to 5 minutes.
89
The above screen allows a SBA Security Profiled to be created, or updated, to include specific services available to
that profile and the Network Control SBA User Security file (SBAS).
90
Appendix M: XPMON SBA Service User Security
(SBAS) screen
The NET24 Network Control SBA User Security screen is brought up by voluming to the subvolume and typing
“XPSBAS” since it is and executable file with a file code of 100. The screen is shown below, followed by a
description of the function keys supported. In order to gain access to the NET24 Network Control Security
Specification file maintenance system you must have the proper NCSS, NCSP, OMF Template and OMF Data Files
listed on this screen. Normally the NCSS and NCSP files will be in the xxxxDATA subvolume that is created during
the network setup process. The OMF Template will be in the OMFTPLT subvolume and the OMF Data file will
OMFDATA subvolume
The location of the files defaults to the volume/subvol the program is run from. You can specify the location of the file
locations by using ASSIGNs.
num
Where < num > is the number of seconds before the screen times-out and exits back to TACL. If not specified,
defaults to 5 minutes.
91
Field descriptions
GROUP NUMBER
The group number identifying the group to which the username entered in the ALIAS field is assigned. The group
number field is intended to identify a particular group of NET24 users. Valid entries range from 0 through 255.
The GROUP NUMBER and USER NUMBER fields form an alternate key to the SBAS.
Field Length
1–3 numeric characters
Required Field
Yes
Default Value
The group number of the user currently accessing this screen.
USER NUMBER
A number identifying a specific user within the group identified in the GROUP NUMBER field. Valid entries range
from 0 through 255.
ACCESS TYPE
For each user there will be an ACCESS TYPE configured (EVERYTHING, NONE, DENY, ALLOW).
E
EVERYTHING - User has access to ALL SBA services - no profile records required. XPNET security is
enough.
N
NONE - User has access to NO SBA services - no profile records required
D
DENY - User will be denied access to the SBA service defined in the various SBA profiles specified in the
92
SBAP records. Again there will be up to 20 profile records that can be associated with a specific user. With
each profile allowing 250 services, this will allow control of up to 5000 SBA services (this can be increased in
the future if needed).
A
ALLOW - User has access to the SBA service defined in the various SBA profiles specified in the SBAP
records. Initially there will be up to 20 profile records that can be associated with a specific user. With each
profile allowing 250 services, this will allow control of up to 5000 SBA services.
93