Implementation Guide

NET24-XPNET™

Version 4.1, September 2021

Table of Contents
About this publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
NSK Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
BASE24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Notation conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
What’s new in this publication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Pre-installation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Pre-installation tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
XPNET 4.1 test system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Restore conversion obey files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Copy XPNET 4.0 configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Edit node configuration command files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
BASE24 application requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Copy current application subvolumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Restore XPNET 4.1 software release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Recompile SKEL applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
NETLIB applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SKELB high pin migration library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Link the NETWORK object file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Accelerate TNS code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Acceleration for Itanium-based NS-series systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Acceleration for X.86-based NS-series systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
EMS template installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Merge XP EMS templates with other templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Create an EMS EVENTCX file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Update EMS filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VHS replacement of SUDOTERM for NS-series systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Phased implementation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Stop and start EMS distributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Implementation of a NET24 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Modify N24SETUP file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Run the N24SETUP macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Configure Pathway environment (if not using XPMON) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Start NET24 Pathmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configure XPMON environment (if not using Pathway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Start NET24 XPMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Load XPNET 4.1 data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Create XPNET 4.1 NEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
 Start NET24 logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Update XPNET 4.1 Pathway configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Update Node configuration command files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Add XPNET 4.1 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Stop the first XPNET node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Update Pathway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Enable / start the first XPNET node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Reconfigure XPNET 4.1 nodes for long term use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Optionally alter NODE STARTUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Relocate XPNET 4.1 code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Relocate XPNET 4.1 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
PATHCONF changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Performance monitoring subsystem tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Final cleanup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
XPNET 4.1 back out procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Light-switch implementation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Update Pathway configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Stop and start EMS distributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Performance monitoring subsystem tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Stop the XPNET 4.0 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Stop XPNET 4.0 Pathway system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Rename XPNET 4.0 data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Create XPNET 4.1 data files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Load XPNET 4.1 data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Replace XPNET 4.0 objects with XPNET 4.1 objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Start XPNET 4.1 Pathway system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Configure the XPNET 4.1 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Start XPNET 4.1 nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
ONCF security files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Update SPROUTE and configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Performance monitoring subsystem tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A: BASE24 applications and high PIN operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Unsupported procedure calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
The ACI migration library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
HIGHPIN object file attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
HIGHREQUESTERS object file attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix B: AWAITIO calls from SKEL applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Unsupported procedure calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The ACI migration library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Notices
ACI Worldwide

Offices in principal cities throughout the world.

www.aciworldwide.com

Americas +1 402 390 7600

Asia Pacific +65 6334 4843

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

© Copyright ACI Worldwide, Inc. 2021

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

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

1
About this publication
The NET24-XPNET Implementation Guide describes the pre-installation tasks, installation tasks, and
implementation tasks.

Audience
This publication is directed at current customers who wish to migrate from XPNET 4.0 to XPNET 4.1. New
customers should refer to the NET24-XPNET Installation Guide for additional information.

Prerequisites
NSK Operating system
XPNET 4.1 will not support the NSK (MIPS) S-Series machine.

The minimum NSK Operating System required to run XPNET 4.1 on an Itanium-based NS-series server is
J06.21.01.

The minimum NSK Operating System required to run XPNET 4.1 on an X.86 based NS-series server is L17.02.00.

Certain new TCPIP functionality is only valid for CLIM TCP/IP stacks and O.S. version L17.08 or newer. See Section
2.6 Internal TCP/IP Updates in the XPNET 4.1 release notes for details.

BASE24
XPNET 4.1 will require a minimum of BASE24 5.3.

If the following ACI application modules are used, current copies of them are required (using the XPNET 4.1 version
of the SKEL library; see BASE24 application requirements for more information):

• Report Initiator Process (RIP) for Transaction Based Pricing

• Remote Application Manager for UDP/IP (URAM) Module

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.

italics Lowercase italics represent variables entered by the user. UPPERCASE

ITALICS represent variables output by the system.

2
Notation Meaning
Brackets [] Brackets enclose optional syntax items. A group of items enclosed in
brackets represents a list of selections from which you can choose one or
none.

Braces {} Braces enclose required syntax items. A group of items enclosed in braces
represents a list of selections from which you must choose one.

Vertical bar | A vertical bar separates alternative syntax items in a list.

Ellipsis … An ellipsis immediately following a pair of brackets or braces indicates that

you can repeat the enclosed syntax items any number of times.

num Represents a number in the specified range, for example,num (0:99).

text Is any ASCII string.

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

where * matches any_text_ and ? matches any ASCII character.

filename Represents a valid HP NonStop external-format file name.

ppdname Represents a valid HP NonStop PPD name.

What’s new in this publication

Here is what is new in the Implementation Guide.

September 2021

Customers migrating from XPNET 3.4 or XPNET 4.0 to XPNET 4.1.

3
September 2021

No changes since previous release.

February 2020

NCSS conversion program added for customers moving from previous releases (3.1 through 4.0) to 4.1.

4
Pre-installation tasks
Pre-installation requirements
It is essential that you read this entire document and carefully plan your migration before executing any
implementation tasks.

These instructions assume that a conversion is being made from XPNET 4.0 to XPNET 4.1.

These instructions also assume that an XPNET 4.0 test system is being converted to 4.1. For discussion purposes,
the software release volume is referred to as $TEST and the test system name is referred to as TEST. Once this test
system has been built and tested, the user must determine the appropriate steps to move the software into
production.

The instructions in this document could be followed to convert a production system by substituting the release
volume name for $TEST, and the production system name for TEST. Enough knowledge will be gained from building
and using the test system to successfully build a production system. It will not be necessary to rigorously follow all
instructions when converting a production system. For instance, the software installed for the test system will
typically be used in the production installation. (For example, the network built in Installation tasks for the test system
will generally be duplicated to the production system.) The EMSNRES built in Installation tasks could be duplicated
to the production system assuming that the CUSTNRES and HP NonStop EMS Template files are the same on the
test system as the production system.

Caution must be used if you choose to modify the installation instructions as mentioned above, or if
NOTE
you choose to modify them in any other manner.

To reduce production down time, XPNET 4.1 nodes may be migrated into your system one at a time from XPNET
4.0. Phased implementation tasks describes the tasks required to undertake a phased implementation. If a phased
migration is not required and a total shutdown during migration is planned, then Light-switch implementation tasks,
which describes a light-switch migration, should be followed.

Pre-installation tasks
Pre-installation tasks are those tasks which may be performed prior to installing the majority of the XPNET 4.1
software. It is possible to perform these tasks without affecting the running system. All existing configuration and
object files should be backed up before changes are made as an additional security measure.

XPNET 4.1 test system

These instructions assume an XPNET 4.1 test system already exists and do not include steps on how to build such
a test system. See the NET24-XPNET Network Control Operations Guide for XPNET 4.1 for a detailed description of
the steps involved in configuring an XPNET 4.1 system.

Restore conversion obey files

Obey files to retrieve the current XPNET 4.1 configuration have been provided. These files will be located on the
XPNET subvolume and should be restored to the $TEST volume.

5
Copy XPNET 4.0 configuration
A file [NEFLIST] has been provided that can be used to generate a snapshot of the current XPNET 4.0 configuration.

comment ***************************************************************
comment
comment XPNET 4.0 "NEFLIST" FILE
comment
comment ***************************************************************
comment
comment This file contains a set of ONCF commands that can be obeyed
comment from NCS or NCPCOM.
Running this file on an XPNET node will
comment generate an output file that contains all the Network
comment objects from that node.
This file can be used to document
comment the on-line changes made to an XPNET node, or it could be
comment edited and obeyed to create a new XPNET node.
comment
comment To run this file:
comment Replace "\<system>.<node>" with the Tandem system name
comment and the node name of the XPNET node to be saved.
comment Replace "outfile" with a valid Tandem file name.
comment If there are no tributary stations in the configuration
comment for this node, the following message will be displayed
comment in the outfile and can be ignored:
comment Station \<system>.<node>.* info failed, no obj met comment filter
criteria
comment
comment From an NCS or an NCPCOM prompt type:
comment OBEY NEFLIST
comment
comment An NCS or NCPCOM prompt is displayed when all the commands
comment are completed.
comment
comment ***************************************************************
assume node \<system>.<node>
info /out outfile/ node ,obeyform
info /out outfile/ link * ,obeyform
info /out outfile/ device * ,obeyform
info /out outfile/ process * ,obeyform
info /out outfile/ line * ,obeyform
info /out outfile/ station * ,obeyform,controller
info /out outfile/ station * ,obeyform,tributary
info /out outfile/ dest * ,obeyform,added

The <outfile> file(s) created by this macro will contain a copy of the current configuration.

Edit node configuration command files

The XPNET node configuration command files <outfile> created in the previous step should be carefully reviewed
and edited as appropriate. Particular care should be taken over the SET NODE commands and all file locations.

NOTE Attributes set to default values are not included in the configuration command files.

6
See the NET24-XPNET Network Control Command Reference Manual for a full description of SET and ADD
commands and all attributes (and their defaults).

Required configuration command file updates

The following changes should be made for each XPNET 4.1 node:

If a phased implementation will be used to roll in XPNET 4.1, the SET NODE STARTUP should be set to
COMMAND.

XNConf files may need to be updated (see the NET24-XPNET Extended Network Configuration (XNConf) Guide) to
change any references to XPNET 4.0 objects/libraries to the XPNET 4.1 vol/subvol locations.

Alter any CTS station entity that uses the ERRORACT of IGNORE to MARKDOWN, REINAFTER, or REINEVERY.

For details of attributes of all objects, and syntax of the appropriate SET commands, see the NET24-XPNET
Network Control Command Reference Manual.

Optional configuration command file updates

If changes to the default configuration attributes are desired to take advantage of any XPNET 4.1 enhancements,
then further editing of the XPNET 4.1 configuration files should be undertaken at this point.

For details of attributes of all objects, and syntax of the appropriate SET commands, see the NET24-XPNET
Network Control Command Reference Manual.

BASE24 application requirements

RIP application for transaction based pricing

If this was running under XPNET 4.0, it should continue to run under XPNET 4.1 with no changes or recompile

However, older versions of the ACI Report Initiator Process (RIP) for Transaction Based Pricing will not start under
XPNET 4.1. A current version of the RIP process linked with the correct version of the SKEL library is required for
XPNET 4.1. Customers running a version of the RIP process older than 10/2005 must request a new copy of the
code from ACI for use with XPNET 4.1.

Remote application manager for UDP/IP (URAM)

If this was running under XPNET 4.0, it should continue to run under XPNET 4.1 with no changes or recompile

Again, older versions of the ACI Remote Application Manager for UDP/IP process, or URAM process, will not start
under XPNET 4.1. A current version of the URAM process linked with the correct version of the SKEL library is
required for XPNET 4.1. Customers running a version of the URAM process older than 10/2005 must request a new
copy of the code from ACI for use with XPNET 4.1.

7
Installation tasks
The following steps require the installation of the delivered software on the TEST system. It is possible to perform
these tasks without affecting the running system. Where a step involves changes to configuration or object files, a
recommendation to rename and duplicate back affected subvolumes is included (unless addressed by an earlier
step). All existing configuration and object files should be backed up to tape before changes are made as an
additional security measure.

Copy current application subvolumes

If a phased migration is being undertaken (or if application object code is shared between multiple XPNET systems),
then the object files of any NETLIB applications that are running on the XPNET system to be migrated should be
copied at this time to avoid library conflicts. As the same NETLIB application processes will be running
simultaneously under XPNET 4.0 and 4.1, and the two versions have unique library files, NETLIB application
process object files must be copied to another volume/subvolume for use by the 4.1 system, or library conflicts will
result. NETLIB applications can be identified by a LIBRARY attribute value of NLIB, XNLIB, XNLIBEN, or XNLIBN. If
no NETLIB application processes are running in the XPNET system being migrated then this step can be omitted.

A determination as to whether SKEL applications are recompiled or duplicated as denoted above for the NETLIB
applications is made in Recompile SKEL applications.

Restore XPNET 4.1 software release

Rename the XPNET 4.0 software release subvolumes being replaced by equivalent XPNET 4.1 subvolumes to
different subvolumes prior to restoring the XPNET 4.1 code.

Sample commands:

FUP
-RENAME $TEST.XPNET.*,$TEST.OXPNET.*
-RENAME $TEST.SCRIBE.*,$TEST.OSCRIBE.*
-RENAME $TEST.RDEBUG.*,$TEST.ORDEBUG.*
-RENAME $TEST.ACIUTILS.*,$TEST.OACIUTLS.*
-RENAME $TEST.ACILIBI.*,$TEST.OACILIBI.*
-RENAME $TEST.XNLIB.*,$TEST.OXNLIB.*

Obtain the XPNET 4.1 software via ACI’s Electronic Distribution (ED) system as follows:

https://ed.aciworldwide.com

Follow the instructions to UNPAK the downloaded files.

8
 If the Performance Monitoring subsystem is installed, then the existing 4.0 code should be renamed
and the new code restored in the above steps. To achieve this the following FUP commands should
be added to those already listed
NOTE
-RENAME $TEST.APMSCNTL.*,$TEST.OAPMSCNT.*
-RENAME $TEST.APMSOBJ.*,$TEST.OAPMSOBJ.*

and the following lines should be included within the file list (that is, inside the parentheses) in the
RESTORE/UNPAK command

*.APMSCNTL.*, &
*.APMSOBJ.*, &

After restoring the XPNET 4.1 code it should be renamed out of the way and the XPNET 4.0 version should be
renamed back into place to ensure that the 4.0 system can be restarted after a failure.

-RENAME $TEST.XPNET.*,$TEST.XPNET41.*
-RENAME $TEST.SCRIBE.*,$TEST.NSCRIBE.*
-RENAME $TEST.RDEBUG.*,$TEST.NRDEBUG.*
-RENAME $TEST.ACIUTILS.*,$TEST.NACIUTLS.*
-RENAME $TEST.ACILIBI.*,$TEST.NACILIBI.*
-RENAME $TEST.XNLIB.*,$TEST.XNLIB40.*
-RENAME $TEST.OXPNET.*,$TEST.XPNET.*
-RENAME $TEST.OSCRIBE.*,$TEST.SCRIBE.*
-RENAME $TEST.ORDEBUG.*,$TEST.RDEBUG.*
-RENAME $TEST.OACIUTLS.*,$TEST.ACIUTILS.*
-RENAME $TEST.OACILIBI.*,$TEST.ACILIBI.*
-RENAME $TEST.OXNLIB.*,$TEST.XNLIB.*

After restoring the XPNET 4.1 Perfmon code it should be renamed out of the way and the XPNET 4.0 version should
be renamed back into place to ensure that the 4.0 system can be restarted after a failure.

-RENAME $TEST.APMSCNTL.*,$TEST.NAPMSCNT.*
-RENAME $TEST.APMSOBJ.*,$TEST.NAPMSOBJ.*
-RENAME $TEST.OAPMSCNT.*,$TEST.APMSCNTL.*
-RENAME $TEST.OAPMSOBJ.*,$TEST.APMSOBJ.*

Recompile SKEL applications

If the SKELB application currently runs under XPNET 4.0, no recompile is required. However, if migrating from an
older release (that is, 3.0) the following may be required.

If applications using SKEL (for example, BASE24-atm, BASE24-pos or BASE24-teller) are installed, it is not
necessary to recompile these applications unless one of the following three exceptions apply:

1. If the application “searches or binds” in XPNET 3.1 SKELB, and SCR3185 was not installed when the
application object was created, compilation or re-bind is required for this application to run with XPNET 4.1.

9
To determine if SCR3185 was installed when the object was created, do "bind list code rel from <application
object>”).

