IBM Sterling Connect:Direct

for UNIX

Administration Guide

Version 4.1
This edition applies to the 4.1 Version of IBM Sterling Connect:Direct for UNIX and to all subsequent releases
and modifications until otherwise indicated in new editions.

Before using this information and the product it supports, read the information in Notices, on page 97.

Licensed Materials - Property of IBM

IBM Sterling Connect:Direct for UNIX
Copyright IBM Corp. 1999, 2011. All Rights Reserved.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.

CDUNXAG1107
 Contents

Chapter 1 About Sterling Connect:Direct for UNIX 7

Server Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Process Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Command Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Session Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Sterling Connect:Direct for UNIX Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
User Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Process Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Archive Statistics Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sample Processes, Shell Scripts, and API Programs. . . . . . . . . . . . . . . . . . . . . 11
Sterling Connect:Direct for UNIX Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Sterling Connect:Direct for UNIX Configuration Files . . . . . . . . . . . . . . . . . . . . . 12
Sterling Connect:Direct for UNIX Directory Structure . . . . . . . . . . . . . . . . . . . . . 13
Sterling Connect:Direct for UNIX Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2 Maintaining Configuration Files 17

About the Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Modifying Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3 Maintaining the Initialization Parameters File 19

About the Initialization Parameters File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Updating Miscellaneous Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Updating the Path Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Updating the SNODE Work Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Updating the Node Name Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Updating the PAM Service Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Updating the Quiesce/Resume Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Updating the Priority Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Restricting the Use of Special Characters in the Run Directory . . . . . . . . . . . . . 23
Updating the Remote Node Connection Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IBM Sterling Connect:Direct for UNIX Administration Guide 3

 Contents

Updating the TCQ Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Adding and Updating the Sterling Connect:Direct Secure Plus Record
(Secure+ Record) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Updating the Global Copy Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Updating the Global Run Task Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Updating the Statistics File Information Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Updating the Server Authentication Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Updating the User Exit Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Updating the Firewall Navigation Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 4 Maintaining the Client Configuration File 35

About the Client Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Updating the API Configuration Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Updating the CLI Configuration Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Updating the Client Authentication Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 5 Maintaining the Network Map File 39

About the Network Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Sample Network Map Entry for Remote Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Updating the Local Node Connection Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Updating TCP/IP Settings for a Local Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Updating Remote Node Connection Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 6 Maintaining Access Information Files 53

User Authorization Information File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Sample User Authorization File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Updating the Local User Information Record Format . . . . . . . . . . . . . . . . . . . . . . . . 55
Updating the Remote User Information Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Updating the Strong Access Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Automatic Detection of Shadow Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Limiting Access to the Program Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Security Exit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 7 Maintaining Client and Server Authentication Key Files 65

About Client and Server Authentication Key Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Key File Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Updating Key File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Sample Client Authentication Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
About the Authentication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Server Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Client Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 IBM Sterling Connect:Direct for UNIX Administration Guide

 Contents

Appendix A Configuring Firewall Navigation 69

Implementing Firewall Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Firewall Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
TCP Firewall Navigation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
UDT Firewall Navigation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Firewall Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
TCP Firewall Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
UDT Firewall Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Blocking Outbound Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Session Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
TCP Session Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
UDT Session Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Appendix B Specifying IP Addresses, Host Names, and Ports 75

IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Host Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Multiple Addresses, Host Names, and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Using Masks for IP Address Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Appendix C Using Sterling Connect:Direct in a Test Mode 79

Processing Flow of the Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Preparing the NDMPXTBL Parameter Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Sample Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Glossary 85

Index 91

Notices 97

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

IBM Sterling Connect:Direct for UNIX Administration Guide 5

 Contents

6 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 1

About Sterling Connect:Direct for UNIX

IBM Sterling Connect:Direct for UNIX links technologies and moves all types of information
between networked systems and computers. It manages high-performance transfers by providing
such features as automation, reliability, efficient use of resources, application integration, and ease
of use. Sterling Connect:Direct for UNIX offers choices in communications protocols, hardware
platforms, and operating systems. It provides the flexibility to move information among mainframe
systems, midrange systems, desktop systems, and LAN-based workstations.
Sterling Connect:Direct for UNIX is based on client-server architecture. The Sterling
Connect:Direct for UNIX server components interact with the user interfaces (API, CLI, IBM
Sterling Connect:Direct Browser User Interface, and IBM Sterling Control Center) to enable
you to submit, execute, and monitor Sterling Connect:Direct for UNIX statements and commands.

Server Components
Sterling Connect:Direct for UNIX has the following server components:

Process Manager
The Process Manager (PMGR) is the daemon that initializes the Sterling Connect:Direct for UNIX
server environment. The PMGR provides the following functions:
Initializes Sterling Connect:Direct for UNIX
Accepts connection requests from Sterling Connect:Direct for UNIX client APIs and remote
nodes
Creates Command Manager and Session Manager child Processes to communicate with APIs
and remote nodes
Accepts requests from Command Managers and Session Managers when centralized Sterling
Connect:Direct for UNIX functions are required
Stops Sterling Connect:Direct for UNIX

Note: Any application, including End User Applications (EUA), can run on any computer as long as it can
connect to the PMGR.

IBM Sterling Connect:Direct for UNIX Administration Guide 7

Chapter 1 About Sterling Connect:Direct for UNIX

Command Manager
A Command Manager (CMGR) is created for every API connection that is successfully established.
The number of Command Managers that a PMGR can create is system-dependent and limited by
the number of file descriptors available for each UNIX Process. The number of file descriptors set
up by the UNIX operating system may affect Sterling Connect:Direct for UNIX operation. You
must define enough file descriptors to handle the number of concurrent Sterling Connect:Direct for
UNIX sessions allowed, which can be as many as 999.
The CMGR provides the following functions:
Executes commands sent by the API and sends the results back to the API
Carries out the Sterling Connect:Direct for UNIX authentication procedure, in conjunction
with the API, to determine access to Sterling Connect:Direct for UNIX
Interacts with the PMGR when executing commands

Session Manager
The Session Manager (SMGR) is created and invoked by the PMGR when resources are available
and either a Process is ready to run or a remote node requests a connection with a local node. The
SMGR provides the following functions:
Performs the necessary Sterling Connect:Direct for UNIX work
Acts as a primary node (PNODE) and initiates Process execution
Acts as a secondary node (SNODE) to participate in a Process initiated by the PNODE
When an SMGR is created to execute a Process submitted to a node, it creates the connection to the
remote node. If the SMGR is started by the PMGR to execute local Processes, the SMGR runs each
Process on this session until all Processes are completed.
If an SMGR is created because a remote node initiated a connection, the SMGR completes the
connection. If the SMGR is started by the PMGR to execute remote Processes, the SMGR executes
remote Process steps supplied by the remote SMGR until the remote SMGR completes all of its
Processes.
The SMGR depends on the PMGR for Transmission Control Queue (TCQ) services and other
centralized services. Refer to the Transmission Control Queue on page 14 for an overview of the
TCQ.

Sterling Connect:Direct for UNIX Concepts

This section introduces concepts and definitions to help you understand Sterling Connect:Direct for
UNIX system operations. For common Sterling Connect:Direct concepts, refer to the IBM Sterling
Connect:Direct for UNIX Product Overview.

8 IBM Sterling Connect:Direct for UNIX Administration Guide

 Sterling Connect:Direct for UNIX Concepts

User Authorization
Sterling Connect:Direct for UNIX can authorize local and remote users to perform certain Sterling
Connect:Direct for UNIX tasks. In order to use Sterling Connect:Direct for UNIX, each user must
have a record defined in the user authorization file, called userfile.cfg. Each local user must have a
record in the user authorization file, and remote users may be mapped to a local user ID in a proxy
relationship.
To provide a method of preventing an ordinary user from gaining root access through Sterling
Connect:Direct for UNIX, a second access file called the Strong Access Control (SACL) file is
created when you install Sterling Connect:Direct for UNIX and is named sysacl.cfg. The
root:deny.access parameter, which is specified in the sysacl.cfg file, allows, denies, or limits root
access to Sterling Connect:Direct for UNIX. If the SACL file is deleted or corrupted, access to
Sterling Connect:Direct for UNIX is denied to all users.
For more information about specifying user authorizations in the userfile.cfg and the sysacl.cfg
files, see Maintaining Access Information Files in the Sterling Connect:Direct for UNIX
Administration Guide.