If the "REL3^VER0^SUTL" proc is "SUTL19" or greater, SCR3185 is present and compilation or re-bind is not
necessary.

If the “REL” proc is “SUTL18” or less, compilation or re-bind is required for this application to run with XPNET
4.1. All XPNET 4.1 SKELB objects contain that SCR, so you can compile or bind using that, but If you wish to
continue using a XPNET 3.1 version of SKELB you will have to obtain one with SCR 3185 (SUTL19 or greater).

10
 SCR #3185 SKELB - rel3^ver0^sutl18^040118
24-JUN-04 SKELLIST - n30sutl.sutl18tl
XNLIBN.XNLIB - rel3_ver1_xnlib_rel14_040624
XNLIBN.XNLIBN - rel3_ver1_xnlib_rel14_040624
XNLIBN.XNLIBR - rel3_ver1_xnlib_rel14_040624
XNLIBN.XNLIBEN - rel3_ver1_xnlib_rel14_040624
XNLIBN.XNLIBER - rel3_ver1_xnlib_rel14_040624
NLIB - rel3_ver1_nlib08_040624
Reference: Internal, preparation for XPNET 3.1 release.
Symptom: None.
Problem: None.
Change: Changed SKEL NETINIT and NETLIB NETLIB_INIT
to optionally accept the standard NSK startup sequence
and consume it.
This will have no impact on Satellites
running under XPNET 3.0 since configuration of the
NSKSTARTSEQ attribute controls whether the NSK startup
sequence is sent; XPNET 3.1 will retire that attribute
and send the NSK startup unconditionally.
This scr will
allow 3.0 Satellites to accept the NSK startup from
XPNET 3.1 if the user (or CRE) didn't consume it before
NETINIT was called.
Implementation: Since SKELB and NETLIB are ran as a user
library, do the following only after taking appropriate
action to avoid library conflicts.
Install SKELB on the XPNET subvol.
Run the SKELMLBC step
if required.
If on a RISC machine, accelerate SKELB as
shown in the SKELAXCL file.
Application processes which
use SKELB as a library must be stopped and restarted in
order for the new library to take effect.
Application
processes which bind in SKELB must be re-compiled or
re-bound with the new SKELB.
Install the new XNLIB on the XNLIB subvol.
Accelerate
XNLIB using XNAXCL file.
Application processes which
bind in XNLIB must be re-compiled or re-bound with the
new library.
Application processes which use XNLIB as a
library must be stopped and restarted in order for the
new library to take effect.
Support Note: A customer wanting to run a XPNET 3.0
XNLIB application under a XPNET 3.1 node may do so
but must use the REL3_VER1_NLIB08_040624 version of
XNLIB.
If a user tries to run a XPNET 3.0 XNLIB
application with a XNLIB library version prior to
REL3_VER1_NLIB08_040624 under a XPNET 3.1 network
the application will abend.
Dependencies: None.

2. If the application “searches or binds” in DUMPLIB, and the DUMPLIB enhancement described below is desired,
compilation or re-bind using the new DUMPLIB is needed. SKEL applications that do not search or bind in
DUMPLIB will get it at run time from the SKELB library, those applications do not have to be recompiled to take

11
 advantage of this enhancement.

As of XPNET 4.0 DUMPLIB was changed to support only ZZSA files, proprietary ACI DUMP files are no longer
created. The PROGRAM and LIBRARY object files are required to view a ZZSA, so the DUMPLIB routines were
enhanced to save those object files in the ZZSA itself

The new DUMPLIB routines are not required unless the new functionality provided by them is
desired. If the old DUMPLIB routines continue to be used, DUMP files will be created and a
NOTE ZZSA will be created if the process is configured with SAVEABEND ON. The ZZSA will not
contain the program or library file, thus a ZZSA sent to ACI must be accompanied by the
program and library object files.

3. If the RMS product is being used, recompilation is recommended.

An enhancement was made to SKEL and GLOBALS to support the RMS Software Management Tool (in XPNET
3.1). If you are using RMS and are using XPNET 3.0 or older, XPNET 4.1 should solve some previously reported
issues and it is recommended you recompile SKEL applications with the new XPNET 4.1 files.

If an application is being recompiled, the XPNET 4.1 version of SKELB, XPNET globals, and other SKEL files
used by the application, should be sourced in from the XPNET41 subvolume. The new application object code
built during this step should be placed on a volume/subvolume other than the location used for XPNET 4.0
compatible SKEL objects. For BASE24 5.3 and newer, if the move_obj_subvol_on define is set to true then the
appropriate and applicable *_obj_loc defines must also be altered, for example, base_obj_loc, atm_obj_loc, and
so on, to a separate destination.

The DUMP* files resident on the RDEBUG subvolume have been replaced with XPNET 4.1
versions and will reside on the XPNET (currently the XPNET41) subvolume for this version.
References in the compilation command files to the RDEBUG subvolume must be changed to
ensure the new XPNET 4.1 components are used.

If you are not recompiling, all application objects must be duplicated to a separate
NOTE
volume/subvolume to avoid library conflict errors. Library conflict errors will occur if the same
application process object is used under both XPNET 4.0 and XPNET 4.1.

You could also ALTER your current application PROCESS objects to utilize the XPNET 4.1 SKELB.
However, this would require you to ALTER PROCESS <pro>, LIBRARY $vol.XPNET41.SKELB on
ALL processes running a specific object and then STOP and START ALL of them.

NETLIB applications
Under XPNET 4.1 there is no XNLIBN subvolume (the same as XPNET 3.1 and newer). For NETLIB applications
that reference the XNLIBN subvolume for a run-time library, the library notation must be altered to point to the XNLIB
subvolume, for example, USEC and VersionChecker.

SKELB high pin migration library

XPNET 3.1 SKELB was changed to automatically include the high pin migration library. See SCR 3542. This change
was carried forward into XPNET 4.1.

12
 SCR #3542 SKELB - rel3^ver1^sutl15^20101115
15-NOV-10 - rel3^ver0^sutl34^20101115
Reference: Internal
Symptom: None
Problem: Customers had to manually bind in the
skel migration library.
We are finding that almost
all customers run with this and that it is now an
inconvenience for them.
Change: We are now building it into the release version of
skel.
A new SKEL bind file, SKELMLBU, will build
"SKELOPIN" (Skel-LoPin), a low-pin-only version of SKEL
for customers who do want to run lowpin.
This bind file
removes the ACI subsitution procedures AWAITIO,
GETCRTPID and MYPID.
Implementation: Since SKELB is run as a user library, do
the following only after taking appropriate action to
avoid library conflicts.
Install SKELB on the XPNET
subvol.
If on a RISC machine, accelerate SKELB as shown
in the SKELAXCL file.
Dependencies: None.

If standard SKELB BASE24 applications are required to run as high PIN processes then MYPID and GETCRTPID
from the Migration Library needs to be bound into SKELB. The Migration Library AWAITIO procedure is required by
all SKELB BASE24 application processes. (See Appendixes A and B for details of the Migration Library and the
obey files provided to enable the binding of the appropriate procedures.) The files resulting from this step need to be
renamed as described in the obey files. For payload processing applications the APPLIBB bind step will be required
(see the BASE24 Application Programming Reference Manual for steps on building the APPLIB).

Link the NETWORK object file

The standard NETB file builds an object file with HIGHPIN ON. If the XPNET process is run high, then all application
processes running under the XPNET process must cope with a high opener, if not then the appropriate line in the
NETB file should be altered to set HIGHPIN OFF.

Obey the XPNET41.NETBC file to build a NETWORK object file on the XPNET41 subvolume. The standard NETB
creates an XPNET object named NEWNET unless the object statement has been modified.

Accelerate TNS code

If you are using an Itanium-based or an X.86-based NS-series server, some of the non-native objects (utilities,
external protocols and pathway servers) installed for XPNET 4.1 should be accelerated to maximize performance.

Acceleration for Itanium-based NS-series systems

If you are using an HP NonStop™ NS-series server (H-series or J-series NonStop™ OS), TNS objects installed for
XPNET 4.1 must be accelerated using HP’s Object Code Accelerator (OCA) utility.

13
TACL routines have been provided to invoke the OCA utility for the objects which should be accelerated. On
XPNET41, the OCAALL macro should be executed from the TACL prompt. This will accelerate all the necessary
objects on the XPNET subvolume, including any CTS/E protocols the customer has purchased.

On the NSCRIBE subvolume, a TACL routine named OCAEMSP is provided to accelerate the EMSPERUS utility.
Since this utility uses the OCABUILD TACL routine from the XPNET subvolume and that subvolume has been
installed as XPNET41 under these installation procedures, the OCAEMSP file must be edited to change the text
“xpnet.ocaBUILD” to “XPNET41.ocaBUILD”. After making the change to the OCAEMSP file, run OCAEMSP from a
TACL prompt to accelerate the EMSPERUS object.

If the non-native version of the XNLIB run-time library is used(code 100 file named “XNLIB” located on the XNLIB
subvolume), there is an OCA TACL routine named OCAXNLIB on the XNLIB subvolume that can be used to
accelerate the XNLIB object. Since this utility uses the OCABUILD TACL routine from the XPNET subvolume and
that subvolume has been installed as XPNET41 under these procedures, the OCAXNLIB file must be edited to
change the text “xpnet.ocaBUILD” to “XPNET41.ocaBUILD”. After making the change to the OCAXNLIB file, run
OCAXNLIB from a TACL prompt to accelerate the XNLIB object.

Acceleration for X.86-based NS-series systems

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. On
XPNET41, the OXAALL macro should be executed from the TACL prompt. This will accelerate all the necessary
objects on the XPNET subvolume, including any CTS/E protocols the customer has purchased.

On the NSCRIBE subvolume, a TACL routine named OXAEMSP is provided to accelerate the EMSPERUS utility.
Since this utility uses the OXABUILD TACL routine from the XPNET subvolume and that subvolume has been
installed as XPNET41 under these installation procedures, the OXAEMSP file must be edited to change the text
“xpnet.oxaBUILD” to “XPNET41.oxaBUILD”. After making the change to the OXAEMSP file, run OXAEMSP from a
TACL prompt to accelerate the EMSPERUS object.

If the non-native version of the XNLIB run-time library is used (code 100 file named “XNLIB” located on the XNLIB
subvolume), there is an OCAX TACL routine named OXAXNLIB on the XNLIB subvolume that can be used to
accelerate the XNLIB object. Since this utility uses the OXABUILD TACL routine from the XPNET subvolume and
that subvolume has been installed as XPNET41 under these procedures, the OXAXNLIB file must be edited to
change the text “xpnet.oxaBUILD” to “XPNET41.oxaBUILD”. After making the change to the OXAXNLIB file, run
OXAXNLIB from a TACL prompt to accelerate the XNLIB object.

EMS template installation steps

See the NET24-XPNET Event Management Manual for full details of ACI’s implementation of EMS support in
XPNET.

Merge XP EMS templates with other templates

Two files (TMPLIN and TMPLMAKE) are provided with the NSCRIBE subvolume to merge all template files provided
on ACI release subvolumes into one file (TMPLNRES) on the NSCRIBE subvolume. The GOINST step (below)
merges TMPLNRES, SPANNRES, and CUSTNRES creating B24NRES and then merges B24NRES and HP
NonStop EMS templates to build EMSNRES.

14
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 NSCRIBE subvolume as shown below.

VOLUME $TEST.NSCRIBE
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. You may execute VHS
replacement of SUDOTERM for NS-series systems at this point, but you must return here and complete the EMS
template installation steps before executing Stop and start EMS distributors in a phased implementation, or Update
Pathway configuration file in a light-switch implementation)

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:

From the DDL compile step

*** WARNING *** C OUTPUT DIAGNOSTICS:

*** WARNING *** Extra level of reference introduced in
C's union - u_a_c

From the TEMPLI step

*** WARNING 42 -- SSID abbreviation TCP is duplicated:

> It is owned by ACI , subsystem number 781, in file $DATA01.N30TCPL.TCPxxPO.
> It is owned by TANDEM , subsystem number 220, in file $SYSTEM.SYS00.TEMPLATE.
*** 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.

15
 DELETE DEFINE =_EMS_TEMPLATES

{For a phased implementation use:}

ADD DEFINE =_EMS_TEMPLATES, CLASS MAP, FILE $TEST.NSCRIBE.EMSNRES

{For a light-switch implementation use:}

ADD DEFINE =_EMS_TEMPLATES, CLASS MAP, FILE $TEST.SCRIBE.EMSNRES

The define also needs to be added to each Server-NCPI definition within the pathway configuration.

Create an EMS EVENTCX file

If an event customer extension file is required to display probable cause and recommended action on specific events
(via EMSPERUS or HP’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 HP’s ViewPoint Manual for information about how
VIEWPOINT uses the EVENTCX file.)

A utility on the NSCRIBE 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 file CXREAD, which is
also on the NSCRIBE 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 NSCRIBE file named EMCLDDLS.) The template file names supplied with this release and the associated
subsystem literal names are provided below.

network
$TEST.XPNET41.NETTPLS (ACI-SSN-XPNET-L)
server-ncp
$TEST.XPNET41.SNCPTPLS (ACI-SSN-XPSVNCP-L)
server-ncpi
$TEST.XPNET41.NCPTPLS (ACI-SSN-XPSNCPI-L)
server-path
$TEST.XPNET3.PATHTPLS (ACI-SSN-XPNTCTSS-L)
Performance Monitoring modules
$TEST.NAPMSOBJ.SSRVTPLS (ACI-SSN-XPSSRV-L)
$TEST.NAPMSOBJ.PMONTPLS (ACI-SSN-XPPMON-L)