Process Restart
Several facilities are provided for Process recovery after a system malfunction. The purpose of
Process recovery is to resume execution as quickly as possible and to minimize redundant data
transmission after a system failure. The following Sterling Connect:Direct for UNIX facilities are
available to enable Process recovery:
Process step restartAs a Process runs, the steps are recorded in the TCQ. If a Process is
interrupted for any reason, the Process is held in the TCQ. When you release the Process to
continue running, the Process automatically begins at the step where it halted.
Automatic session retryTwo sets of connection retry parameters are defined in the remote
node information record of the network map file: short-term and long-term. If you do not
specify a value for these parameters in the remote node information record, default values are
used from the local.node entry of the network map file. The short-term parameters allow
immediate retry attempts. Long-term parameters are used after all short-term retries are
attempted. Long-term attempts assume that the connection problem cannot be fixed quickly
and retry attempts occur after a longer time period, thus saving the overhead of connection
retry attempts.
Checkpoint restartThis feature is available with the copy statement.
Checkpoint restart can be explicitly configured within a copy step through the ckpt parameter.
(Refer to the IBM Sterling Connect:Direct for UNIX Processes Web site at
http://www.sterlingcommerce.com/documentation/processes/processhome.html) If it is not
configured in the copy step, it can be configured in the Initparms through the ckpt.interval
parameter. (See Maintaining the Initialization Parameters File in the Sterling Connect:Direct
for UNIX Administration Guide for more information on this parameter.)
Run Task restartIf a Process is interrupted when a run task on an SNODE step is executing,
Sterling Connect:Direct for UNIX attempts to synchronize the previous run task step on the
SNODE with the current run task step. Synchronization occurs in one of the following ways:

IBM Sterling Connect:Direct for UNIX Administration Guide 9

Chapter 1 About Sterling Connect:Direct for UNIX

If the SNODE is executing the task when the Process is restarted, it waits for the task to
complete, and then responds to the PNODE with the task completion status. Processing
continues.
If the SNODE task completes before the Process is restarted, it saves the task results.
When the Process is restarted, the SNODE reports the results, and processing continues.
If synchronization fails, Sterling Connect:Direct for UNIX reads the restart parameter in the
run task step or the initialization parameters file to determine whether to perform the run
task step again. The restart parameter on the run task step overrides the setting in the
initialization parameter.
For example, if the SNODE loses the run task step results due to a Sterling Connect:Direct for
UNIX cold restart, Sterling Connect:Direct for UNIX checks the value defined in the restart
parameter to determine whether to perform the run task again.

Note: Run task restart works differently when Sterling Connect:Direct for UNIX runs behind a
connection load balancer. For more information on the considerations you need to know when
running Sterling Connect:Direct for UNIX in a load balancing environment, see the IBM
Sterling Connect:Direct for UNIX Release Notes, IBM Sterling Connect:Direct for UNIX
Administration Guide, and the Sterling Connect:Direct for UNIX Getting Started Guide.

Interruption of Process activity when the SNODE is a Sterling Connect:Direct for UNIX
nodeWhen the SNODE is a Sterling Connect:Direct for UNIX node and the PNODE
interrupts Process activity by issuing a command to suspend Process activity, deleting an
executing Process, or when a link fails or an I/O error occurs during a transfer, the Process is
placed in the Wait queue in WS status.
If Process activity does not continue, you must manually delete the Process from the TCQ.
Refer to the Sterling Connect:Direct for UNIX User Guide for command syntax and parameter
descriptions for the delete process command.

Note: You cannot issue a change process command from the SNODE to continue Process activity;
the Process can only be restarted by the PNODE, which is always in control of the session.

Archive Statistics Files

Sterling Connect:Direct for UNIX provides a utility to archive and purge statistics files. When you
configure Sterling Connect:Direct for UNIX, you identify when to archive a statistics file by setting
the parameter, max.age, in the stats record of the initialization parameters file. The max.age
parameter defines how old a statistics file must be before you want to archive the file.
Once a day, the script called statarch.sh is started. This script identifies the statistics files that are
equal to the max.age. It then runs the tar command and the compress command to create a
compressed archived file of all the statistics records that match the max.age parameter. Once the
statistics files are archived, these files are purged. For files archived on a Linux computer, the
archived statistics files have the .gz suffix since these files are compressed with the gzip format.
Archived files on all other UNIX platforms have the .Z suffix to indicate they are compressed using
the compress format.
The archived files are stored in the directory where the statistics files and TCQ are stored. The shell
script, statarch.sh, is located in the ndm/bin directory. If necessary, modify the script to customize
it for your environment.

10 IBM Sterling Connect:Direct for UNIX Administration Guide

 Sterling Connect:Direct for UNIX Concepts

If you want to restore statistics files that have been archived, run the statrestore.sh script. It uses
the uncompress and tar commands to restore all the statistics files in the archive. You supply two
arguments to the statrestore command. The first argument is the directory path where the statistics
files are located and the second argument identifies the archived file name followed by as many
archived file names as you want to restore. Below is a sample statrestore command:

qa160sol: ./statrestore.sh /export/home/users/cd4000/ndm/bin archive1

After files are restored, the statistics records can be viewed using the select statistics command.

Sample Processes, Shell Scripts, and API Programs

Sterling Connect:Direct for UNIX provides sample Processes and shell scripts in d_dir/ndm/src,
where d_dir indicates the destination directory of the Sterling Connect:Direct for UNIX software.
You can create similar files with a text editor. In addition, instructions for creating sample Processes
and shell scripts are in the README file in the same directory.
The following table displays the file names of sample Processes. Modify the Processes as required:

File Name Type of Process

cpunx.cd copy

rtunx.cd run task

rjunx.cd run job

sbunx.cd submit

The following table displays the file names of sample shell scripts. Modify the shell scripts as
required.

File Name Type of Shell Script

selstat.sh select statistics

send.sh send

recv.sh receive

wildcard send multiple files to a PDS

statarch.sh archive statistics files

statrestore.sh restore statistics files that have been archived

lcu.sh launch the Local Connection Utility tool

spadmin.sh launch the Secure+ Admin Tool

IBM Sterling Connect:Direct for UNIX Administration Guide 11

Chapter 1 About Sterling Connect:Direct for UNIX

File Name Type of Shell Script

spcli.sh launch the Secure+ CLI (SPCLI)

spcust_sample1.sh configure Secure+ for the STS protocol

spcust_sample2.sh configure Secure+ for the STS protocol

spcust_sample3.sh configure Secure+ to use the SSL or TLS protocol

The following table displays the names of sample programs:

Program Name Description

apicheck.c This program submits a Process to copy a file to a remote system.

MAXDELAY is used in this example, which means that the program will
not finish execution until the file has been transferred. A standard c
compiler is used to compile this module.

apicheck.C Same as apicheck.c, except that it is compiled with one of the C++
compilers listed in the Sterling Connect:Direct for UNIX User Guide.

exit_skeleton.c This program is a skeleton of a user exit program that works in

conjunction with Sterling Connect:Direct for UNIX. It demonstrates
usage of all three user exits.

exit_skeleton.C Same as exit_skeleton_c, except that it is compiled with one of the C++
compilers listed in the Sterling Connect:Direct for UNIX User Guide.

exit_sample.c This is the same program as the skeleton user exit program, except that
the security exit is demonstrated with code that approximates
PassTicket functionality.

sdksample.C This program exercises various commands using the SDK interface to
Sterling Connect:Direct for UNIX.

Sterling Connect:Direct for UNIX Files

This section describes the configuration files, illustrates the directory structure of Sterling
Connect:Direct for UNIX, and lists the individual files that are installed.

Sterling Connect:Direct for UNIX Configuration Files

Sterling Connect:Direct for UNIX creates the following configuration files during installation and
customization. These files are required for the Sterling Connect:Direct for UNIX server to operate
correctly.

12 IBM Sterling Connect:Direct for UNIX Administration Guide

 Sterling Connect:Direct for UNIX Files

Configuration File Description

Initialization parameters file Provides information to the server to use at start up. During the
installation, you identify the settings necessary for the initialization
parameters file.

User authorization information Contains the local user information and remote user information record
file types. You customize this file during installation to map remote user IDs
to local user IDs and create remote user information records in the user
authorization information file.

Strong access control file Improves the security of Sterling Connect:Direct for UNIX and allows,
denies, or limits root access control. This file is created when you install
Sterling Connect:Direct for UNIX. If the file is deleted or corrupted,
access to Sterling Connect:Direct for UNIX is denied to all users.

Network map file Describes the local node and other Sterling Connect:Direct for UNIX
nodes in the network. You can define a remote node record for each
node that Sterling Connect:Direct for UNIX communicates with.

Server authentication key file Verifies client API connection requests. Only verified clients are granted
a connection.

Client configuration file Identifies the port and host name used by a client to connect to Sterling
Connect:Direct for UNIX.

Client authentication key file Identifies Sterling Connect:Direct for UNIX servers that a Sterling
Connect:Direct for UNIX client connects to. You can have multiple
entries for multiple servers.

Sterling Connect:Direct for UNIX Directory Structure

The following figure illustrates the Sterling Connect:Direct for UNIX directory structure. The
directory tree starts at d_dir/, the destination directory where the software is installed. This directory
structure provides for multiple nodes on the same network and possibly on the same computer. The
directory structure organization enables you to share Sterling Connect:Direct for UNIX programs,
such as cdpmgr and ndmcmgr. If multiple nodes exist, each node must have its own
d_dir/ndm/cfg/cd_node/ directory structure for configuration files, where cd_node is the Sterling
Connect:Direct for UNIX node name.

IBM Sterling Connect:Direct for UNIX Administration Guide 13

Chapter 1 About Sterling Connect:Direct for UNIX

Note: The secure+ directory is available only when Sterling Connect:Direct for UNIX Secure Plus is
installed.

d_dir/

ndm/ work/ cd_node etc/

stats
traces

src/

lib/
README cfg/
bin/ apicheck.c security/ secure+/ include/ xlate/ man1/ SACL/
example
files
cliapi/ certificates/
ndmapi.a ndmapi.h
libcd2g.so (not HP) user_exit.h ndmmsg.1
libcd2g.sl (HP only) trusted.txt user_exit2.h ndmxlt.1
libcdsna.so (not HP) cdunxsdk.h ndmpmgr.1
libcdsna.sl (HP only) export/ cdpmgr.1
libcdsnpsna.so ndmapi.cfg
libcdsp.so
libcdspsrvr.so import/ sysacl.cfg
libcdspsssl.so cd_node/
log/ default_recv.xlt
default_send.xlt

ndmcmgr locks/
cdpmgr cdcust
ndmpmgr ttlflst1.0
ndmsmgr nodes/ svcflst1.0
ndmcli cliflst1.0
direct cdver
ndmproc keys.client cdsnacfg (AIX LU6.2 only)
ndmproc.awk keys.server snaver.sh (AIX LU6.2 only)
ndmstat tcq_convert
ndmstat.awk template (Brixton SNA only)
ndmmsg diskfree
ndmxlt cliapi diskfree.so
ndmauths initparm.cfg cfg.convert
ndmauthc netmap.cfg spcust_sample1.sh
cdcustrpt userfile.cfg spcust_sample2.sh
cdsacomp msgfile.cfg spcust_sample3.sh
cdstatm msgfile.idx
cfgcheck
ndmumgr
cdmsgutil
initcnvt
statarch.sh
statrestore.sh
sample.cd
ndmview
ndmview.awk
initcnvt
Install.bin
lcu.jar
lcu.sh
ohj-jewt.jar (Secure+ only)
runjar.jar (Secure+ only)
SecureOHelp.jar (Secure+ only)
SPAdmin.jar (Secure+ only)
spadmin.sh (Secure+ only)
SPCli.jar (Secure+ only)
CPCliMessages.properties (Secure+
only)
spcli.sh (Secure+ only)
Cipher.txt (Secure+ only)
help4.jar (Secure+ only)

14 IBM Sterling Connect:Direct for UNIX Administration Guide

 Sterling Connect:Direct for UNIX Documentation

Note: See the following figure to view the work directory for a node.

A d_dir/work/cd_node directory is created for each node. The following figure displays the work
directory for multiple nodes and illustrates the working files created for each node, such as TCQ
files:

d_dir/

ndm/ work/

cd_node_1 cd_node_2 cd_node_3 cd_node_n

TCQ, statistics file, TCQ, statistics file,

transient files transient files

TCQ, statistics file, TCQ, statistics file,

transient files transient files

Sterling Connect:Direct for UNIX Documentation

About This Guide

The IBM Sterling Connect:Direct for UNIX Administration Guide is for programmers and network
operations staff who install Sterling Connect:Direct for UNIX. By reading this document, you gain
the knowledge required to install Sterling Connect:Direct for UNIX.
This guide assumes knowledge of the UNIX operating system, including its applications, network,
and environment. For LU6.2 connectivity, a proficiency in configuring the SNA package to support
independent LU6.2 connections is required.

Task Overview
The following table guides you to the information required to perform Sterling Connect:Direct for
UNIX installation tasks:

Task Reference

Understanding Sterling Connect:Direct for UNIX Chapter 1, About Sterling Connect:Direct for
UNIX

IBM Sterling Connect:Direct for UNIX Administration Guide 15

Chapter 1 About Sterling Connect:Direct for UNIX

Task Reference

Installing Sterling Connect:Direct for UNIX Chapter 2, Installing Sterling Connect:Direct

for UNIX

Customizing Sterling Connect:Direct for UNIX Chapter 2, Installing Sterling Connect:Direct

for UNIX

Setting up the Sterling Connect:Direct for UNIX server Chapter 2, Installing Sterling Connect:Direct
for UNIX

Setting up the Sterling Connect:Direct for UNIX client Chapter 2, Installing Sterling Connect:Direct
for UNIX

Creating the Strong Access Control file and changing file Chapter 2, Installing Sterling Connect:Direct
permissions on session manager, process manager, for UNIX
command manager, and user manager programs.

Installing Sterling Connect:Direct for UNIX File Agent Chapter 2, Installing Sterling Connect:Direct
for UNIX

Installing Sterling Connect:Direct for UNIX Secure Plus Chapter 2, Installing Sterling Connect:Direct
for UNIX

Managing files with Sterling Connect:Direct for UNIX File Chapter 3, Managing Files with Sterling
Agent Connect:Direct File Agent

Recording the information necessary to install and Appendix A, Installation Worksheets

customize Sterling Connect:Direct for UNIX

Configuring an LU6.2 connection Appendix B, SNA LU6.2 Connectivity

Accessing and displaying manual pages Appendix C, Sterling Connect:Direct Manual

Pages

16 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 2

Maintaining Configuration Files

Configuration files define the operating environment for Sterling Connect:Direct. The following
configuration files are created during the customization procedure:
Initialization parameters file
Client configuration parameters file
Network map file
Two access files: userfile.cfg and sysacl.cfg
After the initial customization, you can modify these files, if necessary. This chapter provides you
with the information to modify the configuration files.

About the Configuration Files

A configuration file is a text file composed of records. A record is a single logical line. A logical
line is one or more physical lines that can be continued with the backslash (\) character. In the table
on page 18, physical lines 4 and 5 illustrate a logical line. Line 4 ends with a backslash (\) character,
to indicate that the line is continued on the next physical line. Line 1 of the sample begins with a
pound (#) sign. The pound sign indicates this line contains a comment.
A record consists of a record name and one or more parameter pairs. A parameter pair is a parameter
name and parameter value. Line 2 contains the record name, ndm.path. Line 2 also contains the
parameter pair, path and /ndm/users/c, where the parameter name is path and the parameter value
is /ndm/users/c. The parameter pair is bound by colons (:) and separated by an equal sign (=) in the
following format. The following example displays a complete record, where ndm.path is the record
name, path is the parameter name, and /ndm/users/c is the parameter value:

ndm.path:path=/ndm/users/c:

Record names and parameter names are not case sensitive. Parameter values are case sensitive.
Lines 7 through 23 illustrate a longer logical record. Line 7 contains the record name local.node
followed by an optional colon (:) and a backslash (\) character. All lines between 7 and 23 end with

IBM Sterling Connect:Direct for UNIX Administration Guide 17

Chapter 2 Maintaining Configuration Files

a backslash (\) character. Line 23 does not contain a backslash (\) character, to indicate the end of
the record.
The following table displays a portion of the initialization parameters file to illustrate the format of
Sterling Connect:Direct configuration files:

Line Contents Notes

1 #Miscellaneous Parameters # indicates a comment

2 ndm.path:path=/ndm/users/c: record name=ndm.path,

parameter=path
value= /ndm/users/c

3 proc.prio:default=8: record name=proc.prio,

parameter=default
value= 8

6 #Local Sterling Connect:Direct connection information # indicates a comment

7 local.node:\ record name=local.node

13 .

. . . .

21 .

22 :tcp.api=rusty;3191:\ parameter= tcp.api, value=

rusty;3191

23 :tcp.api.bufsize=32768: parameter= tcp.api.bufsize

value= 32768

Configuration files allow duplicate but not identical records, in some cases. For example, you can
define more than one remote node information (rnode.listen) record in the initialization parameters
file.

Modifying Configuration Files

You can modify Sterling Connect:Direct configuration files using any text editor or create a new
configuration file using the cdcust command provided with Sterling Connect:Direct for UNIX.
Modifying Configuration Files with a Text EditorYou can modify Sterling Connect:Direct
configuration files with any text editor, such as vi editor.
Creating Configuration Files with cdcustType the following command to start the
customization procedure, where d_dir is the Sterling Connect:Direct for UNIX path name:

$ d_dir/etc/cdcust

18 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 3

Maintaining the Initialization Parameters File

Initialization parameters determine various Sterling Connect:Direct settings that control system
operation. The initialization parameters file is created when you install Sterling Connect:Direct for
UNIX and can be updated as needed.
You can modify Sterling Connect:Direct initialization parameters file using any text editor. Before
changing a value in the file, first shut down the Sterling Connect:Direct server. After you change a
value and save the file, restart the server. Restarting the server validates the new values and
generates an error message if a value is invalid. All available parameters are described in this
chapter.
If you use Sterling Connect:Direct Browser User Interface to update parameters in the Local Node
Connection Record, you do not have to stop and restart the server.

Note: You can also use the Sterling Connect:Direct Browser User Interface to perform some of the
procedures in this chapter. To learn more about the Sterling Connect:Direct Browser User Interface,
see the documentation on the Sterling Connect:Direct Browser User Interface CD-ROM or available
online from the IBM Documentation Library.

About the Initialization Parameters File

The initialization parameters file resides in d_dir/ndm/cfg/cd_node/initparm.cfg, where d_dir is the
destination directory where Sterling Connect:Direct for UNIX is installed and cd_node is the node
name.
The initialization parameters file contains records. Each record includes parameters to define the
attributes of the record. The records are summarized as follows:
Miscellaneous parametersProvide miscellaneous information including the name of the
Sterling Connect:Direct for UNIX node; the location of Sterling Connect:Direct for UNIX, the
Pluggable Authentication Modules (PAM) service configuration file, and the shared work area
for SNODE work files; the default Process priority; and whether commands with special
characters are restricted in the run directory.
Remote node connection informationThe rnode.listen record includes parameters to monitor
inbound connections.

IBM Sterling Connect:Direct for UNIX Administration Guide 19

Chapter 3 Maintaining the Initialization Parameters File

Transmission Control Queue (TCQ) informationThe tcq record defines how long a Process
is held in error before being deleted.
Global copy parametersThe copy.parms record defines default parameters used by the
Copy operation including checkpoint parameters, file size limitations, translation table
information, exception handling, CRC checking, file allocation retry parameters, and
compression options.
Global run task parametersThe runtask.parms record defines a parameter to define the
restart option.
Statistics file informationThe stats record includes parameters to define default statistics
file information including file size limitations, the type of information to write to the statistics
file, and how long to maintain statistics files before archiving them.
Server authentication informationThe authentication record parameters to authenticate the
server.
User exit parametersThe user.exits record defines the programs used during a user exit
procedure.
Firewall navigation informationThe firewall.parms record defines the ports or range of
ports to use for outbound sessions when a server operates behind a firewall.
The following sample initialization parameters file shows how some of these parameters are
specified:

# Miscellaneous Parameters
ndm.path:path=/sci/users/mscarbro/cd4000:\
:snode.work.path=/sci/users/mscarbro/cd4000/shared:

ndm.node:name=mws_joshua_4000:
ndm.pam:service=cdlogin:
ndm.quiesce:quiesce.resume=n

proc.prio:default=10:

restrict:cmd=y

# TCQ information
tcq:\
:max.age=8:

# Global copy parameters.

copy.parms:\
:ckpt.interval=2M:\
:ulimit=N:\
:xlate.dir=/sci/users/mscarbro/cd4000/ndm/xlate:\
:xlate.send=def_send.xlt:\
:xlate.recv=def_recv.xlt:\
:continue.on.exception=y:

20 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating Miscellaneous Parameters

# Global runtask parameters.

runtask.parms:\
:restart=y:

# Stat file info.

stats:\
:file.size=1048576:\
:log.commands=n:\
:log.select=n:\
:syslog.logd=daemon:

# Authenticator
authentication:\
:server.program=/sci/users/mscarbro/cd4000/ndm/bin/ndmauths:\
:server.keyfile=/sci/users/mscarbro/cd4000/ndm/security/keys.server:

# user exit information

user.exits:\
:security.exit.program=:\
:file.open.exit.program=:\
:stats.exit.program=:

# Remote CDU nodes

rnode.listen:\
:recid=rt.sles96440:\
:comm.info=0.0.0.0;9974:\
:comm.transport=udt33:

# Secure+ parameters
secure+:\
:certificate.directory=/home/nis02/jlyon/certs: \
:s+cmd.enforce.secure.connection=n:

Updating Miscellaneous Parameters

This section identifies the miscellaneous records and defines available parameters. Required
parameters are displayed in bold.

Updating the Path Record

The ndm.path record identifies the path to Sterling Connect:Direct files. The following table
describes the parameter available for this record:

Parameter Description Value

path The path to all Sterling Connect:Direct subdirectories and path specification
files.

IBM Sterling Connect:Direct for UNIX Administration Guide 21

Chapter 3 Maintaining the Initialization Parameters File

Updating the SNODE Work Path

The snode.work.path parameter is part of the ndm.path record and identifies the path to the shared
work area for SNODE work files on a cluster file system (not an NFS). This optional parameter
provides a means to share SNODE work files among nodes in a load balancing environment.
SNODE return code files (steprc files) and copy checkpoint information are created in this area
when the snode.work.path parameter is specified. The following table describes the
snode.work.path parameter:

Parameter Description Value

snode.work.path The path to the shared work area for SNODE work files. path specification
Note: Specify the same path for all nodes in a cluster.

Updating the Node Name Record

The ndm.node record identifies the name of the Sterling Connect:Direct node. The following table
describes the parameter available for this record:

Parameter Description Value

name The name of the The maximum length is 16 bytes. If a node name is longer, the
node. name will be truncated.

Updating the PAM Service Record

The ndm.pam record identifies the PAM service configuration file used to authenticate the user
authority for Sterling Connect:Direct Processes. If the service initialization parameter is defined
and if PAM is installed on the Sterling Connect:Direct server, PAM is used to authenticate users for
service-providing applications. The following table describes the parameter available for this
record:

Parameter Description Value

service PAM service configuration file name. File name

22 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating Miscellaneous Parameters

Updating the Quiesce/Resume Record

The ndm.quiesce record specifies whether Sterling Connect:Direct is operating in a test mode.
Use this record in conjunction with the NDMPXTBL table to enable the test mode. If you enable
the quiesce.resume parameter, you must have an NDMPXTBL parameter table updated for your
environment in the installation ndm/cfg/<nodename> directory. For more information on the test
mode and the NDMPXTBL table, see Appendix C, Using Sterling Connect:Direct in a Test Mode.
The following table describes the parameter available for this record:

Parameter Description Value

quiesce.resume Enables/disables the test mode for Sterling y|n

Connect:Direct. yEnables the test mode.
nDisables the test mode. The
default is n.

Updating the Priority Record

The proc.prio record identifies the default value of the Process priority. The following table
describes the parameter available for this record:

Parameter Description Value

default The default value of the Process priority. 115. The default value is 10.
15 is the highest priority.

Restricting the Use of Special Characters in the Run Directory

If a run directory restriction is defined in the user configuration file (userfile.cfg), the restrict record
determines if commands containing certain special characters are allowed. For more information on
the userfile.cfg file, see Updating the Local User Information Record Format on page 55 and
Updating the Remote User Information Record on page 59. The following parameter is available
for this record:

Parameter Description Values

cmd Determines if commands with certain y|n

special characters are allowed. yRestricts the ability to use commands
with any of the following special characters:
;&|
nDoes not restrict allowed commands.

IBM Sterling Connect:Direct for UNIX Administration Guide 23

Chapter 3 Maintaining the Initialization Parameters File

Updating the Remote Node Connection Record

The rnode.listen record contains parameters used by the local node to monitor inbound connection
requests. You can modify the IP address and port number in the rnode.listen record while the server
is running. However, you must recycle the server before the change is active. The following table
describes the remote node connection parameters:

Parameter Description Values

recid A unique identifier of an rnode.listen record. A text string

comm.info The information needed to monitor connection For TCP/IP connections,

requests from remote nodes using TCP/IP or LU6.2. specify the host name or the
This parameter is required. IP address and port number:
For TCP/IP connections, specify the host name or 10.23.107.5;1364
the IP address and port number. If specifying an Separate multiple IP/host
IP address and port, separate parameters with a addresses with a comma (,):
semicolon (;). Separate multiple addresses/host fe00:0:0:2014::7;1364,
names with a comma, for example: msdallas-dt;1364
10.23.107.5;1364, fe00:0:0:2014::7;1364,
A space can be added after
msdallas-dt;1364
the comma for readability.
For more information on specifying IP addresses
Set the IP address to monitor
and host names, see Appendix B, Specifying IP
a specific adapter or to
Addresses, Host Names, and Ports.
0.0.0.0, to monitor all
For LU6.2 connections, identify the profile name to adapters.
identify the name of an SNA configuration profile The default port is 1364.
for the remote connection. Sterling Connect:Direct
For LU6.2 connections,
generates the default name, hostl1, during the
specify a profile name, up to
customization procedure. For AIX SNA, hostl1
8 characters.
refers to the side information profile name. For HP
SNA, SunLink SNA, and Brixton SNA, hostl1
refers to the SNA profile file located in the same
directory as the configuration files.

comm.transport The transport protocol for the remote node. tcp | lu62 | blklu62 | udt33
tcpFor TCP/IP connections
lu62For AIX SNA LU6.2
connections
blklu62For other LU6.2
connections
udt33For UDT connections

24 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the TCQ Record

Updating the TCQ Record

The tcq record provides information pertaining to the Transmission Control Queue. The following
parameter is available for this record:

Parameter Description Value

max.age The maximum number of days a A 3-digit decimal number. Sterling

Process with Held-in-Error status Connect:Direct does not automatically
remains in the TCQ before it is delete Processes when max.age=0.
automatically deleted. The default is 8 days.

Adding and Updating the Sterling Connect:Direct Secure Plus

Record (Secure+ Record)
The Sterling Connect:Direct Secure Plus Record (Secure+ Record) record provides information
pertaining to remote configuration of Sterling Connect:Direct Secure Plus from the Sterling
Connect:Direct client API. This record is not included in the initparm.cfg file by default. You must
manually add the secure+ record to the initparm.cfg file. The following parameters are available for
this record:

Parameter Description Value

certificate.directory Specifies a default certificate Directory path name

directory for Secure+ commands
issued from the Sterling
Connect:Direct client API. If the
certificate directory is not configured,
the default directory created during
installation is used.

s+cmd.enforce.secure.connection Specifies whether Secure+ y|n

commands are accepted from the yCommands from unsecure
Sterling Connect:Direct client API on connections are not accepted.
unsecure connections. The default is y.
nCommands from unsecure
connections are accepted

IBM Sterling Connect:Direct for UNIX Administration Guide 25

Chapter 3 Maintaining the Initialization Parameters File

Updating the Global Copy Record

The Global Copy record called copy.parms provides default information for the Sterling
Connect:Direct copy operation. The ecz parameters are only used when extended compression is
defined in a Process. The following parameters are available for this record:

Record Description Value

ckpt.interval The default number of bytes transmitted in a The maximum possible value
copy operation before a checkpoint is taken. is 1 terabyte (TB). The normal
Following is a list of the maximum number of value is 64KB.
digits for each byte interval:
noNo checkpointing
nnnnnnnnUp to an 8-digit decimal
nnnnnnnnKUp to an 8-digit decimal, where K
denotes 1024 bytes
nnnnnnnnMUp to an 7-digit decimal, where M
denotes 1048576 bytes
nnnnGUp to an 4-digit decimal, where G
denotes 1073741824 bytes

ulimit The action taken when the limit on a user output nIgnores the limit. n is the
file size is exceeded during a copy operation. default value.
yRecognizes the user file
size limit. If this limit is
exceeded during a copy
operation, the operation fails.

xlate.dir The name of the directory containing the Any valid directory.
translation tables. The default path is
d_dir/ndm/xlate.

xlate.send The default translation table used when sending Any valid directory.
data to a remote node. The default file name is
def_send.xlt.

xlate.recv The name of the default translation table used The default file name is
when copying data from a remote node. def_recv.xlt in the directory
defined in the xlate.dir
parameter.

continue.on.exception The method to use to handle an exception yContinues Processing with

condition in a Process. If a step fails due to a the next step.
STOP IMMEDIATE or FLUSH exception issued nPlaces a Process in the
on the remote node, the Process is placed in the Hold queue with a value of HE.
Hold HE queue, regardless of the value of this
The default is n.
parameter.

26 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Global Copy Record

Record Description Value

ecz.compression.level Sets the compression level. 19. The default is 1.

1The fastest but offers the
least degree of compression.
9Provides the greatest
degree of compression but is
the slowest.

ecz.memory.level How much virtual memory to allocate to 19. The default is 4.

maintaining the internal compression state. 1Uses the least memory and
9 uses the most memory.

ecz.windowsize The size of the compression window and history Valid values are 915. The
buffer. The larger the window, the greater the default is 13.
compression. However, increasing the window
uses more virtual memory.

retry.codes The codes to recognize as a file allocation retry Any valid error code
attempt. File allocation retry enables a Process
with a file allocation or open error on either the
local or remote node to run the Process again,
beginning at the copy step where the error
occurred. This feature supports the ability to
retry a Process that failed when a file is already
in use.
When a file allocation or open error occurs on
either the local or remote node, the PNODE
searches for the error or message ID in the
retry.codes and retry.msgids parameters. If the
error code or message ID is found, the Process
is retried.
Since error codes can vary from one operating
system to another and the same error code can
have different meanings, use message IDs to
identify retry conditions when communicating
between two different platforms.
You can perform retry attempts based on codes
only, IDs only, or a combination of the two.
When a retry condition is detected, the session
is terminated cleanly and the Process is placed
in the Timer queue.

IBM Sterling Connect:Direct for UNIX Administration Guide 27

Chapter 3 Maintaining the Initialization Parameters File

Record Description Value

retry.msgids Identifies the message IDs to use to support a Any of the valid file allocation
file allocation retry attempt. retry messages.
Since error codes can vary from one operating
system to another and the same error code can
have different meanings, use message IDs to
identify retry conditions when communicating
between two different platforms.
When a file allocation or open error occurs on
either the local or remote node, the PNODE
searches for the message ID in the retry.msgids
parameters. If the message ID is found, the
Process is retried.
You can perform retry attempts based on codes
only, message IDs only, or a combination of the
two.
When a retry condition is detected, the session
is terminated cleanly and the Process is placed
in the Timer queue.

tcp.crc Globally turn on or off the CRC function for y|n

TCP/IP Processes. yTurns on the CRC function
globally.
nTurns off the CRC function
globally. The default is n.

tcp.crc.override Determines whether netmap remote node and y|n

Process statement overrides for CRC checking yAllows netmap remote
are allowed. If this value is set to n, setting node and Process statement
overrides for CRC checking will be ignored. overrides for CRC checking.
nPrevents netmap remote
node and Process statement
overrides for CRC checking.
The default is n.

strip.blanks Determines whether trailing blank characters are y|n|i

stripped from the end of a record. If strip.blanks yStrips blanks from the end
is not defined in the initialization parameter, the of a record
default value of i is used.
nDoes not strip blanks from
the end of a record
iSetting for strip.blanks is
determined by the default
value of the remote node type
as follows:
z/OS, VM, VSE, and
i5OSy
All other platformsn

28 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Global Run Task Record

Record Description Value

insert.newline Arbitrarily appends an LF character at the end of y|n

each record when receiving a datatype=text file. yArbitrarily appends an LF
By default, an LF character is not appended if character
one already exists at the end of a record.
nAppends an LF character if
needed

Updating the Global Run Task Record

The Global Run Task record called runtask.parms is used if the PNODE and SNODE cannot
resynchronize during a restart. If a Process is interrupted when a run task on an SNODE step is
executing, Sterling Connect:Direct attempts to synchronize the previous run task step on the
SNODE with the current run task step. If synchronization fails, Sterling Connect:Direct reads the
restart parameter to determine whether to perform the run task step again. The following
parameter is available for this record:

Parameter Description Value

restart If processing is interrupted when a run task on y|n

an SNODE step is executing and if yThe run task program runs
synchronization fails after a restart, Sterling again. The default is y.
Connect:Direct reads the restart parameter to
nThe Process skips the run task
determine whether to perform the run task
step.
step again. Set this parameter in the
initialization parameters file of the SNODE.
Note: When a load balancing cluster is
used and the snode.work.path is
specified, the restart parameter
takes effect only when
resynchronization fails.

IBM Sterling Connect:Direct for UNIX Administration Guide 29

Chapter 3 Maintaining the Initialization Parameters File

Updating the Statistics File Information Record

The statistics file information record called stats define the statistics facility. The following
parameters are available for this record:

Parameter Description Value

file.size The maximum size in bytes of an individual statistics nnnnnnnn, nnnnnnnnK,

data file. The statistics file name is written in the nnnnnnnM, or
format of Syyyymmdd.ext, where yyyy indicates nnnnGEstablishes a
year, mm indicates month, and dd indicates day. default output file size limit
The extension (ext) begins as 001. When a statistics for the statistics files. K
file reaches the defined size within a 24-hour period, denotes 1024 bytes. M
a new file is created with the same file name. The denotes 1048576 bytes. G
extension value is incremented by one. denotes 1073741824 bytes.
The maximum value you
can specify is 1 TB.

log.commands Determines whether commands are written to the y|n

statistics file. If you want to log all commands except yCommands are written
the select statistics and select process commands, to the statistics file.
set this parameter to y and the log.select parameter
nCommands are not
to n.
written to the statistics file.
The default is n.

log.select Specifies whether Sterling Connect:Direct creates a y|n

statistics record when a select process or select yA statistics record is
statistics command is executed. created.
nA statistics record is not
created. The default is n.

syslog.logd Enables Sterling Connect:Direct to send failure Available values are:

messages to the UNIX syslogd daemon. Refer to kernKernel
manual pages for instructions on configuring syslog.
userUser level
mailMail subsystems
daemonSystem daemons
authSecurity or
authorization
syslogsyslogd daemon
lprLine-printer subsystem
newsNews subsystem
uucpuucp subsystem
The default value is
daemon.

30 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Server Authentication Record

Parameter Description Value

max.age Specifies how old a statistics file must be before it is A 3-digit decimal number.
archived. Once a day, a shell script is executed that The default is 8 days.
identifies the statistics files that are as old as the 0no archiving.
max.age, runs the tar command and the compress
command to create a compressed archive, and then
deletes the statistics files that have been archived.

Running a Process generates multiple statistics records. To accommodate the large number of
statistics records generated, Sterling Connect:Direct closes the current statistics file and creates a
new statistics file at midnight every day. It can also close the current file before midnight if the file
size exceeds the value set for the file.size initialization parameter. The default file size is 1
megabyte.
Statistics files are stored in the d_dir/work/cd_node directory. Names of the statistics files are in the
format Syyyymmdd.ext, where yyyy indicates year, mm indicates month, and dd indicates day.
The extension (ext) begins as 001. The extension is incremented by one each time a new statistics
file is created in a single day.
Sterling Connect:Direct for UNIX provides a utility to archive and purge statistics files. You
identify when to archive a statistics file by setting the parameter, max.age. The max.age parameter
defines how old a statistics file must be before you want to archive the file. Once a day, the script
called statarch.sh is started. This script identifies the statistics files that are greater than or equal to
the max.age. It then runs the tar command and the compress command to create a compressed
archived file of all the statistics records that match the max.age parameter. Once the statistics files
are archived, these files are purged.
The archived files are stored in the directory where the statistics files and TCQ are stored. The shell
script, statarch.sh, is located in the ndm/bin directory. If necessary, modify the script to customize
it for your environment.
If you want to restore statistics files that have been archived, run the statrestore.sh script. It uses the
tar command to restore all the statistics files in the archive. Once files are restored, the statistics
records can be viewed using the select statistics command.

Updating the Server Authentication Record

The server authentication record called authentication is used during the authentication procedure.
The following parameters are available for this record:

Parameter Description Value

server.program The name and location of the server program used during The default is
the authentication procedure. ndmauths.

server.keyfile The name and location of the key file used during the The default is
authentication procedure. keys.server.

IBM Sterling Connect:Direct for UNIX Administration Guide 31

Chapter 3 Maintaining the Initialization Parameters File

Updating the User Exit Record

The user exit record called user.exits provides interfaces to specified programs. The available user
exits include Statistics Exit, File Open Exit, and Security Exit. The following parameters are
available for this record:

Parameter Description Value

stats.exit.program The gateway control program used during the Name of the gateway control
user exit procedure. This exit is given control program.
for each statistics record that is written.

file.open.exit.program The file open exit program used during the Name of the file open exit
user exit procedure. It enables you to control program.
file names on both the sending and receiving
node. The exit is located so that it takes control
on the receiving (remote) node before the file
is opened.
This exit applies only to the copy statement
and provides access to all file control
parameters (including the data set name file
name, sysopt parameters, and disposition).

security.exit.program The security exit program used during the user Name of the security exit
exit procedure. This exit generates and verifies program.
passtickets, and it also supports other
password support programs, such as
PASSTICKET, part of the RACF security
system available on MVS hosts and also
supported by IBM on UNIX AIX and OS/2
computers using the NETSP product.

security.exit.flag Modifies the default behavior of snode_sec_exit_only |

security.exit.program. This is an optional sec_exit_only
parameter. snode_sec_exit_onlyCauses
Sterling Connect:Direct to use
the security exit, when it is
acting in the role of the
SNODE. After Sterling
Connect:Direct receives a valid
message, it evaluates the proxy
and the secure point-of-entry to
establish the local user. The
security exit is not used when
Sterling Connect:Direct is the
PNODE.
sec_exit_onlyCauses
Sterling Connect:Direct to
always use the security exit.
After Sterling Connect:Direct
receives a valid message, it
evaluates the proxy and the
secure point-of-entry to
establish the local user.

32 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Firewall Navigation Record

Updating the Firewall Navigation Record

The firewall navigation record, called firewall.parms, enables you to assign a specific TCP/IP and
UDT source port number or a range of port numbers with a particular TCP/IP and UDT address for
outbound Sterling Connect:Direct sessions. These ports also need to be open on the firewall of the
trading partner to allow the inbound Sterling Connect:Direct sessions. This feature enables
controlled access to an Sterling Connect:Direct server if it is behind a packet-filtering firewall
without compromising security policies.

Note: Before you configure firewalls for use with UDT, refer to Appendix A, Configuring Firewall
Navigation, for information on the differences between UDT and TCP session establishment and
firewall navigation.

The following parameters are available for this record:

Parameter Description Value

tcp.src.ports For TCP/IP connections, remote IP Valid IP address with an optional mask
addresses and the ports permitted for the upper boundary of the IP address
for the addresses when using a range and the associated outgoing port
packet-filtering firewall. This number or range of port numbers for the
parameter is required only if the specified IP address, for example:
local node acts as a PNODE. (199.2.4.*, 1000), (fd00:0:0:2015:*::*,
Place all values for an address 2000-3000), (199.2.4.0/255.255.255.0,
inside parentheses and separate 4000-5000),(fd00:0:0:2015::0/48, 6000,
each value for an address with a 7000)
comma. A wildcard character (*) is supported to
define an IP address pattern. If the
wildcard character is used, the optional
mask is not valid.
For more information on IP addresses,
masks, and ports, see Appendix
B, Specifying IP Addresses, Host
Names, and Ports.

tcp.src.ports.list.iterations The number of times that Sterling Any numeric value from 1255. The
Connect:Direct scans the list of default value is 2.
available ports to attempt a .
connection before going into a retry
state.

IBM Sterling Connect:Direct for UNIX Administration Guide 33

Chapter 3 Maintaining the Initialization Parameters File

Parameter Description Value

udp.src.ports For UDT connections, remote IP Valid IP address with an optional mask
addresses and the ports permitted for the upper boundary of the IP address
for the addresses when using a range and the associated outgoing port
packet-filtering firewall. This number or range of port numbers for the
parameter is recommended if a specified IP address, for example:
firewall is used whether the local (199.2.4.*, 1000), (fd00:0:0:2015:*::*,
node acts as a PNODE or an 2000-3000), (199.2.4.0/255.255.255.0,
SNODE. 4000-5000),(fd00:0:0:2015::0/48, 6000,
Place all values for an address 7000)
inside parentheses and separate A wildcard character (*) is supported to
each value for an address with a define an IP address pattern. If the
comma. wildcard character is used, the optional
mask is not valid.
For more information on IP addresses,
masks, and ports, see Appendix
B, Specifying IP Addresses, Host
Names, and Ports.

udp.src.ports.list.iterations The number of times that Sterling Any numeric value from 1255. The
Connect:Direct scans the list of default value is 2.
available ports to attempt a .
connection before going into a retry
state.

34 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 4

Maintaining the Client Configuration File

The client configuration file consists of parameter records that interface with End User Applications
(EUA). The client file includes the following parameters:
Sterling Connect:Direct API configuration parameters
Sterling Connect:Direct CLI configuration parameters
Client authentication parameters
You can modify Sterling Connect:Direct configuration files using any text editor. If you want to
create a new configuration file, use the cdcust command.

About the Client Configuration File

The client configuration file is created during the customization procedure and resides in
d_dir/ndm/cfg/cliapi/ndmapi.cfg, where d_dir is the directory where Sterling Connect:Direct is
installed.
A sample client configuration file is displayed in the following example:

# Connect:Direct for UNIX Client configuration file

cli.parms:\
:script.dir=/home/qatest/jsmith/cdunix/hp/ndm/bin/:\
:prompt.string=Test CD on Medea:

api.parms:\
:tcp.hostname=alicia:\
:tcp.port=1393:\
:wait.time=50:

# Authenticator
authentication:\
:client.program=/home/qatest/jsmith/cdunix/hp/ndm/bin/ndmauthc:\
:client.keyfile=/home/qatest/jsmith/cdunix/hp/ndm/sc/keys.client:

IBM Sterling Connect:Direct for UNIX Administration Guide 35

Chapter 4 Maintaining the Client Configuration File

Updating the API Configuration Record

The Sterling Connect:Direct API Configuration record, api.parms, is used by the API to
communicate. The parameters for the API configuration record are described in the following table:

Parameter Description Value

tcp.hostname The host name or IP address to Host name or IP address.

which the API usually connects. For more information on specifying IP addresses
and host names, see Appendix B, Specifying IP
Addresses, Host Names, and Ports.

tcp.port The TCP/IP port number to which Port number. The default is 1363.
the API usually connects.

wait.time The number of seconds to wait for Seconds to wait. The default is 50 seconds.
responses from the server. If this
limit is exceeded, the message ID
XCMG000I is displayed.

Updating the CLI Configuration Record

The CLI configuration record, cli.parms, identifies the location of the script files to format the
output of the select statistics and select process commands and allows you to customize the CLI
prompt. If you customize the script to format the output of the select statistics and select process
command, update the script.dir parameter to identify the location of the scripts. If you want to
display a customized prompt at the CLI command line, in place of the default Direct prompt,
identify the prompt to use in the prompt.string parameter. The cli.parms parameters are described
in the following table:

Parameter Description Value

script.dir The directory where customized script files are stored. Specify Directory name.
this parameter if you have created a custom script to format the The default
output of the select statistics and select process commands.
directory is
The file names must be ndmstat and ndmproc.
ndm/bin/.

prompt.string Identifies the CLI prompt to display on the command line when Prompt string up to
the client is started. 32 characters. The
If the prompt string includes spaces or special characters, default is Direct.
enclose it in single or double quotation marks.
You can set the customized prompt in this parameter and at the
command line (using the -P parameter). If the prompt string is
specified in both places, the -P parameter at the command line
takes precedence.
When the default prompt is overridden, the new prompt string is
displayed in the Welcome banner and at the command prompt.

36 IBM Sterling Connect:Direct for UNIX Administration Guide

 About the Client Configuration File

Updating the Client Authentication Record

The client authentication record, authentication, is used during the authentication procedure. The
client authentication parameters are described in the following table:

Parameter Description Value

client.program The client program to use during authentication. Client program name.
The default is ndmauthc.

client.keyfile The key file to use during authentication. Client key file. The default is
keys.client.

IBM Sterling Connect:Direct for UNIX Administration Guide 37

Chapter 4 Maintaining the Client Configuration File

38 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 5

Maintaining the Network Map File

This chapter describes the parameters in the network map file. This file is created when you install
Sterling Connect:Direct. If necessary, use a text editor to add or modify remote node records in the
network map file. You can modify the network map file dynamically while the server is running.

Note: You can also use the Sterling Connect:Direct Browser User Interface to perform some of the
procedures in this chapter. To learn more about the Sterling Connect:Direct Browser User Interface,
see the documentation on the Sterling Connect:Direct Browser User Interface CD-ROM or
available online from the IBM Documentation Library.

About the Network Map File

The network map contains connectivity information that describes the local node and the remote
nodes in the network. One remote node information record is created for each node with which the
local node communicates.
The network map file resides in d_dir/ndm/cfg/cd_node/netmap.cfg where d_dir is the location
where Sterling Connect:Direct is installed and cd_node is the node name.

Note: If you are using TCP/IP, the local node can communicate with a remote node without a remote node
information record. Specify the required connection information in the submit command or the
Process statement.

IBM Sterling Connect:Direct for UNIX Administration Guide 39

Chapter 5 Maintaining the Network Map File

Sample Network Map Entry for Remote Node

The following sample shows network map remote node entries for a TCP/IP connection and a Sun
LU6.2 connection to remote nodes.

# Sample Network Map remote node entry for a TCP/IP connection

remote.customer.node:\
:conn.retry.stwait=00.00.30:\
:conn.retry.stattempts=3:\
:conn.retry.ltwait=00.10.00:\
:conn.retry.ltattempts=6:\
:tcp.max.time.to.wait=180;\
:runstep.max.time.to.wait=0:\
:contact.name=:\
:contact.phone=:\
:descrip=:\
:sess.total=255:\
:sess.pnode.max=255:\
:sess.snode.max=255:\
:sess.default=1:\
:comm.info=10.20.246.49;9974:\
:comm.transport=tcp:\
:comm.bufsize=65536:\
:pacing.send.delay=0:\
:pacing.send.count=0:
# Sample Network Map remote node entry for a Sun LU6.2 connection
# hostl1 is the profile name
MVS.SAM1.NODE:\
:conn.retry.stwait=00.00.30:\
:conn.retry.stattempts=3:\
:conn.retry.ltwait=00.10.00:\
:conn.retry.ltattempts=6:\
:contact.name=:\
:contact.phone=:\
:descrip=:\
:sess.total=255:\
:sess.pnode.max=128:\
:sess.snode.max=127:\
:sess.default=1:\
:comm.info=hostl1:\
:comm.transport=blklu62:\
:comm.bufsize=16000:

Note: To insert comments about fields in the network map, be sure to place a # in the first column. If the
# is not in the first column, the comment is not ignored and the field is read.

Updating the Local Node Connection Record

The local.node record serves two separate purposes. It configures settings for the local node, and it
also provides default configuration values that can be overridden in the remote node entries. Two
sets of connection retry parameters are created: short-term and long-term. Short-term parameters
define retry attempts in the event of a short-term connection failure. Sterling Connect:Direct uses

40 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Local Node Connection Record

long-term parameters after exhausting short-term attempts. Long-term attempts are set for less
frequent retries, because long-term attempts assume that the connection problem cannot be fixed
quickly.
Following are the local.node parameters. The parameters in bold are required.

Parameter Description Value

api.max.connects The maximum number of concurrent API 1256

connections permitted for the local node. The default is 16.
The value of api.max.connects and
sess.total cannot exceed the number of file
descriptors available. This value is system
dependent.
A Command Manager (CMGR) is created
for every API connection that is
successfully established. The number of
Command Managers that a PMGR can
create is system-dependent and limited by
the number of file descriptors available for
each UNIX Process. The number of file
descriptors set up by the UNIX operating
system may affect Sterling Connect:Direct
operation.

comm.bufsize The buffer size for transmitting data to and The value for TCP/IP has no
from a remote node for TCP/IP limit (up to 2,147,483,623).
connections. For LU6.2, the maximum is
32000.
The default is 65536 bytes.

conn.retry.stwait The time to wait between retries The maximum value is limited
immediately after a connection failure to the highest value in the
occurs. The format is hh.mm.ss, where hh clock format, 23.59.59. The
specifies hours, mm specifies minutes, and default is 00.00.30, which is
ss specifies seconds. 30 seconds.

conn.retry.stattempts The number of times to attempt connection 09999

after a connection failure occurs. The default is 6.

conn.retry.ltwait The time to wait between long-term retry 00.00.0023.59.59

attempts after all short-term retry attempts The default is 00.10.00, or 10
are used. The format is hh.mm.ss, where minutes.
hh specifies hours, mm specifies minutes,
and ss specifies seconds.

conn.retry.ltattempts The number of times to attempt a 09999

connection after all short-term retry The default is 6.
attempts are used.

IBM Sterling Connect:Direct for UNIX Administration Guide 41

Chapter 5 Maintaining the Network Map File

Parameter Description Value

conn.retry.exhaust.action Action to take after the specified short and hold | delete
long-term retries have been used. holdPlaces Processes in
the hold queue in Held in
Error status, after all retry
attempts are used. This is the
default value.
deleteCauses the
Processes to be deleted from
the TCQ.

contact.name The name of the Sterling Connect:Direct Name

administrator or operator.

contact.phone The phone number of the Sterling Phone number

Connect:Direct administrator or operator.

descrip Comments to include as part of the record. An unlimited text string

lu62.writex.wait If you are using SNA on an IBM AIX 0:00:0059:59:59

operating system, use this parameter to The value is in hh:mm:ss
identify how long to wait before retrying the format. The default value is 1.
connection.

lu62.writex.retry.attempts If you are using SNA on an IBM AIX 02,147,483,647

operating system, use this parameter to The default value is 0.
identify how many times to attempt a
connection.

netmap.check Enhanced security testing performed on y|n

the SNODE. For TCP/IP connections, the ySpecifies that the security
remote IP address of the incoming socket checks are made to verify that
connection is compared to the comm.info the remote node name is in
record of the netmap.cfg file. These values the netmap.cfg file.
must match for an Sterling Connect:Direct
nSpecifies that none of
session to be established. The comm.info
these security checks are
record can be the official network name, an
made.
alias name listed in the appropriate file (for
example, /etc/hosts, if the system is not The default value is n.
running NIS or DNS), or the IP address.
For all connections, the remote node name
must be in the netmap.cfg.

outgoing.address If running in a high availability environment, nnn.nnn.nnn.nnn (IPv4) or

this parameter enables you to specify the nnnn:nnnn:nnnn:nnnn:nnnn:n
virtual IP address for the remote node to nnn:nnnn:nnnn (IPv6)
use for network map checking and
prevents the Process from failing when
For more information on
initiated from within a high availability
specifying IP addresses, see
environment. Specify the IP address for this
Appendix B, Specifying IP
value and network map checking verifies
Addresses, Host Names, and
the address instead of the value set in
Ports.
comm.info in the SNODE network map
record.

42 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Local Node Connection Record

Parameter Description Value

pacing.send.delay The time to wait between send operations The format is nnn.
to the remote node. The decimal number is No limit exists for the size of
the number of milliseconds between the this value.
end of one packet and the beginning of the
The default is 0, which
next packet. Time-based pacing does not
indicates no pacing of this
contribute to network traffic.
type.
The value for this parameter has no effect
on LU6.2 connections.

pacing.send.count The number of send operations to perform No limit exists for the size of
before automatically waiting for a pacing this value.
response from the remote node. The value The default is 0, which
for this parameter has no effect on LU6.2 indicates no pacing of this
connections. type.

proxy.attempt Enables the ID subparameter of snodeid to y|n

contain a proxy, or dummy user ID to be ySpecifies that the remote
used for translation to a local user ID on the users can specify a dummy
remote system. Using a dummy user ID user ID in snodeid parameter.
improves security because neither the local
nSpecifies that the remote
system nor the remote system requires a
users cannot specify dummy
valid user ID from the other side.
user ID in snodeid parameter.
The default is n.

The following code illustrates the logic used

to perform a security check for the user ID:
if proxy.attempt = yes
if snodeid (ID only or ID &
password) is specified

if ID@PNODE found in userfile.cfg

security checking OK
else
if (ID, PSWD) is valid UNIX ID & password
security OK
else
security checking failed
else /*snodeid is NOT specified */
if submitter@PNODE found in userfile.cfg
security OK
else
security checking failed
else /*i.e. proxy.attempt = no, the default value */
if snodeid (ID & password) is specified
if (ID, PSWD) is valid UNIX ID & password
security OK
else
security checking failed
else /*snodeid is NOT specified */
if submitter@PNODE found in userfile.cfg
security OK
else
security checking failed

IBM Sterling Connect:Direct for UNIX Administration Guide 43

Chapter 5 Maintaining the Network Map File

Parameter Description Value

runstep.max.time.to.wait The maximum time to wait for remote run 010000

steps to complete. Remote run steps The value is in seconds.
include remote run task, run job, or submit
The default value is 0.
statements. This wait time is different from
the wait time specified by the
tcp.max.time.to.wait parameter. Using
runstep.max.time.to.wait prevents a
Process from failing when a remote step
takes longer to complete than specified in
tcp.max.time.to.wait.

sess.total The maximum number of concurrent 0999

connections between all nodes and the A 13 digit number.
local node.
The default is 255.
The sum of api.max.connects and
sess.total cannot exceed the number of file
descriptors available. This value is system
dependent.
You must define enough file descriptors to
handle the number of concurrent Sterling
Connect:Direct sessions allowed, which
can be as many as 999.

sess.pnode.max The maximum concurrent connections, 0999

where the local node is the initiator of the The default is 255.
session. Number of PNODE sessions
cannot exceed the total number of
sessions.
If sess.pnode.max is larger than sess.total,
the value of sess.pnode.max is silently
rounded down to the value of sess.total.

sess.snode.max The maximum concurrent connections, 0999

where the local node is the secondary node The default is 255.
in a session.
Number of SNODE sessions cannot
exceed the total number of sessions. If
sess.snode.max is larger than sess.total,
then it is silently changed to the value of
sess.total.0

sess.default The default session class for starting 150

session managers. A Process executes on The default is 1.
the specified class or any higher session
class.

tcp.api.bufsize The buffer size for transmitting data to and This value has no limit. The
from an Sterling Connect:Direct CLI/API. default is 32768 bytes.

44 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Local Node Connection Record

Parameter Description Value

tcp.api The information needed to monitor host name/IP address;nnnn

connection requests from the CLI or API host nameis the name of
using TCP/IP. The host is the host name or the Sterling Connect:Direct
IP address where Sterling Connect:Direct host computer.
is running. The port identifies the
IP addressis the IP address
communications port for Sterling
of a machine running Sterling
Connect:Direct. Multiple host name/IP
Connect:Direct:
addresses and port combinations can be
specified when they are separated by a nnn.nnn.nnn.nnn (IPv4) or
comma. This parameter is required. nnnn:nnnn:nnnn:nnnn:nnnn:n
nnn:nnnn:nnnn (IPv6)
portidentifies the
communications port for
Sterling Connect:Direct. The
format is nnnn, where nnnn is
a decimal number. A
semi-colon separates the host
name/IP address from the
port:
msdallas-dt;1364
You can specify multiple
address/host name and port
combinations (separated with
a comma):
10.23.107.5;1364,
fe00:0:0:2014::7;1364,
msdallas-dt;1364
For more information on
specifying IP addresses and
host names, see Appendix
B, Specifying IP Addresses,
Host Names, and Ports.

tcp.api.inactivity.timeout This is the maximum time a CMGR waits 086399 (23 hours, 59
before exiting when it has not received a minutes, and 59 seconds)
command from a client program. The value is in seconds. The
default is 0, which indicates
no timeout occurs.

tcp.max.time.to.wait The maximum time the local node waits for 010000
a message from the remote node when The value is in seconds. The
using TCP/IP. When the time expires, the default value is 180.
Process is moved to the Timer queue and
Sterling Connect:Direct attempts to
re-establish a session with the remote
node. When set to 0, wait time is unlimited
unless limited by the operating system.

IBM Sterling Connect:Direct for UNIX Administration Guide 45

Chapter 5 Maintaining the Network Map File

Updating TCP/IP Settings for a Local Node

The tcp.ip.default record defines default information to use when the remote node is specified by
IP address. The tcp.ip.default record parameters are described in the following table:

Parameter Description Value

conn.retry.stwait The time to wait between retries The maximum value is limited to
immediately after a connection failure the highest value in the clock
occurs. The format is hh.mm.ss, where format, 23.59.59.
hh specifies hours, mm specifies The default is 00.00.30, which is
minutes, and ss specifies seconds. 30 seconds.

conn.retry.stattempts The number of times to attempt 09999

connection after a connection failure The default is 6.
occurs.

conn.retry.ltwait The time to wait between long-term retry 023.59.59

attempts after all short-term retry The default is 00.10.00, or 10
attempts are used. The format is minutes.
hh.mm.ss, where hh specifies hours,
mm specifies minutes, and ss specifies
seconds.

conn.retry.ltattempts The number of times to attempt a 09999

connection after all short-term retry The default is 6.
attempts are used.

comm.bufsize The buffer size for transmitting data to The value for TCP/IP has no limit
and from a remote node. (up to 2,147,483,623).
For LU6.2, the maximum is
32000.
The default is 16000 bytes.

conn.retry.exhaust.action Action to take after the specified short hold | delete

and long-term retries have been used. holdPlaces Processes in the
Hold queue in Held in Error status,
after all retry attempts are used.
This is the default value.
deleteCauses the Processes to
be deleted from the TCQ.

tcp.max.time.to.wait The maximum time the local node waits 010,000

for a message from the remote node The value in seconds.
when using TCP/IP. When the timer
The default value is 180.
expires, the Process is moved to the
Timer queue and Sterling When set to 0, wait time is
Connect:Direct attempts to re-establish unlimited unless limited by the
a session with the remote node. operating system.

46 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating TCP/IP Settings for a Local Node

Parameter Description Value

runstep.max.time.to.wait The maximum time to wait for remote 010000

run steps to complete. Remote run The value in seconds. The default
steps include remote run task, run job, value is 0.
or submit statements. This wait time is
different from the wait time specified by
the tcp.max.time.to.wait parameter.
Using runstep.max.time.to.wait prevents
a Process from failing when a remote
step takes longer to complete than
specified in tcp.max.time.to.wait.

contact.name The name of the administrator or Name

operator.

contact.phone The phone number of the Sterling Phone number

Connect:Direct administrator or
operator.

descrip Comments to include as part of the An unlimited string

record.

sess.total The maximum number of concurrent 0999

connections between all nodes and the A 13 digit number. The default is
local node. 255.
The sum of api.max.connects and
sess.total cannot exceed the number of
file descriptors available. This value is
system dependent.

sess.pnode.max The maximum concurrent connections, 0999

where the local node is the initiator of The default is 255.
the session.

sess.snode.max The maximum concurrent connections, 0999

where the local node is the secondary The default is 255.
node in a session.

sess.default The default session class for starting 150

session managers. A Process executes The default is 1.
on the specified class or any higher
session class. The value for this
parameter overrides the equivalent
value in the local.node record.

pacing.send.delay How long to wait between send nnn

operations to the remote node. The The size of this number has no
decimal number is the number of limit. The default is 0, which
milliseconds between the end of one indicates no pacing of this type.
packet and the beginning of the next
packet. Time-based pacing does not
contribute to network traffic.
The value for this parameter has no
effect on LU6.2 connections.

IBM Sterling Connect:Direct for UNIX Administration Guide 47

Chapter 5 Maintaining the Network Map File

Parameter Description Value

pacing.send.count The number of send operations to No limit exists for the size of this
perform before automatically waiting for value.
a pacing response from the remote The default is 0, which indicates
node. no pacing of this type.
The value for this parameter has no
effect on LU6.2 connections.

Updating Remote Node Connection Information

The remote node connection information record includes remote node information. Update these
parameters as necessary to define default values to use for a remote node connection or add a new
set of parameters for each new remote node you define. Following are the remote node connection
parameters
:

Parameter Description Value

alternate.comminfo Provides support for establishing host name/IP address or *

netmap-checked sessions with host nameHost name associated
systems with multiple IP with the IP address, for example:
addresses, such as Sterling
:alternate.comminfo=hops (where
Connect:Direct/Plex z/OS. Use
hops is a machine on the local
this parameter to list all IP
domain)
addresses or host names that
are part of the multiple IP :alternate.comminfo=hops.csg.sterco
address environment. mm.com (fully-qualified host name)
For Sterling Connect:Direct/Plex, IP addressthe IP address of a
this list should include the machine running Sterling
address of each Sterling Connect:Direct in IPv4 or IPv6 format:
Connect:Direct/Server with a nnn.nnn.nnn.nnn (IPv4) or
different IP address from the nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nn
Sterling Connect:Direct/Plex nn:nnnn (IPv6)
Manager.If the IP address of the For example:
initiating node does not match
the IP address specified on the :alternate.comminfo=10.23.107.5
comm.info parameter, the :alternate.comminfo=fe00:0:0:2014::7
alternate.comminfo parameter Specify multiple addresses/host
is checked for other valid IP names by separating them with a
addresses. comma (,). A space can be added
For more information on after the comma for readability. For
specifying IP addresses and example:
host names, see Appendix 10.23.107.5, fe00:0:0:2014::7,
B, Specifying IP Addresses, msdallas-dt
Host Names, and Ports.
*Accepts any IP address. This
turns off IP address validation.
Note: Partial pattern matches are
not supported, such as:
*.mydomain.com,
myplex??.mydomain.com.

48 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating Remote Node Connection Information

Parameter Description Value

alt.comm.outbound Alternate communication Fully-qualified host name/IP

address (communication path) address;nnnn
used for outbound Processes. The host name/IP address and port
This parameter provides the are separated by a semi-colon (;). A
alternate addresses for a remote comma separates the list of alternate
node that has multiple NIC communication paths, and the list is
cards. When the local node is processed from the top down. For
the PNODE, the alternate example:
addresses are tried if an initial
salmon;9400, 10.20.40.65;9500
attempt to the primary address
(specified in the comm.info For more information on specifying IP
parameter) fails. After a addresses and host names, see
connection has been Appendix B, Specifying IP
established, if the connection is Addresses, Host Names, and Ports.
subsequently lost, attempts to
reestablish the connection
through the retry mechanism use
the same address as the initial
connection.
When the local node is the
SNODE, the alternate addresses
are used in the Netmap check.

comm.bufsize The buffer size for transmitting The value for TCP/IP has no limit (up
data to and from a remote node to 2,147,483,623).
on TCP/IP connections. For LU6.2, the maximum is 32000.
The default is 65536 bytes.

IBM Sterling Connect:Direct for UNIX Administration Guide 49

Chapter 5 Maintaining the Network Map File

Parameter Description Value

comm.info The information needed to For TCP/IP connections, specify the

initiate connection requests to host name or the IP address and port
remote nodes using TCP/IP or number.
LU6.2. This information refers to The default port is 1364.
the network card that the local
For LU6.2 connections, specify a
Sterling Connect:Direct node
profile name, up to 8 characters.
uses to initiate outbound
requests. This value is required. For more information on specifying IP
addresses and host names, see
For TCP/IP connections, Appendix B, Specifying IP
specify the host name or the Addresses, Host Names, and Ports.
IP address and port number.
If specifying IP address and
port, separate parameters
with a semicolon (;).
For LU6.2 connections,
identify the profile name to
identify the name of an SNA
configuration profile for the
remote connection. Sterling
Connect:Direct generates
the default name, hostl1,
during the customization
procedure. For AIX SNA,
hostl1 refers to the side
information profile name. For
HP SNA, SunLink SNA, and
Brixton SNA, hostl1 refers to
the SNA profile file located in
the same directory as the
configuration files.

comm.transport The transport protocol for the tcp | lu62 |blklu62 | udt33
remote node. tcpTCP/IP connections
lu62AIX SNA LU6.2 connections
blklu62Other LU6.2 connections
udt33UDT connections

conn.retry.stwait Time to wait between retries The maximum value is limited to the
immediately after a connection highest value in the clock format,
failure occurs. The format is 23.59.59.
hh.mm.ss, where hh specifies The default is 00.00.30, which is 30
hours, mm specifies minutes, seconds.
and ss specifies seconds.

conn.retry.stattempts Number of times to attempt 09999

connection after a connection The default is 6.
failure occurs.

50 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating Remote Node Connection Information

Parameter Description Value

conn.retry.ltwait Time to wait between long-term 023.59.59

retry attempts after all short-term The default is 00.10.00, or 10
retry attempts are used. The minutes.
format is hh.mm.ss, where hh
specifies hours, mm specifies
minutes, and ss specifies
seconds.

conn.retry.ltattempts Number of times to attempt a 09999

connection after all short-term The default is 6.
retry attempts are used.

conn.retry.exhaust.action Action to take after the specified hold | delete

short and long-term retries have holdPlaces Processes in the Hold
been used. queue in Held in Error status, after all
retry attempts are used. This is the
default value.
deleteCauses the Processes to be
deleted from the TCQ.

contact.name The name of the Sterling Name

Connect:Direct administrator or
operator.

contact.phone The phone number of the Phone number

Sterling Connect:Direct
administrator or operator.

descrip Comments to include as part of An unlimited string

the record.

pacing.send.count The number of send operations No limit exists for the size of this
to perform before automatically value.
waiting for a pacing response The default is 0, which indicates no
from the remote node. The value pacing of this type.
for this parameter has no effect
on LU6.2 connections.

pacing.send.delay The time to wait between send nnn

operations to the remote node. The size of this number has no limit.
The decimal number is the The default is 0, which indicates no
number of milliseconds between pacing of this type.
the end of one packet and the
beginning of the next packet.
Time-based pacing does not
contribute to network traffic.
The value for this parameter has
no effect on LU6.2 connections.

IBM Sterling Connect:Direct for UNIX Administration Guide 51

Chapter 5 Maintaining the Network Map File

Parameter Description Value

runstep.max.time.to.wait The maximum time to wait for 010000

remote run steps to complete. The default value is 0.
Remote run steps include
remote run task, run job, or
submit statements. This wait
time is different from the wait
time specified by the
tcp.max.time.to.wait parameter.
Using runstep.max.time.to.wait
prevents a Process from failing
when a remote step takes longer
to complete than specified in
tcp.max.time.to.wait. The value
is in seconds.

sess.total The maximum number of 0999

concurrent connections between A 13 digit number.
all nodes and the local node.
The default is 255.
The sum of api.max.connects
and sess.total cannot exceed the
number of file descriptors
available. This value is system
dependent.

sess.pnode.max The maximum concurrent 0999

connections, where the local The default is 255.
node is the initiator of the
session. Number of PNODE
sessions cannot exceed the total
number of sessions.
If sess.pnode.max is larger than
sess.total, the value of
sess.pnode.max is silently
rounded down to the value of
sess.total.

sess.snode.max The maximum concurrent 0999

connections, where the local The default is 255.
node is the secondary node in a
session.
Number of SNODE sessions
cannot exceed the total number
of sessions. If sess.snode.max is
larger than sess.total, then it is
silently changed to the value of
sess.total.

tcp.crc Turn on or off the CRC function y |n

for TCP/IP Processes on the The default is n.
remote node.

52 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 6

Maintaining Access Information Files

You can control access to Sterling Connect:Direct through the following: the user authorization
information file, strong access control file, program directory, local and remote user information
records, and security exit.

User Authorization Information File

In order for users to have access to Sterling Connect:Direct and use Sterling Connect:Direct
commands and statements, you need to define a record for each user ID in the user authorization
information file, called userfile.cfg. The user ID is the key to the local user information record. It
must be a valid user ID on the local system and must be unique.

Note: To disable access to the software for a local user, delete or comment out the local user information
record.

You can create a generic user ID by specifying an asterisk (*) as the user ID. If a user does not have
a specific local user information record, the user authorizations will default to those specified in this
generic record. If no generic local user information record is defined and no specific local user
information record is defined for the user, the user cannot use Sterling Connect:Direct.
Sterling Connect:Direct may optionally use remote user information records to translate remote
user IDs to valid local user IDs where Sterling Connect:Direct is installed. If an snodeid parameter
is not coded on the incoming Process, Sterling Connect:Direct uses this proxy relationship to
determine the rights of remote users to issue Sterling Connect:Direct commands and statements.
Sterling Connect:Direct for UNIX uses the asterisk (*) character to establish generic mappings that
facilitate mapping remote user IDs to local user IDs. The asterisk matches the node name or the host
name. For example, you can specify *@node name to map the remote user ID to all user IDs at one
node name, specify id@* to map to a specific user ID at all node names, or specify *@* to match
all users at all node names.

IBM Sterling Connect:Direct for UNIX Administration Guide 53

Chapter 6 Maintaining Access Information Files

The following table displays sample remote user ID mappings to local user IDs using the special
characters:

Remote User ID at Remote Node is Local User ID Result of Mapping

Name mapped
to

user @ * = test02 Remote user ID user on all

remote nodes is mapped to
local user ID test02.

* @ mvs.node3 = labs3 All remote user IDs on

remote node mvs.node3 are
mapped to local user ID
labs3.

* @ * = vip01 All remote user IDs on all

remote nodes are mapped
to local user ID vip01.

You can generate all the records through the script-based customization procedure or generate only
one or two records and use a text editor to generate additional records. After customization, you
may want to modify some of the parameters. Use cdcust to create a new user file or a text editor to
modify the file as necessary.

Sample User Authorization File

The following sample displays a user authorization file. In the sample, SAM1 is the remote user ID,
MVS.SAM1.NODE is the remote node name, and sam is the local UNIX user ID.

[email protected]:\
:local.id=sam:\
:pstmt.upload=y:\
:pstmt.upload_dir=/home/qatest/username/ndm/uploaddir:\
:pstmt.download=y:\
:pstmt.download_dir=/home/qatest/username/ndm/downloaddir:\
:pstmt.run_dir=/home/qatest/username/ndm/rundir:\
:pstmt.submit_dir=/home/qatest/username/ndm/submitdir:\
:descrip=:
sam:\
:admin.auth=y:\
:pstmt.copy.ulimit=y:\
:pstmt.upload=y:\
:pstmt.upload_dir=/home/qatest/username/ndm/uploaddir:\
:pstmt.download=y:\
:pstmt.download_dir=/home/qatest/username/ndm/downloaddir:\
:pstmt.run_dir=/home/qatest/username/ndm/rundir:\
:pstmt.submit_dir=/home/qatest/username/ndm/submitdir:\
:name=:\
:phone=:\
:descrip=:
:cmd.s+conf=n:

54 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Local User Information Record Format

Updating the Local User Information Record Format

The local user record, userid, defines the default values for each user ID. Most of the parameters in
the local user information record can take the following values:
yIndicates that a user can perform the function. In the case of process and select statistics
commands, the user can affect Processes and view statistics owned by this user ID
nIndicates that a user cannot perform the function.
aIndicates that a user can issue commands for Processes owned by all users and generate
statistics records for all users.
The following table defines the local user information parameters. The default values are
underlined.

Parameter Description Value

admin.auth Determines if the user has administrative y|n

authority. If set to y, the user can perform all of yUser has administrative
the commands by default, but the specific authority.
command parameters override the default. If
nUser does not have
set to n, the specific command parameters
administrative authority.
must be granted individually.
The default is n.

cmd.chgproc Determines if the user can issue the change y|n|a

process command. yAllows the user to issue the
A y value enables a user to issue the command.
command to targets owned by that user. nPrevents the user from issuing
Whereas, a allows a user to issue the the command. The default is n.
command to targets owned by all users.
aAllows the user to issue the
command against targets owned by
all users.

cmd.delproc Determines if the user can issue the delete y|n|a

process command. yAllows the user to issue the
A y value enables a user to issue the command.
command to targets owned by that user. nPrevents the user from issuing
Whereas, a allows a user to issue the the command. The default is n.
command to targets owned by all users.
aAllows the user to issue the
command against targets owned by
all users.

IBM Sterling Connect:Direct for UNIX Administration Guide 55

Chapter 6 Maintaining Access Information Files

Parameter Description Value

cmd.flsproc Determines if the user can issue the flush y|n|a

process command. yAllows the user to issue the
A y value enables a user to issue the command.
command to targets owned by that user. nPrevents the user from issuing
Whereas, a allows a user to issue the the command. The default is n.
command to targets owned by all users.
aAllows the user to issue the
command against targets owned by
all users.

cmd.selproc Determines if the user can issue the select y|n|a

process command. yAllows the user to issue the
A y value enables a user to issue the command.
command to targets owned by that user. nPrevents the user from issuing
Whereas, a allows a user to issue the the command. The default is n.
command to targets owned by all users.
aAllows the user to issue the
command against targets owned by
all users.

cmd.viewproc Determines if the user can issue the view y|n|a

process command. yAllows the user to issue the
A y value enables a user to issue the command.
command to targets owned by that user. nPrevents the user from issuing
Whereas, a allows a user to issue the the command. The default is n.
command to targets owned by all users.
aAllows the user to issue the
command against targets owned by
all users.

cmd.selstats Determines if the user can issue the select y|n|a

statistics command. yAllows the user to issue the
A y value enables a user to issue the command.
command to targets owned by that user. nPrevents the user from issuing
Whereas, a allows a user to issue the the command. The default is n.
command to targets owned by all users.
aAllows the user to issue the
command against targets owned by
all users.

cmd.stopndm Determines if the user can issue the stop y|n

command. yAllows the user to issue the
command.
nPrevents the user from issuing
the command. The default is n.

cmd.s+conf Determines if the user can issue commands y|n

from network clients, such as IBM Sterling yAllows the user to issue
Control Center or Java API, to configure commands. The default is y.
Sterling Connect:Direct Secure Plus.
nPrevents the user from issuing
Note: This parameter has no effect on commands.
local tools, such as spadmin.sh and
spcli.sh.

56 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Local User Information Record Format

Parameter Description Value

cmd.submit Determines if the user can issue the submit y|n

process command. yAllows the user to issue the
command.
nPrevents the user from issuing
the command. The default is n.

cmd.trace Determines if the user can issue the trace y|n

command. yAllows the user to issue the
command.
nPrevents the user from issuing
the command. The default is n.

pstmt.crc Enables the user to override the initial settings y|n

to use the keyword CRC in a Process yAllows the user to issue the
statement. command.
nPrevents the user from issuing
the command. The default is n.

descrip Permits the administrator to add descriptive Unlimited text string

notes to the record.

name The name of the user. User name

phone The phone number of the user. user phone number

pstmt.copy Determines if the user can issue the copy y|n

statement. yAllows the user to issue the
command.
nPrevents the user from issuing
the command. The default is n.

pstmt.copy.ulimit The action taken when the limit on a user y | n | nnnnnnnn | nnnnnnnnK |
output file size is exceeded during a copy nnnnnnnM | nnnnG
operation. The value for this parameter yHonors the user file size limit. If
overrides the equivalent value for the ulimit this limit is exceeded during a copy
parameter in the initialization parameters file. operation, the operation fails.
nIgnores the limit. The default is
n.
nnnnnnnn, nnnnnnnnK, nnnnnnnM,
or nnnnGEstablishes a default
output file size limit for all copy
operations. K denotes 1024 bytes.
M denotes 1048576 bytes. G
denotes 1073741824 bytes. The
maximum value you can specify is
1 TB.

IBM Sterling Connect:Direct for UNIX Administration Guide 57

Chapter 6 Maintaining Access Information Files

Parameter Description Value

pstmt.upload Determines if the user can send files from this y|n
local node. If a file open exit is in use, this yAllows the user to send files.
parameter is passed to the exit, but it is not The default is y.
enforced.
nPrevents the user from sending
files.

pstmt.upload_dir The directory from which the user can send Directory path name
files. If a value is set for this parameter, then
files can only be sent from this directory or
subdirectories. If a file open exit is in use, this
parameter is passed to the exit, but it is not
enforced. If this parameter is defined, file
names in Copy statements must be relative to
this directory. Absolute path names can be
used, but the path must coincide with this
specification.

pstmt.download Determines if the user can receive files to this y|n

local node. If a file open exit is in use, this yAllows the user to receive files.
parameter is passed to the exit, but it is not The default is y.
enforced.
nPrevents the user from
receiving files.

pstmt.download_dir The directory to which the user can receive Directory path name
files. If a value is set for this parameter, then
files can only be received to this directory or
subdirectories. Otherwise, they can be
received to any directory. If a file open exit is
in use, this parameter is passed to the exit, but
it is not enforced.

pstmt.run_dir The directory where Sterling Connect:Direct is Directory path name

installed that contains the programs and
scripts the user executes with run job and run
task statements. Any attempt to execute a
program or script outside the specified
directory fails.
The UNIX Restricted Shell provides enhanced
security by restricting the user to the
commands contained in the pstmt.run_dir. If
the user does not specify pstmt.run_dir, the
commands are started with the Bourne shell.
To restrict the use of special characters in the
run directory, be sure to configure Y for the
restrict:cmd initialization parameter. For
more information on specifying the
restrict:cmd initialization parameter, see
Restricting the Use of Special Characters in
the Run Directory on page 23.

58 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Remote User Information Record

Parameter Description Value

pstmt.runjob Specifies whether the user can issue the run y|n
job statement. yAllows the user to issue the
statement.
nPrevents the user from issuing
the statement. The default is n.

pstmt.runtask Specifies whether the user can issue the run y|n
task statement. yAllows the user to issue the
statement.
nPrevents the user from issuing
the statement. The default is n.

pstmt.submit Specifies whether the user can issue the y|n

submit statement. yAllows the user to issue the
statement.
nPrevents the user from issuing
the statement. The default is n.

pstmt.submit_dir The directory from which the user can submit Directory path name
Processes. This is for submits within a
Process.

snode.ovrd Specifies whether the user can code the y|n

snodeid parameter on the submit command yAllows the user to code the
and process and submit statements. snodeid parameter
nPrevents the user from coding
the snodeid parameter. The
default is n.

pstmt.crc Gives the user the authority to specify the use y|n
of CRC checking in a Process statement. yAllows a user to specify CRC
Setting this parameter to y enables the user to checking on a Process statement.
override the initial settings in the initialization nPrevents a user from specifying
parameters or network map settings files. CRCchecking on a Process
statement. The default is n.

If the same parameter is specified in the remote user information record and the local user
information record, the parameter in remote user information record takes precedence unless it is a
null value. When a null value is specified in the remote record, the local user record takes
precedence.

Updating the Remote User Information Record

The remote user information record contains a remote user ID and a remote node name that become
the key to the record. The local.id parameter identifies a local user information record for this user.
You must create a local user information record for the remote user.

IBM Sterling Connect:Direct for UNIX Administration Guide 59

Chapter 6 Maintaining Access Information Files

Note: To prevent the remote user from using Sterling Connect:Direct, delete or comment out the remote
user information, unless the remote user specifies an SNODEID parameter in the Process.

The remote user information record is remote userid@remote node name. It specifies the user and
remote node name pair defined as a remote user. This value becomes the key to the record and must
be unique. Create a remote user information record for each user on a remote node that will
communicate with this local node.
Following are the parameters for the remote user information record:

Parameter Description Value

local.id The local user ID to use for security Local user ID

checking on behalf of the remote user.
The local.id parameter must identify a
local user information record.

pstmt.copy Determines if the user can issue the copy y|n

statement. yAllows a user to issue the
statement.
nPrevents a user from issuing the
statement. The default is n.

pstmt.upload Determines if the user can send files from y|n

this local node. If a file open exit is in use, yAllows a user to send files. The
this parameter is passed to the exit, but it default is y.
is not enforced.
nPrevents a user from sending
files.

pstmt.upload_dir The directory from which the user can Directory path name
send files. If a value is set for this
parameter, then files can only be sent
from this directory or subdirectories. If a
file open exit is in use, this parameter is
passed to the exit, but it is not enforced. If
this parameter is defined, file names in
Copy statements must be relative to this
directory. Absolute path names can be
used, but the path must coincide with this
specification.

pstmt.download Determines if the user can receive files to y|n

this local node. If a file open exit is in use, yAllows a user to receive files. The
this parameter is passed to the exit, but it default is y.
is not enforced.
nPrevents a user from receiving
files.

60 IBM Sterling Connect:Direct for UNIX Administration Guide

 Updating the Remote User Information Record

Parameter Description Value

pstmt.download_dir The directory to which the user can Directory path name
receive files. If a value is set for this
parameter, then files can only be received
to that directory or subdirectories.
Otherwise, they can be received to any
directory. If a file open exit is in use, this
parameter is passed to the exit, but it is
not enforced.

pstmt.run_dir The directory that contains the programs Directory path name
and scripts the user can execute with run
job and run task statements. Any
attempt to execute a program or script
outside the specified directory fails.
To restrict the use of special characters in
the run directory, be sure to configure Y
for the restrict:cmd initialization
parameter. For more information on
specifying the restrict:cmd initialization
parameter, see Restricting the Use of
Special Characters in the Run Directory
on page 23.

pstmt.submit_dir The directory from which the user can Directory path name
submit Processes. This is for submits
within a Process.

pstmt.runjob Specifies whether the user can issue the y|n

run job statement. yAllows a user to issue the
statement.
nPrevents a user from issuing the
statement. The default is n.

pstmt.runtask Specifies whether the user can issue the y|n

run task statement. yAllows a user to issue the
statement.
nPrevents a user from issuing the
statement. The default is n.

pstmt.submit Specifies whether the user can issue the y|n

submit statement. yAllows a user to issue the
statement.
nPrevents a user from issuing the
statement. The default is n.

descrip Permits you to add descriptive notes to Text string

the record.

IBM Sterling Connect:Direct for UNIX Administration Guide 61

Chapter 6 Maintaining Access Information Files

Updating the Strong Access Control File

To provide a method of preventing an ordinary user from gaining root access through Sterling
Connect:Direct, a strong access control file called sysacl.cfg is created at installation in the
d_dir/ndm/SACL/ directory. By default, an ordinary user cannot access the root through Sterling
Connect:Direct for UNIX. If you want to give an ordinary root user access through Sterling
Connect:Direct for UNIX, you must access and update the sysacl.cfg file.

Note: Even if you do not want to limit root access through Sterling Connect:Direct for UNIX, the
sysacl.cfg file must exist. If the file is deleted or corrupted, all users are denied access to Sterling
Connect:Direct for UNIX.

The file layout of the sysacl.cfg file is identical to the user portion of the userfile.cfg file. Setting a
value in the sysacl.cfg file for a user overrides the value for that user in the userfile.cfg file.
The root:deny.access parameter, which is specified in the sysacl.cfg file, allows, denies, or limits
root access to Sterling Connect:Direct. This parameter is required. The following values can be
specified for the root:deny.access parameter:

Parameter Description Value

deny.access Allows, denies, or limits root access to y|n|d

IBM Sterling Connect:Direct yNo Processes can acquire root authority
nPNODE Processes can acquire root
authority, but SNODE Processes can not.
This is the default value.
dAny Process can acquire root authority

If a user is denied access because the root:deny.access parameter is defined in the sysacl.cfg file
for that user, a message is logged, and the session is terminated. If a user is running a limited ID, an
informational message is logged.

Automatic Detection of Shadow Passwords

Because shadow password files are available on some versions of the UNIX operating system,
Sterling Connect:Direct for UNIX detects the use of shadow passwords automatically, if available.

62 IBM Sterling Connect:Direct for UNIX Administration Guide

 Limiting Access to the Program Directory

Limiting Access to the Program Directory

The program directory provides enhanced security for the run task and run job process statements
by limiting access to specified scripts and commands. Any attempt to execute a program or script
outside the specified directory fails. The program directory is identified with the pstmt.run_dir
parameter. If the program directory is specified, the UNIX restricted shell is invoked, providing
enhanced security. If the program directory is not specified, the regular (Bourne) shell is invoked
for executing commands with no restrictions.
The restricted shell is very similar to the regular (Bourne) shell, but it restricts the user from
performing the following functions:
Changing the directory (cd)
Changing PATH or SHELL environment variables
Using command names containing a slash (/) character
Redirecting output (> and >>)
Additional information about the restricted shell can be found in the appropriate UNIX manual
pages or UNIX security text books.
The restricted shell is started using only the environment variables HOME, IFS, PATH, and
LOGNAME, which are defined as follows:
HOME=run_dir
IFS=whitespace characters (tab, space, and newline)
PATH=/usr/rbin and run_dir
LOGNAME=users UNIX ID
Because environment variables are not inherited from the parent Process, no data can be passed to
the script or command through shell environment variables. The restricted shell restricts access to
specified scripts and commands, but it does not restrict what the scripts and commands can do. For
example, a shell script being executed within the run_dir directory can change the value of PATH
and execute command names containing a slash (/) character. For this reason, it is important that the
system administrator controls which scripts and commands the user has access to and does not give
the user write privileges to the run_dir directory or any of the files in the run_dir directory.

Security Exit
The Security Exit in the initialization parameters file, initparm.cfg, provides an interface to
password support programs.
This exit generates and verifies passtickets and it also supports other password support programs.
An example of other programs is PASSTICKET, part of the RACF security system available on
MVS hosts and also supported by IBM on UNIX AIX and OS/2 computers using the NETSP
product.
Refer to Chapter 3, Maintaining the Initialization Parameters File, for information on the Security
Exit.

IBM Sterling Connect:Direct for UNIX Administration Guide 63

Chapter 6 Maintaining Access Information Files

64 IBM Sterling Connect:Direct for UNIX Administration Guide

 Chapter 7

Maintaining Client and Server Authentication

Key Files

This chapter contains information about client and server authentication key files. You can edit both
key files with any text editor installed on your system.

About Client and Server Authentication Key Files

Sterling Connect:Direct client/server security depends on a key, similar to a password, in an
Sterling Connect:Direct server and an identical key in each API that communicates with that server.
The keys are defined and coordinated by the system administrator.
The client key file is called keys.client on the node on which the API resides. The server key file is
keys.server on the node on which the server resides. The key files are located in the directory
d_dir/security.

Key File Format

A record in a key file can contain up to four keys that match entries in another API or server key
file. The key file can contain as many key file records as necessary. The format of a key file entry
is illustrated in the following sample:

hostname MRLN SIMP key [key [key [key] ] ]

IBM Sterling Connect:Direct for UNIX Administration Guide 65

Chapter 7 Maintaining Client and Server Authentication Key Files

Updating Key File Parameters

The following table describes the available key file parameters:

Parameter Description Value

hostname The host name of the server with which you want to 116 characters and must be
communicate or the host name of the API you will unique within its key file.
allow to communicate with your server. The
hostname is followed by one or more space
characters. If you replace the host name with an
asterisk (*) character in the server configuration file,
the server accepts a connection from any API with a
matching key. You can use only one asterisk per file.
Always place the entry with the asterisk after entries
with specific host names.

MRLN SIMP A required character string, separated from the other Character string
fields by one or more spaces.

key The security key. Separate the key from SIMP by Up to 22 characters long
one or more spaces. including A to Z, a to z, 0 to 9,
period (.), and
slash (/).

Sample Client Authentication Key File

The following figure illustrates API key lists in the Clients column and server key lists in the
Servers column.
API A contains key11, key21, key31, and key41. Key11 enables API A to communicate with
Server A because Server A also contains the key11 entry. You must ensure that API1 is the
host name on which API A resides and that Server1 is the host name on which Server A
resides.
API D contains key14, key24, and key34. Key14 enables API D to communicate with Server
A because Server A also contains the key14 entry. You must ensure that API4 is the host name
on which API D resides and that Server1 is the host name on which Server A resides.

66 IBM Sterling Connect:Direct for UNIX Administration Guide

 About the Authentication Procedure

API C can communicate with Server A and Server B through matching keys. API C also can
communicate with Server C and Server D only through the * MRLN SIMP keyany line.

Clients Servers
API A SERVER A
Server1 MRLN SIMP key11 API1 MRLN SIMP key11
Server2 MRLN SIMP key21 API2 MRLN SIMP key12
Server3 MRLN SIMP key31 API3 MRLN SIMP key13
Server4 MRLN SIMP key41 API4 MRLN SIMP key14

API B SERVER B
Server1 MRLN SIMP API1 MRLN SIMP key21
key12 API2 MRLN SIMP key22
Server2 MRLN SIMP API3 MRLN SIMP key23
key22 API4 MRLN SIMP key24
API C SERVER C
Server1 MRLN SIMP key13 API1 MRLN SIMP key31
Server2 MRLN SIMP key23 API2 MRLN SIMP key32
* MRLN SIMP keyany API3 MRLN SIMP key33
* MRLN SIMP keyany
API D SERVER D
Server1 MRLN SIMP key14 API1 MRLN SIMP key41
Server2 MRLN SIMP key24 API2 MRLN SIMP key42
Server3 MRLN SIMP key34 * MRLN SIMP keyany
* MRLN SIMP keyany

Note: Substitute the correct host name for Server1, 2, 3, or 4 and API1,
2, 3, or 4.

About the Authentication Procedure

The Sterling Connect:Direct authentication procedure determines if the user is authorized to access
the system.
The goal of Sterling Connect:Direct security is to reliably determine the identity of each user
without requiring logon repetition. In addition, the security design ensures that all requests originate

IBM Sterling Connect:Direct for UNIX Administration Guide 67

Chapter 7 Maintaining Client and Server Authentication Key Files

from the Sterling Connect:Direct API, to ensure that the authentication procedure is not bypassed
by an unauthorized user. The following figure displays the components that perform authentication:

Secondary Node Primary Node

User Application
Connect:Direct Server
Connect:Direct API

Key File Key File

Server Authentication Parameters

The server authentication parameters are specified in initparm.cfg. You must have ownership and
permissions to modify these files. Ownership is established during the installation procedure.
Additionally, the directory containing the keys.server file must have UNIX permission 0700, and
keys.server must have UNIX permission 0600. These files cannot be owned by root.
The following server authentication parameters are used by the CMGR during the authentication
procedure:

Parameter Description

server.program The server program to use during the authentication procedure.

server.keyfile The key file to use during the authentication procedure.

Client Authentication Parameters

The client authentication parameters are specified in ndmapi.cfg. You must have ownership and
permissions to modify these files. Ownership is established during the installation procedure.
Additionally, the directory containing the keys.client file must have UNIX permission 0700, and
keys.client must have UNIX permission 0600.
The following client authentication parameters are used by the CLI/API during the authentication
procedure:

Parameter Description

client.program The client program to use during the authentication procedure.

client.keyfile The key file to use during the authentication procedure.

68 IBM Sterling Connect:Direct for UNIX Administration Guide

 Appendix A

Configuring Firewall Navigation

Firewall navigation enables controlled access to an Sterling Connect:Direct system running behind
a packet-filtering firewall without compromising your security policies or those of your trading
partners. You control this access by assigning a specific TCP or UDT source port number or a range
of source port numbers with a specific destination address (or addresses) for Sterling
Connect:Direct sessions.
Before you configure source ports in the Sterling Connect:Direct initialization parameters, you need
to review the information in this chapter, especially if you are implementing firewalls for UDT.

Implementing Firewall Navigation

To implement firewall navigation in Sterling Connect:Direct:
1. Coordinate IP address and associated source port assignment with your local firewall
administrator before updating the firewall navigation record in the initialization parameters
file.
2. Add the following parameters to the Sterling Connect:Direct initialization parameters file as
needed, based on whether you are using TCP or UDT:
tcp.src.ports
tcp.src.ports.list.iterations
udp.src.ports
udp.src.ports.list.iterations
3. Coordinate the specified port numbers with the firewall administrator at the remote site.

Firewall Navigation
Firewall rules need to be created on the local firewall to allow the local Sterling Connect:Direct
node to communicate with the remote Sterling Connect:Direct node. A typical packet-filtering
firewall rule specifies that the local firewall is open in one direction (inbound or outbound) to
packets from a particular protocol with particular local addresses, local ports, remote addresses, and

IBM Sterling Connect:Direct for UNIX Administration Guide 69

Appendix A Configuring Firewall Navigation

remote ports. Firewall Navigation differs between TCP and UDT; as a result, firewall rules for TCP
and UDT should be configured differently.

TCP Firewall Navigation Rules

In the following table, the TCP rules are presented in two sections: the first section applies to rules
that are required when the local node is acting as a PNODE; the second section applies to rules that
are required when the local node is acting as an SNODE. A typical node acts as a PNODE on some
occasions and an SNODE on other occasions; therefore, its firewall will require both sets of rules.

TCP PNODE Rules

Rule Name Rule Direction Local Ports Remote Ports

PNODE session Outbound Local C:Ds source ports Remote C:Ds listening port

TCP SNODE Rules

Rule Name Rule Direction Local Ports Remote Ports

SNODE session Inbound Local C:Ds listening port Remote C:Ds source ports

UDT Firewall Navigation Rules

UDT firewall rules are applied to the UDP protocol. The recommended default firewall rule for
UDP packets is to block packets inbound to the local system and outbound from the local system
to prevent the confusion that could occur due to the callback feature of UDT session establishment.
In the following table, the UDT rules are presented in two sections: the first section applies to rules
that are required when the local node is acting as a PNODE; the second section applies to rules that
are required when the local node is acting as an SNODE. A typical node acts as a PNODE on some
occasions and an SNODE on other occasions; therefore, its firewall will require both sets of rules.

UDT PNODE Rules

Rule Name Rule Direction Local Ports Remote Ports

PNODE Session Request Outbound Local C:Ds source ports Remote C:Ds listening port

PNODE Session Outbound Local C:Ds source ports Remote C:Ds source ports

UDT SNODE Rules

Rule Name Rule Direction Local Ports Remote Ports

SNODE listen Inbound Local C:Ds listening port Remote C:Ds source ports

SNODE session Inbound Local C:Ds source ports Remote C:Ds source ports

70 IBM Sterling Connect:Direct for UNIX Administration Guide

 Firewall Configuration Examples

Firewall Configuration Examples

In the firewall configuration examples for TCP and UDT, the following IP addresses and source
ports will be used:

Note: The IP addresses in the examples have been chosen to be distinctive and are not intended to be valid
IP addresses.

The local node has IP address 222.222.222.222 and listening port 2264. Its source ports for
communicating with the remote node are 20002200.
The remote node has IP address 333.333.333.333 and listening port 3364. Its source ports for
communicating with the local node are 30003300.

Note: See Session Establishment on page 72 for a discussion of the differences between UDT and TCP
session establishment.

TCP Firewall Configuration Example

The Sterling Connect:Direct administrator configures the local node to listen on port 2264, and the
following initialization parameter settings are used to configure the local node's source ports:
tcp.src.ports = (333.333.333.333, 20002200)
tcp.src.ports.list.iterations = 1
This configuration specifies to use a source port in the range 20002200 when communicating with
the remote nodes address 333.333.333.333 and to search the port range one time for an available
port. The local node will act as both a PNODE and an SNODE when communicating with the
remote node.
Based on this scenario, the firewall rules for the local node are the following:

Rule Name Rule Direction Local Ports Remote Ports

PNODE session request Outbound 20002200 3364

SNODE session Inbound 2264 30003300

UDT Firewall Configuration Example

The Sterling Connect:Direct administrator configures the local node to listen on port 2264, and the
following initialization parameter settings are used to configure the local node's source ports:
udp.src.ports = (333.333.333.333, 2000-2200)
udp.src.ports.list.iterations = 1
This configuration specifies to use a source port in the range 20002200 when communicating with
the remote nodes address 333.333.333.333 and to search the port range one time for an available
port. The local node will act as both a PNODE and an SNODE when communicating with the
remote node.

IBM Sterling Connect:Direct for UNIX Administration Guide 71

Appendix A Configuring Firewall Navigation

Based on this scenario, the firewall rules for the local node are the following:

Rule Name Rule Direction Local Ports Remote Ports

PNODE session request Outbound 20002200 3364

PNODE session Outbound 20002200 30003300

SNODE listen Inbound 2264 30003300

SNODE session Inbound 20002200 30003300

Blocking Outbound Packets

The recommended default rule for outbound UDP packets from the local system is to block the
packets. If you do not follow this recommendation, port usage may, at first sight, appear to violate
the firewall's inbound rules.
An example will help illustrate this situation. Suppose that in the example in the previous section:
The local node is the SNODE.
The default outbound rule allows all outbound UDP packets from the local system.
The SNODE session rule is accidently omitted.
Because of the callback feature of UDT session establishment, SNODE sessions are still likely to
succeed on ports 20002200. This may cause confusion because ports 20002200 are blocked to
inbound UDP packets.
If you use the recommended default outbound rule and apply the PNODE and SNODE rules
described in the previous section, there will be no confusion about which port to use, and the UDT
callback feature will function as designed, thus supporting reliability.

Session Establishment
Session establishment differs between TCP and UDT; these differences affect how you set up
firewall rules and configure the firewall navigation initialization parameters in Sterling
Connect:Direct.

TCP Session Establishment

An Sterling Connect:Direct TCP client contacts an Sterling Connect:Direct TCP server on its
listening port. The Sterling Connect:Direct client scans the list of ports (specified using the
tcp.src.ports initialization parameter) and looks for a port to bind to. The number of times Sterling
Connect:Direct scans the list is specified using the tcp.src.ports.list.iterations initialization
parameter. If Sterling Connect:Direct finds an available port, communication with the remote node
proceeds.

72 IBM Sterling Connect:Direct for UNIX Administration Guide

 Session Establishment

UDT Session Establishment

When an Sterling Connect:Direct UDT client contacts an Sterling Connect:Direct UDT server on
its listening port to request a session, the UDT server responds with a different server port to use for
the session. The client attempts to contact the server on the session port. The Sterling
Connect:Direct client scans the list of ports (specified in the udp.src.ports initialization parameter)
and looks for an available port to bind to. The number of times Sterling Connect:Direct scans the
list is specified using the udp.src.ports.list.iterations initialization parameter. If the Sterling
Connect:Direct client finds an available port, communication with the remote Sterling
Connect:Direct server proceeds. If a session cannot be established after a certain time interval, the
server attempts to contact the client.

IBM Sterling Connect:Direct for UNIX Administration Guide 73

Appendix A Configuring Firewall Navigation

74 IBM Sterling Connect:Direct for UNIX Administration Guide

 Appendix B

Specifying IP Addresses, Host Names, and

Ports

Sterling Connect:Direct accepts both Internet Protocol version 4 (IPv4) and Internet Protocol
version 6 (IPv6) versions of the Internet Protocol as well as host names. You can enter IP
addresses/host names and ports in several ways, depending on the field you are specifying:
Address or host name only
Port number only
Address/host name with a port number
Multiple address/host name and port combinations
When specifying IP addresses/host names and ports for Sterling Connect:Direct, use the following
guidelines.

IP Addresses
Sterling Connect:Direct accepts both IPv4 and IPv6 addresses. Wherever an IP address is specified
in IBM Sterling Connect:Direct, you can use either IPv4 or an IPv6 addresses.

IPv4 Addresses
IPv4 supports 232 addresses written as 4 groups of dot-separated 3 decimal numbers (0 through 9),
for example, 10.23.107.5.

IPv6 Addresses
IPv6 supports 2128 addresses written as 8 groups of colon-separated 4 hexadecimal digits, for
example, 1001:0dc8:0:0:0:ff10:143e:57ab. The following guidelines apply to IPv6 addresses:
If a four-digit group contains zeros (0000), the zeros may be omitted and replaced with two
colons (::), for example:

2001:0db8:85a3:0000:1319:8a2e:0370:1337
can be shortened as
2001:0db8:85a3::1319:8a2e:0370:1337

IBM Sterling Connect:Direct for UNIX Administration Guide 75

Appendix B Specifying IP Addresses, Host Names, and Ports

Any number of successive 0000 groups may be replaced with two colons (::), but only one set
of double colons (::) can be used in an address, for example:

001:0db8:0000:0000:0000:0000:1319:58ab
Can be shortened as:
2001:0db8:0000:0000::1319:58ab

Leading zeros in a four-zero group can be left out (0000 can be shortened to 0), for example:

2001:0db8:0000:0000:0000:0000:1319:58ab
Can be shortened as:
2001:0db8:0:0:0:0:1319:58ab

You can write a sequence of 4 bytes that occur at the end of an IPv6 address in decimal format
using dots as separators, for example:

::ffff:102:304
Can be written as:
::ffff:1.2.3.4

This notation is useful for compatibility addresses.

Host Names
When you specify a host name, rather than an IP address, Sterling Connect:Direct gets the IP
address from the operating system. The first IP address returned by the operating system is used
regardless of whether it is in IPv4 or IPv6 format.
A host name (net, host, gateway, or domain name) is a text string of up to 24 characters comprised
of the alphabet (AZ), digits (09), minus sign (-), and period (.), for example, msdallas-dt.
The following guidelines also apply:
No blank or space characters are permitted as part of the name.
Periods are allowed only when they are used to delimit components of domain-style names.
Host names are not case sensitive.
The first and last character must be a letter or digit.
Single-character names or nicknames are not allowed.

76 IBM Sterling Connect:Direct for UNIX Administration Guide

 Port Numbers

Port Numbers
Port numbers can be appended to the end of IP/host addresses when they are preceded by a
semi-colon (;), for example, 10.23.107.5;1364. This convention is specific to Sterling
Connect:Direct and is not an industry standard.
A port number must be in the range of 0 through 65535. Port numbers lower than 1024 are
designated as reserved and should not be used. The following examples show port numbers
appended to IP/host addresses using these conventions:

10.23.107.5;1364
fe00:0:0:2014::7;1364
msdallas-dt;1364

Multiple Addresses, Host Names, and Ports

You can specify multiple IPv4 and IPv6 addresses and host names by separating them with a
comma (,). A space can be added after the comma for readability, for example:

10.23.107.5, fe00:0:0:2014::7, msdallas-dt

You can also specify a port number for each address or host name. The port is separated from its
corresponding address/host name with a semi-colon (;), and each address/host name and port
combination is separated by a comma (,). A space may be added after the comma for readability.
The following example shows multiple address/host name and port combinations:

10.23.107.5;1364, fe00:0:0:2014::7;1364, msdallas-dt;1364

Multiple address/host names (and combinations with port numbers) are limited to 1024 characters.

Using Masks for IP Address Ranges

When you specify a value for the tcp.src.ports parameter in the initialization parameters file, you
can use masks to specify the upper boundary of a range of IP addresses that will use a specific port,
multiple ports, or a range of ports. Sterling Connect:Direct supports masks for both IPv4 and IPv6
addresses as shown in the following sample entry from the initparms.cfg file:

tcp.src.ports=(199.2.4.*, 1000), (fd00:0:0:2015:*::*, 2000-3000), (199.2.4.0/255.255.255.0, 4000-5000),

(fd00:0:0:2015::0/48, 6000, 7000)

IBM Sterling Connect:Direct for UNIX Administration Guide 77

Appendix B Specifying IP Addresses, Host Names, and Ports

These sample addresses specify the following information:

(199.2.4.*, 1000)Any IPv4 address that falls in the range from 199.2.4.0 through 199.2.4.255 will
use only port 1000.
(fd00:0:0:2015:*::*, 2000-3000)Any IPv6 address that falls in the range from
fd00:0:0:2015:0:0:0:0 through fd00:0:0:2015:ffff:ffff:ffff:ffff will use a port in the range of 2000
through 3000.
(199.2.4.0/255.255.255.0, 4000-5000)Any IPv4 address that falls in the range from 199.2.4.0
through 199.2.255.255 will use a port in the range of 4000 through 5000.
(fd00:0:0:2015::0/48, 6000, 7000)Any IPv6 address that falls in the range from
fd00:0:0:2015:0:0:0:0 through fd00:0:0:ffff:ffff:ffff:ffff:ffff will use port 6000 or port 7000.
As shown in the sample entry above, the wildcard character (*) is supported to define an IP address
pattern. You can specify up to 255 unique IP address patterns or up to 1024 characters in length,
each with its own list of valid source ports. If the wildcard character is used, the optional mask is
not valid.

78 IBM Sterling Connect:Direct for UNIX Administration Guide

 Appendix C

Using Sterling Connect:Direct in a Test Mode

You can enable a test mode for production instances of Sterling Connect:Direct to perform the
following functions:
Test new applications and customer connections
Prevent future production work from executing until testing is complete after you have
terminated all active production work using the Flush Process command
Resume regular production work after testing
Control individual file transfers by application
Enable and disable individual nodes and applications
While testing is being conducted, only Processes, particularly file transfers, involved with the
testing activity are executed. No production data is transferred to applications being tested while at
the same time no test data is transferred to production applications.

Processing Flow of the Test Mode

You enable the testing mode using the quiesce.resume initialization parameter and specify which
Sterling Connect:Direct Processes to run and not run by storing your preferences as text records in
a parameter table named NDMPXTBL. A sample parameters file, NDMPXTBL.sample, is located
in the /ndm/src directory. After you have updated the file for your testing environment, place it in
the installation ndm/cfg/<nodename> directory. If you enable the quiesce.resume parameter, you
must have an NDMPXTBL table to operate Sterling Connect:Direct in a test mode.
You can specify the following criteria that are used to find matches for one or more Processes to
include (using the I command code) or exclude (X command code) from execution:
A partial or full Process name
A partial or full remote node name
A partial or full Sterling Connect:Direct submitter ID and submitter node combination

IBM Sterling Connect:Direct for UNIX Administration Guide 79

Appendix C Using Sterling Connect:Direct in a Test Mode

In addition to telling Sterling Connect:Direct which Processes to run, you tell the system what to do
with the Processes which do not get executed. You can specify the following dispositions for
Processes not permitted to run:
Place the Process in the Hold queue
Place the Process in the Timer queue for session retry
Flush the Process from the queue
For more information on how the testing mode can be used, see Sample Test Scenarios on page 82.
When the testing mode is enabled, Sterling Connect:Direct performs a syntax check on the
parameter table and fails initialization if the table is invalid. If the table is valid, Sterling
Connect:Direct scans it looking for a pattern that matches the Process that is about to execute. If a
match is found, the Process is permitted to execute if the I (Include) command code is in effect.
If command code X (Exclude) is in effect, the process is not permitted to execute. If a match is
not found in the table, the opposite processing occurs from the case where a match is found, that is,
if no match is found and command code I is in effect, the Process is not permitted to execute,
whereas if command code X is in effect, the Process is permitted to execute.
If a Process is not permitted to execute, the disposition specified in the NDMPXTBL parameter
table to either hold, retry, or flush the Process is implemented and a non-zero return code is returned.
When a Process is prevented from executing in testing mode, appropriate messages are issued and
can be viewed in the statistics log.

Note: For Processes initiated on remote nodes, the testing mode functions in the same manner as it does
for Processes submitted on the local Sterling Connect:Direct node except that the remote node is the
PNODE (Process owner) for that Process, and the local node is the SNODE (secondary node). The
NDMPXTBL Parameter Table is searched for a matching entry, and the remotely-initiated Process
is either permitted to execute or is excluded from execution. Because the local node is the SNODE
for this type of transfer, it cannot enforce the Process disposition setting in the NDMPXTBL
parameter table. The remote PNODE determines how the Process is handled. Typically, the remote
node places the Process in the Hold queue with a status of HE (Held in Error).

Preparing the NDMPXTBL Parameter Table

You can use any text editor to modify the sample NDMPXTBL parameter table supplied with
Sterling Connect:Direct. When you update the parameter table, name it NDMPXTBL and save it to
the Server directory of the installation. The parameter table file can be created or updated while the
server is active, and any changes made to the file take effect for sessions that begin after the changes
are made. Similarly, the quiesce.resume initialization parameter can be modified while the server
is active. For more information on the quiesce.resume initialization parameter, see Updating the
Quiesce/Resume Record on page 23.

Note: If you enable the quiesce.resume initialization parameter, you must have an NDMPXTBL
parameter table.

80 IBM Sterling Connect:Direct for UNIX Administration Guide

 Preparing the NDMPXTBL Parameter Table

Each table entry or record consists of a single-character command code in column one. Most
command codes have a parameter which begins in column two and varies according to the
command code function.

Command Description Subparameters/

Code Examples

* Comment line. * Only run the following Processes.

E Enables execution of Processes based on table The second column in this entry must
entries. Either E or D must be the first contain one of the following values
non-comment entry in the table. which indicates the disposition of a
PNODE Process if it is not allowed to
run.
HPlaces the Process in the Hold
queue
RPlaces the Process in the Timer
queue in session retry
FFlushes the Process from the
queue

D Disables the execution of all Processes regardless The parameter for command code
of the contents of the parameter table and fails E can also be specified in column
Process execution with a non-zero (error) return two. This is a convenience to make it
code and message LPRX003E. Either E or D easier to change from E to D and
must be the first non-comment entry in the table vice versa without having to change
column two to a blank for command
code D.

P Matches Processes based on a full or partial PCOPYMatches a single Process

Process name. Supports the wild card trailing PACH*Matches all Processes
asterisk (*). Can be used to enable or disable beginning with ACH
Process execution for a particular application by
P*Matches all Processes
using naming conventions to match an application.

N Matches Processes based on a full or partial remote NCD.NODE1Matches a single

node name. Supports the wild card trailing asterisk remote node name
(*). NCD.NODEA*Matches all remote
node names beginning with
CD.NODEA N*Matches all
remote node names

S Matches Processes based on a full or wild card SACTQ0ACD@TPM002Matches

Sterling Connect:Direct submitter ID and submitter a specific ID and node combination.
node combination. The format is <id>@<node>. S*@TPM002Matches all IDs from
node TPM002
SACTQ0ACD@*Matches ID
ACTQ0ACD from all nodes
S*@*Matches all IDs from any
node. This is another way to match
all Processes.

IBM Sterling Connect:Direct for UNIX Administration Guide 81

Appendix C Using Sterling Connect:Direct in a Test Mode

Command Description Subparameters/

Code Examples

I Includes Processes for execution that match the ER

patterns in the table which follow this command I
code. Either I or X must be the second
NCD.BOSTON
non-comment entry in the table. Processes which do
not match a pattern in the table are not executed.
Includes Processes for execution on
Note: To choose which command code to use to
the CD.BOSTON node only.
select Processes, determine which group
Processes destined for all other
is smaller and use the corresponding
remote nodes are placed in the Timer
command Code. For example, if the
queue in session retry
number of Processes to be executed is
smaller than the number of Processes to
exclude from execution, specify I as the
command code and add patterns to match
that group of Processes.

X Excludes from execution those Processes that EH

match the patterns in the table which follow this X
command code. Either X or I must be the second
SDALLASOPS@*
non-comment entry in the table. Processes which do
not match a pattern in the table are executed.
Excludes Processes for execution
submitted by the ID DALLASOPS
from any node

L Last entry in table.

Sample Test Scenarios

The following examples show different applications of the test mode using the NDMPXTBL
parameter table to define which Sterling Connect:Direct Processes to run and not run.

Specifying Which Processes Run

In this example, Sterling Connect:Direct executes all Processes that start with ACH or are named
DITEST01 or DITEST02. All other Processes are placed in the Hold queue.

* Enable processing. Only permit processes matching one of the patterns

* to execute. Hold processes that don't execute.
EH
I
PACH*
PDITEST01
PDITEST02
L

82 IBM Sterling Connect:Direct for UNIX Administration Guide

 Sample Test Scenarios

Specifying Which Processes to Exclude

In this example, Sterling Connect:Direct does not execute any Process that starts with ACH or is
named DITEST01 or DITEST02. All other Processes are executed.

* Exclude matching processes. Permit all others to execute.

EH
X
PACH*
PDITEST01
PDITEST02
L

Permitting Process Execution by Secondary Node and Submitter User ID/Node

In this example, Sterling Connect:Direct executes all Processes that match one of the following
criteria:
The specific secondary node (SNODE) name is DI.NODE1
An SNODE whose name starts with DI0017
Any Sterling Connect:Direct submitter ID from node DI0049
The specific Sterling Connect:Direct submitter ID ACHAPP from any node
All Processes not matching one of the above criteria are flushed from the queue.

* Only permit matching processes to execute. Flush those that do not.

EF
I
NDI.NODE1
NDI0017*
S*@DI0049
SACHAPP@*
L

Stopping the Test Mode

In this example, no Processes will be executed, and a non-zero return code will be displayed, which
signifies an error along with message ID LPRX003E. The remainder of the table is ignored
(including the F code to flush Processes from the queue), and all Processes are placed in the Hold
queue.
To resume testing, change the D command code to an E.

* Execute no processes at all. Put them in the hold queue and return.
DF
I
PACH*
PDITEST01
PDITEST02
L

IBM Sterling Connect:Direct for UNIX Administration Guide 83

Appendix C Using Sterling Connect:Direct in a Test Mode

84 IBM Sterling Connect:Direct for UNIX Administration Guide

 Glossary

Application Programming Interface (API)

A library of function calls that enables End User Applications (EUAs) to interact with the Sterling
Connect:Direct software.

Client
A program that makes requests of the Sterling Connect:Direct server and accepts the servers
responses.

Command Line Interface (CLI)

A program available to submit Sterling Connect:Direct Processes and commands from a command
line environment.

Command Manager (CMGR)

The program that executes commands sent by the API and sends the results back to the API. In
conjunction with the API, the CMGR carries out the Sterling Connect:Direct authentication
procedure, which determines if the user name and password are authorized to access the system.
CMGR interacts with the PMGR when required by command execution.

daemon
The long-running process that provides a service to a client. The PMGR is the Sterling Connect:Direct
for UNIX daemon.

IBM Sterling Connect:Direct for UNIX Administration Guide 85

Glossary

Diagnostic Commands
Sterling Connect:Direct commands that assist in the diagnosis of Sterling Connect:Direct software
problems.

End User Application (EUA)

An application program developed by an end user to accomplish a particular task.

Execution Queue
A logical queue in the TCQ. A Process in the Execution Queue can be transferring data to or from
a remote Sterling Connect:Direct node or it can be waiting for a connection to the remote
Sterling Connect:Direct node before it can perform its tasks.

Hold Queue
A logical queue in the TCQ. Processes in the Hold Queue are waiting for operator intervention
before they move to the Wait Queue for scheduling.

IBM Sterling Connect:Direct

See Sterling Connect:Direct.

IBM Sterling Connect:Direct Browser User Interface

See Sterling Connect:Direct Browser User Interface.

IBM Sterling Connect:Direct for UNIX

See Sterling Connect:Direct for UNIX.

IBM Sterling Connect:Direct Node

See Sterling Connect:Direct Node.

86 IBM Sterling Connect:Direct for UNIX Administration Guide

 Glossary

IBM Sterling Connect:Direct Process

See Sterling Connect:Direct Process.

IBM Sterling Control Center

See Sterling Control Center.

Monitoring Commands
Sterling Connect:Direct commands that allow you to display information from the statistics file and
the TCQ about Sterling Connect:Direct Process execution results.

Operational Control Commands

Sterling Connect:Direct commands that allow you to submit a Process, change specific
characteristics of a Process in the TCQ, remove executing and nonexecuting Processes from the
TCQ, and stop Sterling Connect:Direct.

Process Manager (PMGR)

The long-running Sterling Connect:Direct server that initializes the Sterling Connect:Direct
software, accepts connection requests from Sterling Connect:Direct APIs and remote Sterling
Connect:Direct nodes, creates Command Managers and Session Managers, accepts requests
from Command Managers and Session Managers where centralized Sterling Connect:Direct
functions are required, and terminates Sterling Connect:Direct software execution.

PNODE (Primary Node)

The Sterling Connect:Direct node on which the Process is being executed. The primary node is also
called the controlling or source node, but is not always the sending node because PNODE can
be the receiver. Every Process has one PNODE and one SNODE. The submitter of a Process is
always the PNODE. The PNODE name can be 116 characters long.

IBM Sterling Connect:Direct for UNIX Administration Guide 87

Glossary

Session
A connection between two Sterling Connect:Direct nodes.

Session Manager (SMGR)

The server component responsible for creating or completing a connection with a remote Sterling
Connect:Direct node and carrying out the Sterling Connect:Direct work to be performed.

SNODE (Secondary Node)

The Sterling Connect:Direct node that interacts with the Primary node (PNODE) during Process
execution. The Secondary node (SNODE) also can be referred to as the participating, target, or
destination node. Every Process has one PNODE and one SNODE. The secondary node is the
node participating in Process execution initiated by another node (PNODE). The SNODE name
can be 116 characters long.

Sterling Connect:Direct
The family of data transfer software products that distributes information and manages production
activities among multiple data centers.

Sterling Connect:Direct Browser User Interface

As an alternative to submitting Sterling Connect:Direct commands through the command line
interface, you can use the Sterling Connect:Direct Browser User Interface to create, submit, and
monitor Processes from an Internet browser, such as Microsoft Internet Explorer. You can also
use the Sterling Connect:Direct Browser User Interface to perform Sterling Connect:Direct
system administration tasks, such as viewing and changing the network map or initialization
parameters, if you have the appropriate Sterling Connect:Direct authority.

Sterling Connect:Direct File Agent

An application program and component of Sterling Connect:Direct. It scans specified directories
searching for the presence of a file. When a file appears in a watched directory, Sterling
Connect:Direct either submits a Process or performs the action specified by the rules for the file.

Sterling Connect:Direct for UNIX

The UNIX implementation of the Sterling Connect:Direct product.

Sterling Connect:Direct Node

Any computer/workstation running Sterling Connect:Direct.

88 IBM Sterling Connect:Direct for UNIX Administration Guide

 Glossary

Sterling Connect:Direct Process

A series of statements, which can be predefined and stored in a directory, submitted through the API
to initiate Sterling Connect:Direct for UNIX activity. Examples of Process functions are
copying files and running jobs.

Sterling Control Center

A centralized management system that provides operations personnel with continuous
enterprise-wide business activity monitoring capabilities for Sterling Connect:Direct z/OS,
UNIX, and Microsoft Windows servers. It manages multiple Sterling Connect:Direct servers to
suspend, release, and delete Processes, stops Sterling Connect:Direct servers, and views
detailed statistics on running or completed Processes. It monitors service levels to view Sterling
Connect:Direct processing across Sterling Connect:Direct for z/OS, UNIX, and Microsoft
Windows servers within your network and retrieve information about active and completed
Processes. It receives notification of data delivery events that occur or do not occur as scheduled
and defines rules that, based on processing criteria, can generate an alert, send an e-mail
notification, generate a Simple Network Management Protocol (SNMP) trap to an Enterprise
Management System (EMS), or run a system command. It monitors for alerts, such as a server
failure or a Process not starting on time.

TCQ Status Value

A two-letter code assigned to a Process by Sterling Connect:Direct when the Process is placed on
the TCQ. The status of a Process can be examined with a select process command.

TCQ (Transmission Control Queue)

A queue that holds all Processes that are submitted to Sterling Connect:Direct for UNIX. TCQ
contains the following four logical queues:
EXECUTION
WAIT
TIMER
HOLD

Timer Queue
A logical queue in the TCQ. Processes on the Timer Queue are waiting for a start time before they
move to the Wait Queue for scheduling.

IBM Sterling Connect:Direct for UNIX Administration Guide 89

Glossary

Wait Queue
A logical queue in the TCQ. Processes on the Wait Queue are waiting on a connection to or from
the remote Sterling Connect:Direct node.

90 IBM Sterling Connect:Direct for UNIX Administration Guide

 Index

A cmd.selstats, Local User Information Record 56

cmd.stopndm, Local User Information Record 56
About the initialization parameters file 19
cmd.submit, Local User Information Record 57
admin.auth, Local User Information Record 55
cmd.trace, Local User Information Record 57
alt.comm.outbound, remote connection parameter 49
CMGR, description 8
API configuration parameters, listed 36
comm.bufsize
api.max.connects, local node connection parameter 41
remote node parameter 49
api.parms record 36
comm.info, remote node connection parameter 24, 50
Authentication parameters, described 31
comm.transport
Authentication record 37 LU 6.2 parameter 24, 50
remote node connection information 50
C remote node connection parameter 24
remote node parameter 24
cdcust script, modifying configuration files 18
Command manager, overview 8
ckpt.interval, copy parameters 26
Configuration
CLI configuration parameter, listed 36 files, modifying 18, 35
CLI/API Configuration file initialization parameters file 19
client.keyfile 37 network map parameters 39
client.program 37 user authorization parameters 53
location 35 conn.retry.ltattempts
tcp.hostname 36 local node parameter 41, 46
tcp.port 36 remote node parameter 51
wait.time 36
conn.retry.ltwait
Client and server authentication key files, about 65 local node parameter 41, 46
Client authentication key file remote node parameter 51
authentication parameters 68 conn.retry.stattempts
overview 65 local node parameter 41, 46
permissions 68 remote node parameter 50
Client authentication parameters, listed 37 conn.retry.stwait
Client configuration file, defined 35 local node parameter 41, 46
remote node parameter 50
client.keyfile, CLI/API configuration parameter 37
contact.name
client.program, CLI/API configuration parameter 37 local node parameter 42, 47
cmd.chgproc, Local User Information Record 55 remote node parameter 51
cmd.delproc, Local User Information record 55 contact.phone
local node parameter 42, 47
cmd.flsproc, Local User Information Record 56
remote node parameter 51
cmd.selproc, Local User Information Record 56
continue.on.exception, copy parameter 26

IBM Sterling Connect:Direct for UNIX Administration Guide 91

 Index

Copy parameters, described 26

I
copy.parms record 26
Initialization parameters file
CRC checking 28, 52, 57, 59 about 19
authentication 31
D ckpt.interval 26
comm.info 24
default, priority parameter 23 comm.transport 24, 50
descrip copy.parms 26
local node parameter 42, 47 defined 19
Local User Information Record 57 ecz.compression.level 27
remote node parameter 51 ecz.memory.level 27
Remote User Information Record 61 ecz.windowsize 27
file.open.exit.program 32
Description file.size 30
CMGR 8 local.node 40
PMGR 7 location 19
SMGR 8 log.commands 30
user authorization 9 log.select 30
max.age 25
E modifying 19
ndm.pam 22
ecz.compression.level, copy parameters 27 path parameter 21
ecz.memory.level, copy parameter 27 priority record 23
recid 24
ecz.windowsize, copy parameters 27
restrict
cmd 58, 61
F retry.codes 27
retry.msgids 28
file.open.exit.program, user exit parameter 32
rnode.listen 24
file.size, file information parameters 30 runtask.parms 29
Files security.exit.program 32
client authentication key file 65 server.keyfile 31
initialization parameters, modifying 19 server.program 31
server authentication key file 65 stats.exit.program 32
strong access control file 62 syslog.logd 30
user authorization information file, modifying 53 tcp.crc 28
tcp.crc.override 28
Firewall navigation parameters, described 33 tcp.src.ports 33, 34, 69
firewall.parms record 33 tcp.src.ports.list.iterations 33, 34, 69
TCQ 25
ulimit 26
G xlate.dir 26
Generic, host name in server configuration file 66 xlate.recv 26
xlate.send 26
H insert.newline parameter 29
Host names IP address
multiple 77 masks 77
specifying 76 IP address ranges, using masks 77

92 IBM Sterling Connect:Direct for UNIX Administration Guide

 Index

IP addresses 75 log.commands, file information parameter 30

IPv4 75
log.select, file information parameters 30
IPv6 75
multiple 77
IPv4 75
M
max.age, parameter 10
IPv4 addresses 75
max.age, TCQ parameter 25
IPv6 75
Modifying configuration files 18
IPv6 addresses 75
guidelines 75
N
K name
parameter, in ndm.node record 22
Key files
overview 65 name, in Local User Information Record 57
permissions required for the client 68 ndm.node record 22
permissions required for the server 68
ndm.path record 21
ndm.pam record 22
L snode.work.path parameter 22
Local User Information Record NDMPXTBL parameter table 80
about 55
admin.auth 55 NDMPXTBL table 79
cmd.chgproc 55 netmap.check, local node parameter 42
cmd.delproc 55
Network map file
cmd.flsproc 56
comm.bufsize 49
cmd.selproc 56
comm.info parameter 50
cmd.selstats 56
conn.retry.ltattempts 41, 46, 51
cmd.stopndm 56
conn.retry.ltwait 41, 46, 51
cmd.submit 57
conn.retry.stattempts 41, 46
cmd.trace 57
conn.retry.stwait 41, 46, 50
descrip 57
contact.name 42, 47, 51
name 57
contact.phone 42, 47, 51
phone 57
descrip 42, 47, 51
pstmt.copy 57, 60
location 39
pstmt.copy.ulimit 57
modifying 39
pstmt.crc 57, 59
netmap.check 42
pstmt.download_dir 58, 61
pacing.send.count 43, 48, 51
pstmt.runjob 59, 61
pacing.send.delay 43, 47, 51
pstmt.runtask 59, 61
proxy.attempt 43
pstmt.submit 59, 61
runstep.max.time.to.wait 44, 47, 52
pstmt.submit_dir 59
sess.default 44, 47
pstmt.upload 58, 60
sess.pnode.max 44, 47, 52
pstmt.upload_dir 58, 60
sess.snode.max 44, 47, 52
snode.ovrd 59
sess.total 44, 47, 52
local.id, Remote User Information Record 60 tcp.api 45
local.node, initialization parameter record 40 tcp.api.bufsize 44
tcp.crc 52

IBM Sterling Connect:Direct for UNIX Administration Guide 93

 Index

tcp.ip.default 46 pstmt.submit_dir
tcp.max.time.to.wait 45, 46 Local User Information Record 59
Remote User Information Record 61
P pstmt.upload
Local User Information Record 58, 60
pacing.send.count
local node parameter 43 pstmt.upload_dir
remote node parameter 51 Local User Information Record 58, 60
tcp/ip settings for local node parameter 48
pacing.send.delay Q
local node parameter 43, 47
quiesce and resume, testing mode 79
remote node parameter 51
quiesce.resume
path parameter, for ndm.path record 21
test mode 79
Permissions
required for the client 68
required for the server 68
R
recid, remote node connection parameter 24
phone, Local User Information Record 57
Record
PMGR, description 7
api.parms 36
Port numbers authentication 31
specifying 77 copy.parms 26
Ports firewall.parms 33
multiple 77 local user information 55
ndm.node 22
proc.prio record 23 ndm.path 21
Process restart, overview 9 remote user information 59
remote userid@remote node name 60
Process, samples 11
runtask.parms 29
profile name, LU 6.2 parameter 24, 50 stats 30
Program directory, about 63 tcp.ip.default 46
tcq 25
proxy.attempt, local node parameter 43 user.exits 32
pstmt.copy, Local User Information Record 57, 60 Record, authentication 37
pstmt.copy.ulimit, Local User Information Record 57 Remote node information record
pstmt.crc, Local User Information Record 57, 59 creating 13
modifying 39
pstmt.download
Local User Information 58, 60 Remote User Information Record
about 59
pstmt.download_dir
descrip 61
Local User Information Record 58, 61
local.id 60
pstmt.run_dir pstmt.run_dir 61
local user information record 58 pstmt.submit_dir 61
remote user information record 61
remote userid@remote node name, user authorization
pstmt.runjob, Local User Information Record 59, 61 information record 60
pstmt.runtask, Local User Information Record 59, 61 restart, run task parameter 29
pstmt.submit, Local User Information Record 59, 61

94 IBM Sterling Connect:Direct for UNIX Administration Guide

 Index

restrict Shadow password detection 62

cmd initialization parameter 58
Shell script, samples 11
cmd, initialization parameter 61
SMGR, description 8
Restricted shell, about 63
snode.ovrd, Local User Information Record 59
retry.codes, copy parameter 27
snode.work.path parameter 22
retry.msgids, copy parameter 28
Statistics file information, parameters 30
rnode.listen record 24
stats record 30
Run task, parameters 29
stats.exit.program, user exit parameter 32
runstep.max.time.to.wait
local node parameter 44, 47 Sterling Connect:Direct
remote node parameter 52 client authentication parameters 68
configuration overview 17
security 65
S security, authentication procedure 67
Samples server authentication parameters 68
Processes 11 strip.blanks parameter 28
shell scripts 11
Strong Access Control File 62
Security
authentication procedure 67 sysacl.cfg, strong access control 62
client authentication parameters 68 syslog.logd, file information parameter 30
format for key files 65
program directory 63
server authentication parameters 68
T
Security Exit, in the Initialization parameters file 63 tcp.api, local node parameter 45

security.exit.program, user exit parameter 32 tcp.api.bufsize, local node parameter 44

Server authentication key file, authentication tcp.api.inactivity.timeout, local node parameter 45

parameters 68 tcp.crc
Server authentication parameters copy parameter 28
described 31 remote node parameter 52
overview 65 tcp.crc.override, copy parameter 28
permissions 68
tcp.hostname CLI/API configuration parameter 36
server.keyfile, server authentication parameter 31
tcp.ip.default, initialization parameter record 46
server.program, server authentication parameter 31
tcp.max.time.to.wait, local node parameter 45, 46
sess.default, local node parameter 44, 47
tcp.port, CLI/API configuration parameter 36
sess.pnode.max
tcp.src.ports, firewall navigation parameter 33
local node parameter 44, 47
remote node parameter 52 tcp.src.ports.list.iterations, firewall navigation
parameter 33
sess.snode.max
local node parameter 44, 47 TCP/IP Parameters, described 24
remote node parameter 52 TCQ parameters, described 25
sess.total Test mode
local node parameter 44, 47 NDMPXTBL table 79
remote node parameter 52 processing flow 79
Session manager, overview 8 sample scenarios 82

IBM Sterling Connect:Direct for UNIX Administration Guide 95

 Index

Testing mode 79
Testing mode, scenarios 82
Text editor, modifying configuration files 18

U
udp.src.ports, firewall navigation parameter 34
udp.src.ports.list.iterations, firewall navigation
parameter 34
ulimit, copy parameters 26
UNIX, restricted shell 63
User authorization information file
description 9
local user information 55
modifying 53
program directory 63
remote user information 59
remote userid@remote node name 60
userid 53
User exit parameters, described 32
user.exits record 32
userfile.cfg, content and use 53

W
wait.time, CLI/API configuration parameter 36

X
xlate.dir, copy parameter 26
xlate.recv, copy parameter 26
xlate.send, copy parameter 26

96 IBM Sterling Connect:Direct for UNIX Administration Guide

 Notices

This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other
countries. Consult your local IBM representative for information on the products and
services currently available in your area. Any reference to an IBM product, program, or
service is not intended to state or imply that only that IBM product, program, or service may
be used. Any functionally equivalent product, program, or service that does not infringe any
IBM intellectual property right may be used instead. However, it is the user's responsibility
to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in
this document. The furnishing of this document does not grant you any license to these
patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte character set (DBCS) information, contact the
IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
The following paragraph does not apply to the United Kingdom or any other country
where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS
MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,

IBM Sterling Connect:Direct for UNIX Administration Guide 97

 Notices

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do

not allow disclaimer of express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new
editions of the publication. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience
only and do not in any manner serve as an endorsement of those Web sites. The materials
at those Web sites are not part of the materials for this IBM product and use of those Web
sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes
appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of
enabling: (i) the exchange of information between independently created programs and
other programs (including this one) and (ii) the mutual use of the information which has
been exchanged, should contact:
IBM Corporation
J46A/G4
555 Bailey Avenue
San Jose, CA__95141-1003
U.S.A.
Such information may be available, subject to appropriate terms and conditions, including
in some cases, payment of a fee.
The licensed program described in this document and all licensed material available for it
are provided by IBM under terms of the IBM Customer Agreement, IBM International
Program License Agreement or any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment.
Therefore, the results obtained in other operating environments may vary significantly.
Some measurements may have been made on development-level systems and there is no
guarantee that these measurements will be the same on generally available systems.
Furthermore, some measurements may have been estimated through extrapolation. Actual
results may vary. Users of this document should verify the applicable data for their specific
environment.
Information concerning non-IBM products was obtained from the suppliers of those
products, their published announcements or other publicly available sources. IBM has not
tested those products and cannot confirm the accuracy of performance, compatibility or any
other claims related to non-IBM products. Questions on the capabilities of non-IBM
products should be addressed to the suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.

98 IBM Sterling Connect:Direct for UNIX Administration Guide

 Notices

This information is for planning purposes only. The information herein is subject to change
before the products described become available. This information contains examples of
data and reports used in daily business operations. To illustrate them as completely as
possible, the examples include the names of individuals, companies, brands, and products.
All of these names are ficticious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate
programming techniques on various operating platforms. You may copy, modify, and
distribute these sample programs in any form without payment to IBM, for the purposes of
developing, using, marketing or distributing application programs conforming to the
application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions.
IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs. The sample programs are provided "AS IS", without warranty of any kind. IBM
shall not be liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must include a
copyright notice as follows:
IBM 2011. Portions of this code are derived from IBM Corp. Sample Programs.
Copyright IBM Corp. 2011.
If you are viewing this information softcopy, the photographs and color illustrations may
not appear.

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at Copyright and trademark information at
www.ibm.com/legal/copytrade.shtml.
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks
or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
IT Infrastructure Library is a registered trademark of the Central Computer and
Telecommunications Agency which is now part of the Office of Government Commerce.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron,
Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or
both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.

IBM Sterling Connect:Direct for UNIX Administration Guide 99

 Notices

ITIL is a registered trademark, and a registered community trademark of the Office of

Government Commerce, and is registered in the U.S. Patent and Trademark Office.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of
Oracle and/or its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United
States, other countries, or both and is used under license therefrom.
Linear Tape-Open, LTO, the LTO Logo, Ultrium and the Ultrium Logo are trademarks of
HP, IBM Corp. and Quantum in the U.S. and other countries.
Connect Control Center, Connect:Direct, Connect:Enterprise, Gentran,
Gentran:Basic, Gentran:Control, Gentran:Director, Gentran:Plus,
Gentran:Realtime, Gentran:Server, Gentran:Viewpoint, Sterling Commerce,
Sterling Information Broker, and Sterling Integrator are trademarks or registered
trademarks of Sterling Commerce, Inc., an IBM Company.
Other company, product, and service names may be trademarks or service marks of others.

100 IBM Sterling Connect:Direct for UNIX Administration Guide