Update the EVENTCX file with the NETWORK, server-NCP and server-path events as shown below. If any optional
modules (for example, Performance Monitoring) are being installed, update the EVENTCX as appropriate.

16
 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.

VOLUME $TEST.NSCRIBE
DELETE DEFINE =_EMS_TEMPLATES
ADD DEFINE =_EMS_TEMPLATES, FILE $TEST.NSCRIBE.EMSNRES
RUN CXUTIL Enter EVENTCX filename --

EVENTCX

Enter Template filename--

NOTE $TEST.XPNET41.NETTPLS

SSID = ACI.XPNET.0 Correct [y]/N

Enter Template filename --

type next file name

(or press enter if done)

DELETE DEFINE =_EMS_TEMPLATES

FUP COPY can be used to combine $TEST. NSCRIBE.EVENTCX and the site EVENTCX into one file for use by
EMSPERUS and ViewPoint.

Update EMS filters

EMS filters written for earlier releases of XPNET may require amendment for XPNET 4.1. You may wish to add new
event filters to take account of the new XPNET 4.1 events.

VHS replacement of SUDOTERM for NS-series systems

The SUDOTERM utility version rel2^ver0^sudo05^060323 is not supported on NS-series Systems.

ACI recommends using HP’s Virtual Hometerm Subsystem (VHS) as the preferred replacement for SUDOTERM.
Three files are released on the SCRIBE subvolume to assist in the configuration of a VHS environment:

VHSSEG
TACL segment file for the VHS_MAKE macro to build the VHS environment.

MYDEFS
Edit input file to VHS_MAKE with configuration information, that is location of VHS save and log files, PPD
names for VHS and its subsystems, and so on.

GOMAKE
Obey file to execute the VHS_MAKE macro.

17
The following steps can be used to build a VHS system to replace $SUDO:

1. Edit the MYDEFS configuration file to change PPD names and volume/subvolume locations to meet user
specific requirements. Refer to HP’s Virtual Hometerm Subsystem (VHS) Manual for detailed information about
these configuration parameters. The following is the contents of the MYDEFS configuration file.

--
-- This is the input file for the MAKE_VHS macro.
--
VHS-PPD $PPD1 -- PPD of the VHS process
VHS-PATHMON-NAME $PPD2 -- PPD of the VHS Pathway
VHS-BSVR-NAME $PPD3 -- PPD of the VHS Browser
VHS-ENV-NAME A1234567 -- VHS environment name
VHS-LOG-SVOL $VVVVVVVV.SSSSSSSS -- VOLUME/SUBVOL for LOG and
-- PROMPT files
VHS-SAVE-FILE $VVVVVVVV.SSSSSSSS.SAVE0000 -- SAVE file location and form
VHS-PRI-COLL $PPD4 -- Existing EMS collector
VHS-OWNER-NAME USER.GROUP -- PATHWAY owner
VHS-VOLSVOL $VVVVVVVV.SSSSSSSS -- Location used when creating
-- startup command files

2. Run GOMAKE to create the VHS environment. The following files will be created on the VHS-VOLSVOL:

AAREADME – Readme file

GOCOLD - Cold start the PATHWAY part of VHS
GOCOOL - 'Cool' start the VHS PATHWAY
GODOWN - Stop VHS
GOVHSL - Go to the VHS PATHWAY log facility
GOVHSP - Go to the VHS PATHWAY prompt facility
GOVHSL - Go to the VHS PATHWAY log facility
VHSBCONF - Configuration file for VHS (env name and
prompt file location.
VHSINSP - Contains INSPECT/eINSPECT commands
VHSSTART - OBEY file for starting VHS application
VHSSTOP - Terminates VHS
ZVHSCONF - VHS PATHMON configuration
ZVHSDEFS - More VHS PATHWAY configuration
ZVHSSTRT - Start VHS PATHWAY servers

3. Edit the VHSINSP file to enable/change commands to meet user specific requirements. This file contains
examples of INSPECT/eINSPECT commands similar to the INSPECT commands found in the STRTSUDO obey
file.

18
 == THE DEFAULT COMMANDS FOR TNS PROGRAMS ARE:
== save
== stop
== exit
== THE DEFAULT COMMANDS FOR TNS/E PROGRAMS ARE:
== save
== kill
== exit
== Explanations for the following examples can be
== found in the VHS Manual from HP:
== PROGRAMFILE $VOL.SVOL.OBJECT
== SOME INSPECT COMMANDS
== EPROGRAMFILE $VOL.SVOL.NATIVE
== SOME EINSPECT COMMANDS
== PROCESS $PPD
== SOME INSPECT COMMANDS
== EPROCESS $PPD
== LANGUAGE <C/C++/COBOL/TAL/COBOL/SCOBOL, et cetera>
== SOME INSPECT COMMANDS
== ELANGUAGE <C/C++/PTAL, et cetera>
== SOME INSPECT COMMANDS

4. Obey VHSSTART to start VHS ($SUDO) and obey GOCOLD to start the VHS Pathway system which is used to
control VHS and monitor log messages. Refer to HP’s Virtual Hometerm Subsystem (VHS) Manual for detailed
information about using VHS, the VHS Browser and VHSCI.

19
Phased implementation tasks
The following steps involve the phased replacement of the XPNET 4.0 system with XPNET 4.1 components and will
impact the operational system. If a phased implementation is not required then this section should be skipped and
the tasks described in Light-switch implementation tasks should be followed.

Careful planning must precede the execution of these steps, particularly on the production system.

Stop and start EMS distributors

If you continued without completing the EMS template merge described in Merge XP EMS templates with other
templates, complete that step before proceeding.

EMSPERUS and any EMS distributors should be stopped and started at this point to pick up the new EMS
templates.

Implementation of a NET24 system

This section explains the steps involved in creating a usable NET24 network using the N24SETUP macro.

The NET24-XPNET Network Control Operations Guide contains information regarding the configuration of a NET24
system (system components, naming conventions, utility programs, and so on).

For discussion purposes, the NET24 system volume is referred to as $TEST and the NET24 system name is
referred to as “XN40”.

Modify N24SETUP file

The N24SETUP macro is written to load the main setup macro as a segment (file N24SEG). In order for N24SETUP
to know where the N24SEG file is (when being run from any subvolume on the HP NonStop system), the
n24setup_location_subvol variable in the N24SETUP file must be set with the appropriate volume name.

Sample commands:

TACL 1> volume $TEST.XPNET41

Edit the N24SETUP file and change the following line:

#SET n24setup_location_subvol $VOLUME.XPNET

to

20
 #SET n24setup_location_subvol $

TEST.
XPNET41

Modify the N24DEFS file

The N24DEFS file must be FUP DUP’d from the XPNET41 subvolume to the XN41CNTL subvolume (since the
name of the network, as mentioned above, will be "XN41").

Sample commands:

TACL 1> volume $TEST.XN41CNTL

TACL 2> fup dup XPNET41.N24DEFS, *

See Appendix G in the NET24-XPNET Installation Guide for an explanation of each define in the N24DEFS file. For
the purpose of this example, N24DEFS will be edited to set the defines to the following values (obviously, the actual
values you give these defines will depend on your unique situation):

21
 MIGRATION-ONLY : YES <- YES/NO to create only migration files
REPLACE-ALL-FILES : NO <- YES/NO to replace all files with new
XPNET-CODE-LOCATION : $
XNLIB-CODE-LOCATION : $VOL.XNLIB <- location of XNLIB code

TEST.
xpnet41 <- location of XPNET code
TANDEM-SYSTEM-NAME : \

SYS1
<- Tandem system to place network on
TANDEM-VOLUME-NAME :

$TEST
<- Tandem volume to place network on
NETWORK-NAME :

XN40
<- 4 alphanumeric (PROD, TEST, and so on)
PPD-PREFIX :

T
<- 1 alpha character
OPTIONAL-DATA-LOCATION : N/A <- N/A or enter \sys.$volume.subvolume
OPTIONAL-TPLT-LOCATION : N/A <- N/A or enter \sys.$volume.subvolume
DEFAULT-HOMETERM :

$SUDO
<- default hometerm PPD name
OWNER-USERID :

154,70
<- pathway owner ID
EMS-COLLECTOR :

$0
<- EMS collector PPD
SCRIBE-CODE-LOCATION :

$TEST.
NSCRIBE <- location of SCRIBE code
ONCF-SECURITY : OFF <- ON/OFF/DETAIL
NUMBER-OF-NODES : 1 <- number of nodes in the NET24 system
STARTING-NODE-ID : A <- node ID of first node, for example,
p1A^node
LOGICAL-NET-ID : 1 <- Identifier for this logical network
XPMON-ONLY :

NO
<- YES/NO Use XPMON instead of Pathway

Run the N24SETUP macro

The N24SETUP macro is located on the XPNET41 subvolume. To run the macro the current volume must be where
your N24DEFS file is located.

22
 TACL 1> volume $TEST.XN40CNTL
TACL 2> run XPNET41.N24SETUP

The following files will be created by N24SETUP:

XN41CNTL(Pathway):

AAREADME EMSPLOCL GONCP GONET24 GOOSSXM L1CONF PATHCONF

N24DEFS N24SEG N24SETUP OSCONF PATHCOLD PATHCOOL PATHSTOP

PATHSTRT PURGENET SHUTDOWN STOPLOG S TRTLOG

XN41CNTL(XPMON):

AAREADME EMSPLOCL GONCP GONET24 GOOSSXM GOXMON GOXNCXP

L1CONF NODECONF OSCONF PURGENET STOPLOG STOPXMON STRTLOG
XPCONF

XN34DATA(Pathway):
NCSP NCSS NCSS0 NMAP NMAP0
NMAP1 NSEC NSEC0 SBAP SBAS

XN34DATA(XPMON):
NCSP NCSS NCSS0 NMAP NMAP0
NMAP1 NSEC NSEC0 SBAP SBAS

XN34TPLT(Pathway and XPMON)

AYYMMDDX LCONF NEF

Configure Pathway environment (if not using XPMON)

Typically, a customer will use either the Pathway environment or the XPMON environment, so you only need to
proceed with this if not using XPMON.

The Pathway configuration file, $TEST.XN41CNTL.PATHCONF in this example, contains all of the PATHWAY, TCP,
SERVER and PROGRAM settings for the Pathway environment. The user may wish to edit this file to alter settings
for CPUs, program priorities, unique PPD names, or adjust it in any other way that the user feels necessary.

The necessary servers for XPNET 4.1 phased migration are:

SERVER-N24LNCF
The Logical Network Configuration File (LCONF) file maintenance server. This server requires the following
ASSIGN statements in its definition:

OMF
Online Maintenance File for auditing

23
 OMFT
Online Maintenance File Template

This server also allows an optional ASSIGN statement for the default LNCF/LCONF filename:

LNCF
Logical Network Configuration File default

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. The ASSIGN statements must point to the XPNET 4.1 version of these files:

NCSP
Network Control Security Profile file

NCSS
Network Control Security Specification file

OMF
Online Maintenance File for auditing

OMFT
Online Maintenance File Template

SERVER-N24NCSS
The Network Control Security Specification file maintenance server. This server requires the following ASSIGN
statements in its definition which must point to the XPNET 4.1 version of these files:

NCSS
Network Control Security Specification file

OMF
Online Maintenance File for auditing

OMFT
Online Maintenance File Template

SERVER-N24SEC
The NET24 Security file server for Pathway security. This server requires the following ASSIGN statements in its
definition which must point to the XPNET 4.1 version of these files:

NSEC
NET24 Security file

24
 OMF
Online Maintenance File for auditing

OMFT
Online Maintenance File Template

This server also accepts an optional PARAM statement, OMFFILE-RETENTION, which sets the number of
OMF files that will be 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.

For NCS access to the migrated XPNET 4.1 nodes the NET24 XPNET 4.1 NCS screen must be
used. To use the NET24-XPNET 4.1 NCS screen the following statement must be added to the
SERVER-NCS declaration:
NOTE

SET SERVER STARTUP “$TPMN,SERVER-NCP403”.

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
the NCS screen.

LOGON-NET24
The 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.

Start NET24 Pathmon

After all edits have been completed, the user will implement the MIGPCONF as the Pathway configuration by
obeying the PATHCOLD file.

Sample commands:

TACL 1> volume $TEST.XN40CNTL

TACL 2> obey PATHCOLD

Obeying the PATHCOLD file starts a PATHMON process and configures it using the MIGPCONF, subsequently
creating a PATHMON configuration file, XN40CNTL.PATHCTL.

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.

25
Once the PATHCOLD obey file is finished running, your Pathway environment is configured and running as
PATHMON process $XPMN (in this example).

Configure XPMON environment (if not using Pathway)

Typically, a customer will use either the Pathway environment or the XPMON environment, so you only need to
proceed with this if not using Pathmon.

The XPMON configuration file, $TEST.XN41CNTL.XPCONF in this example, contains XML of all the SERVER and
PROGRAM settings for the XPMON environment. The user may wish to edit this file to alter settings for CPUs,
program priorities, unique PPD names, or adjust it in any other way that the user feels necessary.

The necessary servers for XPNET 4.1 phased migration are:

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: The format of the NCSP did not change from
XPNET 4.0 to 4.1, so your existing XN34DATA.NCSP file can be used with XPNET 4.1. The profiles will need to
be updated to control access to the new commands and attributes added to ONCF under XPNET 4.1 (or else the
new commands will fail with a security violation).

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 $TEST.XN40CNTL.XPCONF 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>$A0</file> </assign>
<assign name="ALT-EVT"> <file>$0</file> </assign>
<assign name="NCSP"> <file>\SYS1.$TEST.XN41DATA.NCSP </file> </assign>
<assign name="NCSS"> <file>\SYS1.$TEST.XN41DATA.NCSS </file> </assign>
<assign name="NMAP"> <file>\SYS1.$TEST.XN41DATA.NMAP </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

26
 screens. This process will bring in the XPNET 4.1 version of the following files:

NCSS
Network Control Security Specification file

NOTE Additional information about NCSS is in the next topic, NCSS conversion.

OMF
Online Maintenance File for auditing

OMFT
Online Maintenance File Template

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:

SBAS
Service Based Architecture Security file

SBAP
Service Based Architecture Security Profile file

OMF
Online Maintenance File for auditing

OMFT
Online Maintenance File Template

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:

SBAS
Service Based Architecture Security file

SBAP
Service Based Architecture Security Profile file

OMF
Online Maintenance File for auditing

OMFT
Online Maintenance File Template

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 the

27
NCS screen.

NCSS conversion

If you are moving from XPNET 3.1 to newer releases, the size of the NCSS file increased from XPNET 3.1 to
XPNET 3.2 to support the SHA-256 password hash algorithm. All of the new data was appended to the end of the
file. However, the following step will need to be done before you accesss this file.

Use a space “ “ as the pad character.

FUP COPY XN31DATA.NCSS, XN41DATA.NCSS, PAD “ “

In order to simplify migrations to Rel. 3.2, 3.3 and newer, a conversion program was written for the NCSS. This is to
assist users in moving from Rel 3.1, to 3.2 and newer releases of XPNET.

This conversion program copies all the 3.1 NCSS fields to the 4.1 NCSS fields and overwrites the ten previous
password history fields with “-CONVERTED-TO-R41”. The current 3.1 password field is copied to XPNET 4.1. This
gets modified the first time the user logs into NCPCOM / NCS. They will be forced to change their password, which
will overwrite the old password field and update the new password in the NCSS file using the new SHA-256 hash.
This is only allowed if the SET USER succeeds with a valid password (from the 3.1 NCSS file).

In addition, the conversion program copies all the 3.1 NCSP records into the 4.1 NCSP file. As it does this it will add
a second record for each profile with all the access flags set to “N”. The new second record was added to support
the new XPNET 4.1 commands and for new commands in the future.

A report will be created and sent to the spooler with the outcome of the conversion.

To start the conversion, make a copy of the GOCONV macro and update the assigns to the appropriate file
locations.

fup purgedata <$vol.subvol.ncss40>

fup purgedata <$vol.subvol.ncss400>
fup purgedata <$vol.subvol.ncsp40>
clear all
assign ncss31, <$vol.subvol.ncss31>
assign ncss40, <$vol.subvol.ncss40>
assign ncsp31, <$vol.subvol.ncsp31>
assign ncsp40, <$vol.subvol.ncsp40>

Run NCSSCONV. Once this completes you can open the spooler and examine the outcome to verify that the
conversion was successful.

Start NET24 XPMON

After all edits have been completed, the user will implement the XPCONF as the XPMON configuration by obeying
the GOXNCXP and GOXMON files. Edit the GOXNCXP file and make sure that the proper “IN_XNC_FILE” file is
listed.

Sample commands:

28
 ==input XNC xml file (MISC)
#SET in_xnc_file XPCONF (this would the
$TEST.XP40CNTL.XPCONF and since this obey file is being run from the same subvol
you can just use “XPCONF”)
==output XNC file & prefix
#SET out_xnc_prefix XPCONF (this will create a new XPCONF#
file in the same subvol.
This file name will have to match the file name in the XPCONF xml file for the
server-ncp)

Sample commands:

<serverclass name="server-ncp">
<get name="gbl^ncpi"></get>
<assign name="XPCONF"> <file>

\SYS1.$TEST.XN40CNTL.XPCONF0

</file></assign>

Sample commands:

TACL 1> volume $TEST.XN40CNTL

Obeying the GOXNCXP file will first create an XPCONF0.

TACL 2> obey GOXNCXP

This starts the XPMON process and configures it using the XPCONF file.

TACL 3> obey GOXMON

If you want to enter ONCF commands utilizing PATHWAY, continue to use the PATH command followed by the
PATHMON name.

At the NCPCOM prompt enter the following:

NCPCOM Version REL4^VER1^NCPC00^20210930

(c) Copyright 1995 Applied Communications, Inc.

1 > PATH $XPMN

If you want to enter ONCF commands utilizing XPMON, use the GATE command followed by the XPMON PPD
name.

29
At the NCPCOM prompt enter the following:

NCPCOM Version REL4^VER1^NCPC00^20210930

(c) Copyright 1995 Applied Communications, Inc.

1 > GATE $XPMN

You can use both PATHMON and XPMON at the same time, however, this will require them to have different PPD
names.

Note also that when the EMS-COLLECTOR define in the N24DEFS file is set to something other than $0. Obey 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).

Load XPNET 4.1 data files

Load the ONCF security files that were created in Configure Pathway environment (if not using XPMON).

From FUP:

-VOLUME $TEST.TESTDATA
-COPY NCSS,XN40DATA.NCSS,SHARE

Copy the XPNET 4.0 NCSP to the XPNET 4.1 NCSP.

From FUP:

-VOLUME $TEST.TESTDATA
-COPY NCSP,XN40DATA.NCSP,SHARE

Create XPNET 4.1 NEF

Create an XPNET 4.1 NEF for each XPNET 4.0 node being migrated using the NEF template file created in
Configure Pathway environment (if not using XPMON).

The N24SETUP Macro should create a NEF file for the number of XPNET nodes specified in the N24DEFS file (up
to 26).

This can also be done manually

From FUP:

30
 -VOLUME $TEST.XN41DATA
-SET LIKE XN41TPLT.NEF
-CREATE N1ANEF
-CREATE N1BNEF
.
.
.

Make sure a NEF is created for each XPNET 4.0 node to be migrated.

Start NET24 logon

The Pathway file maintenance environment should now be tested and records added, if necessary. The NET24
Logon screen can be brought up on your terminal by simply obeying the GONET24 file on the $TEST.XN41CNTL
subvolume.

Sample commands:

TACL 1> volume $TEST.XN40CNTL

TACL 2> obey GONET24

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 can be
accomplished 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 password that you entered by retyping it in the NEW
PASSWORD field and pressing F1 again.

If you were utilizing the NSEC file in XPNET 4.0, you can continue to use this same file. So existing userid’s and
passwords will still apply.

Now you are logged onto the Pathway file maintenance system as SUPER/SUPER.

NET24-XPNET command and control security records should be updated to change the NCSS and NCSP files to
support the XPNET 4.1 commands. Update the profiles (NCSP) to reflect site-specific security for the new
commands.

See Appendices A through F of the NET24–XPNET 4.1 Installation Guide for full details on all of the Pathway file
maintenance screens.

Update XPNET 4.1 Pathway configuration file

Prior to making changes to the XPNET 4.1 PATHCONF file (as discussed in the following paragraphs), the current
PATHCONF file should be copied. This is to keep copies of the current 4.0 configuration files and to enable the
XPNET 4.0 system to continue running uninterrupted.

A migration NCP serverclass, “SERVER-NCP403” will need to be added for each HP Nonstop node.

The migration NCP Server should be added to the PATHCONF File as well as online. Configuration should be

31
similar to the example given below, (full details of Server-NCP params and assigns are given in the NET24-XPNET
Network Control Operations Guide).

TACL> PATHCOM $TPMN

=RESET SERVER
=SET SERVER ASSIGN PRI-EVT,\SYS1.$0
=SET SERVER ASSIGN NMAP,\SYS1.$TEST.XN40DATA.NMAP
[ PMONnn assigns are required for all Pathmons on remote
[ Tandems that are a part of the XPNET 4.0 production system.
[SET SERVER ASSIGN PMON01,\

sysname1.ppdname

[SET SERVER ASSIGN PMON02,\

sysname2.ppdname

=SET SERVER CPUS (0:1)

=SET SERVER CREATEDELAY 10 SECS
=SET SERVER DELETEDELAY 12 HRS
=SET SERVER HIGHPIN ON
=SET SERVER HOMETERM \SYS1.$SUDP
=SET SERVER LINKDEPTH 32
=SET SERVER MAXLINKS 32
=SET SERVER MAXSERVERS 3
=SET SERVER NUMSTATIC 1
=SET SERVER PARAM ALT-TIM-LMT "300"
=SET SERVER PARAM PRI-TIM-LMT "500"
=SET SERVER PARAM REFR-ERR-TIMEOUT “500”
=SET SERVER PARAM REFR-TIMEOUT “6000”
=SET SERVER PARAM RQST-TIMEOUT "30000"
=SET SERVER PARAM SINTERVAL "180000"
=SET SERVER PARAM TN-TIMEOUT "12000"
=SET SERVER PARAM XN-TIMEOUT "18000"
=SET SERVER PARAM SERVERCLASS "SERVER-NCP403"
=SET SERVER PRI 140
=SET SERVER PROCESS $MNC1
=SET SERVER PROCESS $MNC2
=SET SERVER PROCESS $MNC3
=SET SERVER PROGRAM \SYS1.$TEST.XPNET41.SVNCP
=SET SERVER VOLUME \SYS1.$TEST.TESTDATA
=ADD SERVER SERVER-NCP403

• The PPD name (PROCESS attribute) should be the same structure as the XPNET 4.0 Server-
NCP name with a different prefix, that is M - migration. The server class name should differ
from the existing Server-NCP (which should be left in place).
• The NMAP assign should point to the location of the new XPNET 4.1 NMAP, for example,
NOTE $TEST.XN40DATA.NMAP.
• A 4.1 Server-NCPI serverclass entry must be added to the PATHCONF file for each XPNET
process on all HP Nonstop nodes in the production pathway as well as online. Configurations
should be similar to the following example, (full details of Server-NCPI params and assigns are
given in the NET24-XPNET Network Control Operations Guide) .

Please note and follow the server naming conventions denoted below, for example, SRVR-NCPI40-<ln><node-id>

32
 TACL> PATHCOM $TPMN

=RESET SERVER
=SET SERVER ASSIGN PRI-EVT,\SYS1.$0
=SET SERVER ASSIGN NCSP,\SYS1.$TEST.XN40DATA.NCSP
=SET SERVER ASSIGN NCSS,\SYS1.$TEST.XN40DATA.NCSS
=SET SERVER ASSIGN NEF,\SYS1.$TEST.XN40DATA.N1ANEF
=SET SERVER ASSIGN NMAP,\SYS1.$TEST.XN40DATA.NMAP
=SET SERVER ASSIGN N-PROG, $TEST.XPNET41.NETWORK
=SET SERVER ASSIGN N-PPD, $M1AN
=SET SERVER DEFINE
=_EMS_TEMPLATES,FILE $TEST.NSCRIBE.EMSNRES
=SET SERVER AUTORESTART 0
=SET SERVER CPUS (2:1)
=SET SERVER CREATEDELAY 1 SECS
=SET SERVER DEBUG OFF
=SET SERVER DELETEDELAY 18 HRS
=SET SERVER HIGHPIN ON
=SET SERVER HOMETERM \SYS1.$SUDP
=SET SERVER LINKDEPTH 1
=SET SERVER MAXLINKS 32
=SET SERVER MAXSERVERS 1
=SET SERVER NUMSTATIC 1
=SET SERVER PARAM ALT-TIM-LMT "300"
=SET SERVER PARAM ENABLE-AUDIT "OFF"
=SET SERVER PARAM ENABLE-SECURITY "ON"
=SET SERVER PARAM PRI-TIM-LMT "300"
=SET SERVER PARAM XN-LOCK "ON"
=SET SERVER PARAM XN-TIMEOUT "18000”
=SET SERVER PARAM RQST-TIMEOUT "32737"
=SET SERVER PARAM SERVERCLASS "SRVR-NCPI40-1A"
=SET SERVER PRI 140
=SET SERVER PROCESS $M1AU (ASSOCIATIVE ON)
=SET SERVER PROGRAM \SYS1.$TEST.XPNET41.SVNCPI
=SET SERVER SECURITY "N"
=SET SERVER TMF OFF
=SET SERVER VOLUME \SYS1.$TEST.TESTDATA
=ADD SERVER SRVR-NCPI40-1A

The NCSS, NCSP, NEF, and NMAP assigns should all point to those files created in Configure Pathway environment
(if not using XPMON)..

The N-PROG assign will point to the XPNET 4.1 NETWORK object file. This assign will override what is in the NEF
or the ADD NODE command.

The N-PPD assign will need to be added to override the PPD name of the XPNET node in the 4.0 production
environment. This will allow the XPNET 4.1 object to run without getting a process_create error 10, but will not
require the NEF to be updated or the INFO NODE <node-name>,OBEYFORM output to be changed and then
altered later.

If present, the KILL and SPROUTE assigns should be removed from the NCPI server declarations.

Update Node configuration command files

The XPNET node configuration command file(s) <xn41conf> created in Copy XPNET 4.0 configuration should be

33
altered. The following changes should be made for each XPNET 4.1 node:

Delete the PATH,SERVER-NCPI-<ln><node-id> reference at the beginning of the <xn41conf> file.

Change all NETWORK references to point to the XPNET 4.1 network objects, for example, XPNET.NETWORK
becomes XPNET41.NETWORK.

Change the NODE STARTUP attribute to COMMAND if you haven’t done so previously.

Change the ADD NODE statement to include the “,DISABLED” attribute.

Sample command:

ADD NODE P1A^NODE,UNDER SYSNAME \TEST,DISABLED

Change all SKEL application PROGRAM attributes to point to the objects produced within Recompile SKEL
applications.

Change all SKEL application LIBRARY attributes to point to the XPNET 4.1 SKELB, for example,
$TEST.XPNET41.SKELB.

Change all NETLIB application PROGRAM attributes to point to the objects produced within Copy current application
subvolumes.

Change all NETLIB applications to reference their library location from the XNLIB subvolume as denoted in NETLIB
applications.

Add XPNET 4.1 nodes

For each XPNET 4.0 node in the current environment a corresponding XPNET 4.1 node must be added.

From XPNET 4.1 NCPCOM:

PATH $TPMN, SRVR-NCPI41-1A

SET USER <user>, password
OBEY <xn41conf>

This will add the XPNET 4.1 node to the NEF and the 4.1 NMAP. The above steps must be completed for each
node.

Stop the first XPNET node

Perform an orderly shutdown of the selected XPNET 4.0 node using the appropriate ONCF obey files or procedures
(including STOP NODE*xpobj*, STOP NODE*xpobj*) from XPNET 4.0 NCS or the XPNET 4.0 NCPCOM.

Sample commands:

34
 >PATH $TPMN, SERVER-NCP
>OBEY STOPP1A

From TACL stop the XPNET 4.1 node.

TACL> KILL $M1AN

From TACL stop the XPNET 4.0 NCPI server.

TACL> KILL $T1AU

From TACL stop the XPNET 4.1 NCPI server.

TACL> KILL $M1AU

Update Pathway configuration

The XPNET 4.0 NCPI server must be saved off and then altered for XPNET 4.1 compatibility.

Sample commands:

TACL> PATHCOM $TPMN

RESET SERVER
SET SERVER LIKE SERVER-NCPI-1A
ADD SERVER SRVR-NCPI40-1A
ALTER SERVER-NCPI-1A,PROGRAM $TEST.XPNET41.SVNCPI
ALTER SERVER-NCPI-1A,ASSIGN NEF, $TEST.XN40DATA.N1ANEF
ALTER SERVER-NCPI-1A,ASSIGN NCSS,$TEST.XN40DATA.NCSS
ALTER SERVER-NCPI-1A,ASSIGN NCSP,$TEST.XN40DATA.NCSP
ALTER SRVR-NCPI40-1A,RESET PROCESS
ALTER SRVR-NCPI40-1A,PROCESS $T1AU(ASSOCIATIVE ON)

The above changes must also be incorporated into the PATHCONF so they will not be lost during the next
PATHCOLD.

Do not restart the XPNET 4.1 NCPI from the NCPI40 serverclass (for example, start SERVER-
NOTE NCPI-1A rather than SRVR-NCPI40-1A) as this could result in wild-carded ONCF command
responses displaying information out of order, for example, not in alphabetic order.

Enable / start the first XPNET node

Start the appropriate SERVER-NCPI from PATHCOM.

35
Sample commands:

TACL> PATHCOM $TPMN

=START SERVER-NCPI-1A

Execute the appropriate ONCF commands from NCS or the standard XPNET 4.0 NCPCOM to invoke an orderly
startup of the node.

Sample commands:

>PATH $TPMN, SERVER-NCP

>ENABLE NODE P1A^NODE
>START NODE P1A^NODE, AUTO

Check the operation of the XPNET 4.1 node and its interaction with the remaining XPNET 4.0
NOTE nodes. When satisfied, repeat Stop the first XPNET node through Enable / Start the first XPNET
node for all remaining nodes.

The resulting mixed 4.0/4.1 XPNET system must be operated from an XPNET 4.0 based network control interface
(NCPCOM or NCS).

Sample commands:

TACL> RUN $TEST.XPNET.NCPCOM $TPMN

>PATH $TPMN,SERVER-NCP

New XPNET 4.1 commands are not accepted by a 4.0 interface. If a XPNET 4.1 feature is to be implemented or a
XPNET 4.1 attribute is to be added/altered this must be done from the XPNET 4.1. NCPCOM or the NET24-XPNET
4.1 NCS screen. From the XPNET 4.1 NCPCOM the PATH $TPMN,SRVR-NCPI41-1A command must be initiated.

Sample commands:

TACL> RUN $TEST.XPNET41.NCPCOM $TPMN

>PATH $TPMN,SRVR-NCPI41-1A

For NCS access to the migrated XPNET 4.1 nodes the NET24-XPNET 4.1 NCS screen must be used. To use the
NET24-XPNET 4.1 NCS screen the SET SERVER STARTUP “$TPMN, SERVER-NCP403” statement must be
added to the NCS server declaration.

Reconfigure XPNET 4.1 nodes for long term use

After all nodes have been migrated to XPNET 4.1 the following steps must be completed.

36
Optionally alter NODE STARTUP
If Server-NCPI is required to automatically START,AUTO the XPNET process (and START,WARM the XPNET
process after a failure), then the NODE STARTUP attribute should be set to AUTOMATIC at this time.

TACL> RUN $TEST.XPNET41.NCPCOM $TPMN

>ALTER NODE *, STARTUP AUTOMATIC

Relocate XPNET 4.1 code

The XPNET 4.0 subvolumes will be renamed in preparation for moving the XPNET 4.1 subvolumes into their place.

FUP:
-RENAME XPNET.*,OXPNET.*
-RENAME SCRIBE.*,OSCRIBE.*
-RENAME RDEBUG.*,ORDEBUG.*
-RENAME ACIUTILS.*,OACIUTLS.*
-RENAME ACILIBI.*,OACILIBI.*
-RENAME XNLIB.*,XNLIB34.*
-RENAME XPNET41.*,XPNET.*
-RENAME NSCRIBE.*,SCRIBE.*
-RENAME NACIUTLS.*,ACIUTILS.*
-RENAME NACILIBI.*,ACILIBI.*
-RENAME XNLIB40.*,XNLIB.*

Alter all process and node attributes to point to the XPNET subvolume versus the XPNET41 subvolume. Note that
the processes must be stopped to alter the LIBRARY attribute. A “STOP PRO” command must be initiated prior to
the “ALTER PRO,LIB” command. Your site should coordinate the “STOP PRO” commands during non-peak hours.
All processes pointing to the same object file should be stopped at the same time to avoid library conflict errors.

Sample commands:

TACL> RUN XPNET.NCPCOM $TPMN

1>STOP PRO *, UNDER SERVICE AUTH
2>ALTER PRO *, LIB $TEST.XPNET.SKELB,UNDER SERVICE AUTH
3>START PRO *, UNDER SERVICE AUTH
…
4>ALTER NODE *,PROGRAM $TEST.XPNET.NETWORK

Relocate XPNET 4.1 data

The XPNET 4.0 data files must be moved out of the way and the XPNET 4.1 data files should be moved into their
location.

37
 FUP:
-VOLUME $TEST.TESTDATA
-RENAME NCSS,ONCSS
-RENAME NCSS0,ONCSS0
-RENAME NCSP,ONCSP
-RENAME <all XPNET 4.0 nef files>,O<all XPNET 4.0 nef files>
-VOLUME $TEST.XN40DATA
-RENAME NCSS,TESTDATA.NCSS
-RENAME NCSS0,TESTDATA.NCSS0
-RENAME NCSP,TESTDATA.NCSP
-RENAME <XPNET 4.1 nef files>,TESTDATA.<XPNET 4.1 nef files>
-VOLUME TESTDATA
-ALTER NCSS,ALTFILE(0,$TEST.TESTDATA.NCSS0)
-ALTER NMAP,ALTFILE(0,$TEST.TESTDATA.NMAP0)
-ALTER NMAP,ALTFILE(1,$TEST.TESTDATA.NMAP1)

PATHCONF changes
Server declarations must be altered online and in the PATHCONF file to point to the altered locations of the XPNET
4.1 NCSP, NCSS, NEF, and NMAP. Servers requiring changes are the NCP, NCPI, NCSS, NCSP.

Server declarations must be altered online and in the PATHCONF file to point to the altered locations of the XPNET
software (for example, $TEST.XPNET41 altered to $TEST.XPNET).

Scup copy the XPNET 4.1 POBJ into the production POBJ file.

Remove migration servers (for example, SRVR-NCPI41-nn, SERVER-NCP413).

Remove saved servers (for example, SRVR-NCPI34-nn).

Performance monitoring subsystem tasks

If you are running the Performance Monitoring subsystem then it should be stopped and restarted at this point to
load the XPNET 4.1 modules. Use the standard shutdown procedures for your installation (these will vary according
to the display product in use). Once PERFMON is stopped you should initiate a PERFGEN and a restart of
PERFMON. See the NET24 Performance Monitoring System Installation Guide for specifics on PERFMON and
PERFGEN.

Final cleanup
Shutdown the NET24-XPNET pathway environment.

TACL> OBEY $TEST.XN40CNTL.SHUTDOWN

Purge the NET24 NMAP.

TACL> PURGE $TEST.XN40DATA.NMAP*

38
XPNET 4.1 back out procedures
Procedures are being provided to back out XPNET 4.1 if necessary. The following can be completed at any point
prior to completing Reconfigure XPNET 4.1 nodes for long term use and Final cleanup.

Stop XPNET 4.1 Node(s) and the respective NCPI server. The following is an example assuming that one node has
been migrated and is to be backed out:

{Stop the XPNET 4.1 node}

TACL> RUN XPNET.NCPCOM $TPMN

1>STOP NODE P1A^NODE
2>STOP NODE P1A^NODE
3>EXIT

{Stop the XPNET 4.1 NCPI}

TACL>KILL $T1AU

{Reset PATHMON}

TACL> PATHCOM $TPMN

DELETE SERVER SERVER-NCPI-1A
SET SERVER LIKE SRVR-NCPI34-1A
ADD SERVER SERVER-NCPI-1A
FREEZE SERVER SRVR-NCPI41-1A
STOP SERVER SRVR-NCPI41-1A
STOP SERVER SRVR-NCPI41-1A
ALTER SERVER SRVR-NCPI41-1A,RESET PROCESS
ALTER SERVER SRVR-NCPI41-1A,PROCESS $M1AU(ASSOCIATIVE ON)
THAW SERVER SRVR-NCPI41-1A
START SERVER SERVER-NCPI-1A

Sample commands:

TACL> RUN XPNET.NCPCOM $TPMN

1>START NODE P1A^NODE
2>EXIT

39
Light-switch implementation tasks
The following steps involve the replacement of the XPNET 4.0 system with a complete XPNET 4.1 system during a
system shutdown. If a phased implementation is required, then the tasks described in Phased implementation tasks
should have been followed and this section is not required.

Careful planning must precede the execution of these steps, particularly on the production system.

Update Pathway configuration file

Prior to making changes to the PATHCONF file (as discussed in the following paragraph), the current PATHCONF
file should be copied. This is to keep copies of the current 4.0 configuration files and to enable the XPNET 4.0
system to continue running uninterrupted.

The KILL and SPROUTE assigns should be removed from the NCPI server declarations.

Stop and start EMS distributors

If you continued without completing step Merge XP EMS templates with other templates, complete that step before
proceeding.

EMSPERUS and any EMS distributors should be stopped and started at this point to pick up the new EMS
templates.

Performance monitoring subsystem tasks

If you are running the Performance Monitoring subsystem then it should be stopped at this point to load the XPNET
4.1 modules. Use the standard shutdown procedures for your installation. (These will vary according to the display
product in use.) Rename the new code into the correct location:

-RENAME $TEST.APMSCNTL.*,$TEST.OAPMSCNT.*
-RENAME $TEST.APMSOBJ.*, $TEST.OAPMSOBJ.*
-RENAME $TEST.NAPMSCNT.*,$TEST.APMSCNTL.*
-RENAME $TEST.NAPMSOBJ.*,$TEST.APMSOBJ.*

Stop the XPNET 4.0 system

Perform an orderly shutdown of the XPNET 4.0 nodes using appropriate ONCF obey files or procedures (including
STOP NODE xpobj, STOP NODE xpobj) from NCS or the standard XPNET 4.0 NCPCOM.

Sample commands:

>PATH $TPMN
>OBEY STOPP1A
>OBEY STOPP1B
and so on

40
Stop XPNET 4.0 Pathway system
The Pathway system needs to be stopped. Stop the XPNET 4.0 Pathway system by obeying
TESTCNTL.PATHSTOP (or STOP TERM *; FREEZE SERVER *; STOP SERVER *; STOP SERVER *; STOP TCP *;
SHUTDOWN!; from PATHCOM).

Rename XPNET 4.0 data files

Rename the XPNET 4.0 data files to be used to load the corresponding XPNET 4.1 data files:

From FUP:

-VOLUME TESTDATA
-RENAME NMAP, ONMAP
-RENAME NMAP0,ONMAP0
-RENAME NMAP1,ONMAP1
-RENAME NCSS, ONCSS
-RENAME NCSS0,ONCSS0
-RENAME NCSP, ONCSP

Complete the following command for each node configured within this environment:

-PURGE TESTDATA.N1ANEF
-PURGE TESTDATA.N1BNEF

continue as needed.

Create XPNET 4.1 data files

To create the XPNET 4.1 data files (NEF, NMAP, NCSS, NCSP) obey the NCPDFUP, NETDFUP and SECDFUP files
provided on the XPNET41 subvolume:

From FUP:

-VOLUME TESTDATA
FUP / IN NETDFUP /
FUP / IN SECDFUP /
FUP / IN NCPDFUP /

Load XPNET 4.1 data files

Load the ONCF security files that were created in the previous step.

After successfully running SECDFUP from the XPNET41 subvol, do the following:

From FUP:

41
 -VOLUME TESTDATA
-COPY ONCSS,NCSS,SHARE

Copy the XPNET 4.0 NCSP to the XPNET 4.1 NCSP.

From FUP:

-VOLUME TESTDATA
-COPY ONCSP,NCSP,SHARE

If the location of the NCSS and NCSP is being changed to TESTDATA as suggested, then the LCONF assigns for
these files must be changed accordingly.

Replace XPNET 4.0 objects with XPNET 4.1 objects

Prior to moving in the XPNET 4.1 code the current XPNET 4.0 objects should be renamed. The XPNET 4.0 objects
will be saved and moved to make way for the XPNET 4.1 objects.

Complete the following FUP commands:

From FUP:

{Rename old objects}

-RENAME XPNET.*, OXPNET.*

-RENAME SCRIBE.*, OSCRIBE.*
-RENAME RDEBUG.*, ORDEBUG.*
-RENAME ACIUTILS.*, OACIUTIL.*
-RENAME ACILIBI.*, OACILIBI.*
-RENAME XNLIB.*, OXNLIB.*

{Rename new objects }

-RENAME XPNET41.*, XPNET.*

-RENAME NSCRIBE.*, SCRIBE.*
-RENAME NRDEBUG.*, RDEBUG.*
-RENAME NACIUTLS.*, ACIUTILS.*
-RENAME NACILIBI.*, ACILIBI.*
-RENAME XNLIB40.*, XNLIB.*

Start XPNET 4.1 Pathway system

Start the Pathway system by obeying TESTCNTL.PATHCOLD (or RUN PATHMON/NAME ppdname /; PATHCOM/IN
PATHCONF/ppdname).

42
 PATHCOM /OUT $S.#XN40, PRI 140/ $TPMN
=OBEY PATHCONF

Configure the XPNET 4.1 system

Start the appropriate Server-NCPIs from PATHCOM.

Sample commands:

TACL> PATHCOM $TPMN

=START SERVER-NCPI-1A
=START SERVER-NCPI-1B
and so on

Execute the following ONCF commands from NCS or the standard XPNET 4.1 NCPCOM for each node. <xn40conf>
was created in Copy XPNET 4.0 configuration.

Sample commands:

>OBEY <xn40conf>
and so on

Start XPNET 4.1 nodes

If the XPNET 4.1 nodes are not configured for AUTOMATIC STARTUP manually start the nodes at this time (START
NODE xpobj).

From NCPCOM:

>PATH $TPMN
>OBEY START1A
>OBEY START1B
and so on

ONCF security files

If ONCF security is not required then PARAM ENABLE-SECURITY OFF should be included on all Server-NCPI
definitions.

Update SPROUTE and configuration files

ACI recommends that PREGEN be run at this time to ensure that all system components are running with the new
SPROUTE file.

43
The GOPRE file should contain a run command similar to the following:

RUN $TEST.XPNET.PREGEN/IN PRECMD,OUT $S.#PREGEN,NAME $TPRE/

Following a successful run and distribution of the SPROUTE, then a CONTROL NODE xpobj,
WARMBOOTSPROUTE command should be issued to all XPNET nodes with BASE24 application processes using
SPROUTE routing. It is no longer necessary to warmboot the application processes.

PREGEN will be required to be run when routing requirements change, new IPFs need to be processed, or new
XPNET nodes or logical networks are added.

Performance monitoring subsystem tasks

If you are running the Performance Monitoring subsystem then a Perfgen should be initiated at this time. Once
PERFGEN has successfully completed, start Perfmon using the standard procedures for your installation (these will
vary according to the display product in use). See the NET24 Performance Monitoring System Installation Guide for
specifics on Perfmon and Perfgen.

44
Appendix A: BASE24 applications and high PIN
operation
This appendix discusses the issues involved in ascertaining whether BASE24 application processes can run as high
PIN processes and lists those standard products that can run as high PIN processes and those that should run low.

Unsupported procedure calls

If an application process is intended to run as a high PIN process, then a range of procedure calls are no longer
possible. These include MYPID, LOOKUPPROCESSNAME on a high PIN process, and GETCRTPID and
PROCESSINFO if MYPID is passed as a parameter. Any application process that holds, uses or displays its own
PID cannot run high (without code changes), and where PIDs are held in an openers table then those processes
cannot run high (without code changes).

The ACI migration library

To maximize the number of BASE24 application processes that can run as high PIN processes, ACI produced a
BINDable code library which replaces some of these calls with new D-series, high PIN compatible calls. The two
procedure calls replaced are MYPID and GETCRTPID. (The migration library GETCRTPID will only work on high
PIN processes if MYPID is passed as a parameter.) Both will actually return a PID of cpu,255 on a high PIN process,
but will not generate errors. Thus, if the actual PID is required, the library calls will not enable the application code to
run high PIN, but, if, as is often the case, only the PPD name is required then the library calls will provide the
necessary information. The use of the library calls is assumed in the list below of BASE24 application processes that
can run high. (That is, several of the processes listed would not be able to run high without the use of the library
procedures.)

If it is required that these BASE24 application processes run as high PIN processes, then the replacement library
procedures should be bound into SKELB.

By default the MIGNLIB is bound into SKELB, no action is required to include this in the library.

This can be done manually, by removing the COMMENTs from the following lines in the BIND input file provided
(XPNET.SKELMLB). However, as this is the default, this step is not required.

@ADD CODE MYPID

@ADD CODE GETCRTPID

The resulting files should be renamed as per the notes at the end of the BIND input file to create a new version of
SKELB.

NOTE This step is mandatory if the ATM DCT or BASE DCT process is configured to run HIGHPIN ON.

This step should be undertaken at the same time as the bind step described in Appendix B if both are required.

45
HIGHPIN object file attribute
For application processes to be able to run high PIN, both the object files and any associated library files need to
have the HIGHPIN attribute set ON. This can be achieved at compile time, BIND time or via a BIND CHANGE.

The attribute is probably most easily configured using BIND CHANGE as follows:

>BIND
@CHANGE HIGHPIN ON IN

$vol.subvol.applobj

The standard ACI libraries have HIGHPIN set ON. The attribute will need to be included in the build
NOTE statement if the library is rebuilt for any reason. This will ensure the attribute is retained. The
attribute is included in the BIND input file provided to bind in the high pin migration library.

HIGHREQUESTERS object file attribute

To enable application processes to accept high PIN openers, the object file needs to have the HIGHREQUESTERS
attribute set ON. This can be achieved at compile time, BIND time or via a BIND CHANGE.

The attribute is probably most easily configured using BIND CHANGE as follows:

>BIND
@CHANGE HIGHREQUESTERS ON IN

$vol.subvol.applobj

If the XPNET process is to be run as a high PIN process, then HIGHREQESTERS ON is required
NOTE
for all application processes.

46
Appendix B: AWAITIO calls from SKEL
applications
This appendix discusses the issues involved in calling AWAITIO from SKEL-based applications running under
XPNET 4.1.

Unsupported procedure calls

Because the buffer area for messages from the XPNET process (and indeed any other opener) is now held in
extended memory (to support large messages), calls to AWAITIO on $RECEIVE will no longer complete
successfully.

The ACI migration library

To minimize the number of BASE24 application processes requiring a code change because of this enhancement,
ACI has produced a BINDable code library that replaces the AWAITIO call with an AWAITIOX call.

The replacement call will work in almost all situations where AWAITIO is called from a SKEL-based application.
However, if AWAITIO is called by a SKEL-based application process and the returned#bufaddr# is accessed directly
on a $RECEIVE read completion (rather than by calling NETBLOCKREADCOMPLETE), then the address will be
invalid as the buffer is now held in an extended segment (requiring a 32 bit address rather than the 16 bit address
supported by AWAITIO). This situation is extremely unlikely as processes would not typically call AWAITIO directly,
(and where they did would probably follow the call with a call to NETBLOCKREADCOMPLETE on $RECEIVE
completions), but where it does occur then a code change will be required to use AWAITIOX, RCV^AWAITIO or
NETREAD.

By default the MIGNLIB is bound into SKELB, no action is required to include this in the library.

47