Admin Guide 40

Connect:Direct
for UNIX
Administration Guide
Version 4.0
Connect:Direct for UNIX Administration Guide
Version 4.0
Second Edition
(c) Copyright 1999-2009 Sterling Commerce, Inc. All rights reserved. Additional copyright information is located in the release notes.
STERLING COMMERCE SOFTWARE
***TRADE SECRET NOTICE***
THE CONNECT:DIRECT SOFTWARE (STERLING COMMERCE SOFTWARE) IS THE CONFIDENTIAL AND TRADE SECRET
PROPERTY OF STERLING COMMERCE, INC., ITS AFFILIATED COMPANIES OR ITS OR THEIR LICENSORS, AND IS PROVIDED
UNDER THE TERMS OF A LICENSE AGREEMENT. NO DUPLICATION OR DISCLOSURE WITHOUT PRIOR WRITTEN PERMISSION.
RESTRICTED RIGHTS.
This documentation, the Sterling Commerce Software it describes, and the information and know-how they contain constitute the proprietary,
confidential and valuable trade secret information of Sterling Commerce, Inc., its affiliated companies or its or their licensors, and may not be used
for any unauthorized purpose, or disclosed to others without the prior written permission of the applicable Sterling Commerce entity. This
documentation and the Sterling Commerce Software that it describes have been provided pursuant to a license agreement that contains prohibitions
against and/or restrictions on their copying, modification and use. Duplication, in whole or in part, if and when permitted, shall bear this notice and
the Sterling Commerce, Inc. copyright notice. As and when provided to any governmental entity, government contractor or subcontractor subject
to the FARs, this documentation is provided with RESTRICTED RIGHTS under Title 48 52.227-19. Further, as and when provided to any
governmental entity, government contractor or subcontractor subject to DFARs, this documentation and the Sterling Commerce Software it
describes are provided pursuant to the customary Sterling Commerce license, as described in Title 48 CFR 227-7202 with respect to commercial
software and commercial software documentation.
These terms of use shall be governed by the laws of the State of Ohio, USA, without regard to its conflict of laws provisions. If you are accessing
the Sterling Commerce Software under an executed agreement, then nothing in these terms and conditions supersedes or modifies the executed
agreement.
Where any of the Sterling Commerce Software or Third Party Software is used, duplicated or disclosed by or to the United States government or a
government contractor or subcontractor, it is provided with RESTRICTED RIGHTS as defined in Title 48 CFR 52.227-19 and is subject to the
following: Title 48 CFR 2.101, 52.227-19, 227.7201 through 227.7202-4, FAR 52.227-14, and FAR 52.227-19(c)(1-2) and (6/87), and where
applicable, the customary Sterling Commerce license, as described in Title 48 CFR 227-7202 with respect to commercial software and commercial
software documentation including DFAR 252.227-7013, DFAR 252,227-7014, DFAR 252.227-7015 and DFAR 252.227-7018, all as applicable.
The Sterling Commerce Software and the related documentation are licensed either AS IS or with a limited warranty, as described in the Sterling
Commerce license agreement. Other than any limited warranties provided, NO OTHER WARRANTY IS EXPRESSED AND NONE SHALL BE
IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR USE OR FOR A PARTICULAR PURPOSE.
The applicable Sterling Commerce entity reserves the right to revise this publication from time to time and to make changes in the content hereof
without the obligation to notify any person or entity of such revisions or changes.
Connect:Direct is a registered trademark of Sterling Commerce. Connect:Enterprise is a registered trademark of Sterling Commerce, U.S. Patent
Number 5,734,820. All Third Party Software names are trademarks or registered trademarks of their respective companies. All other brand or
product names are trademarks or registered trademarks of their respective companies.
Sterling Commerce, Inc.

4600 Lakehurst Court Dublin, OH 43016-2000 *
614/793-7000
CDUNXAG902
Contents
Chapter 1 About Connect:Direct for UNIX 7
Server Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Process Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Command Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Session Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
File Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Connect:Direct Secure+ Option for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Applications Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Command Line Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Sterling Control Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Connect:Direct Browser User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Connect:Direct Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Local and Remote Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Transmission Control Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Network Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
User Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Process Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Archive Statistics Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Sample Processes, Shell Scripts, and API Programs. . . . . . . . . . . . . . . . . . . . . 17
Connect:Direct for UNIX Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Connect:Direct for UNIX Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Connect:Direct for UNIX Directory Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Connect:Direct for UNIX Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2 Maintaining Configuration Files 25
About the Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Modifying Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Connect:Direct for UNIX Administration Guide 3

Contents
Chapter 3 Maintaining the Initialization Parameters File 27
About the Initialization Parameters File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Updating Miscellaneous Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Updating the Path Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Updating the SNODE Work Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Updating the Node Name Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Updating the PAM Service Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Updating the Quiesce/Resume Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Updating the Priority Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Updating the License Management Key Record. . . . . . . . . . . . . . . . . . . . . . . . . 31
Restricting the Use of Special Characters in the Run Directory . . . . . . . . . . . . . 31
Updating the Remote Node Connection Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Updating the TCQ Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Adding and Updating the Secure+ Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Updating the Global Copy Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Updating the Global Run Task Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Updating the Statistics File Information Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Updating the Server Authentication Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Updating the User Exit Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Updating the Firewall Navigation Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapter 4 Maintaining the Client Configuration File 43
About the Client Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Updating the API Configuration Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Updating the CLI Configuration Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Updating the Client Authentication Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 5 Maintaining the Network Map File 47
About the Network Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Sample Network Map Entry for Remote Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Updating the Local Node Connection Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Updating TCP/IP Settings for a Local Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Updating Remote Node Connection Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapter 6 Maintaining Access Information Files 61
User Authorization Information File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Sample User Authorization File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Updating the Local User Information Record Format . . . . . . . . . . . . . . . . . . . . . . . . 63
Updating the Remote User Information Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Updating the Strong Access Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Automatic Detection of Shadow Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Limiting Access to the Program Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Security Exit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4 Connect:Direct for UNIX Administration Guide

Contents
Chapter 7 Maintaining Client and Server Authentication Key Files 73
About Client and Server Authentication Key Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Key File Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Updating Key File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Sample Client Authentication Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
About the Authentication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Server Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Client Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Appendix A Configuring Firewall Navigation 77
Implementing Firewall Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Firewall Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
TCP Firewall Navigation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
UDT Firewall Navigation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Firewall Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
TCP Firewall Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
UDT Firewall Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Blocking Outbound Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Session Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
TCP Session Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
UDT Session Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Appendix B Specifying IP Addresses, Host Names, and Ports 83
IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Host Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Multiple Addresses, Host Names, and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using Masks for IP Address Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C Using Connect:Direct for UNIX in a Test Mode 87
Processing Flow of the Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Preparing the NDMPXTBL Parameter Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Sample Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Glossary 93
Index 99

Contents

Chapter 1
About Connect:Direct for UNIX
Connect:Direct 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. Connect:Direct 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.
Connect:Direct is based on client-server architecture. The Connect:Direct server components
interact with the user interfaces (API, CLI, Connect:Direct Browser User Interface, and Sterling
Control Center) to enable you to submit, execute, and monitor Connect:Direct statements and
commands.
Server Components
Connect:Direct has the following server components:
Process Manager
The Process Manager (PMGR) is the daemon that initializes the Connect:Direct server
environment. The PMGR provides the following functions:
Initializes Connect:Direct
Accepts connection requests from Connect:Direct 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
Connect:Direct functions are required
Stops Connect:Direct
Note: Any application, including End User Applications (EUA), can run on any computer as long as it can
connect to the PMGR.

Chapter 1 About 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 Connect:Direct operation. You must define enough
file descriptors to handle the number of concurrent Connect:Direct 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 Connect:Direct authentication procedure, in conjunction with the API, to
determine access to Connect:Direct
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 Connect:Direct 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 13 for an overview of the
TCQ.
File Agent
Connect:Direct File Agent is a feature of Connect:Direct, which provides unattended file
management. File Agent monitors watched directories to detect new files. When File Agent detects
a new file, it either submits a default Process or evaluates the file using rules to override the default
Process and to determine which Process to submit. You create rules to submit different Processes
based on the following properties:
Specific or partial file names
File size
System events
You create the Processes used by File Agent on Connect:Direct; you cannot create them using File
Agent.

User Interfaces
To achieve optimum performance, configure File Agent to communicate with the Connect:Direct
node where it is installed. File Agent can be installed on UNIX, Windows, and z/OS operating
systems. For information to help you plan how to implement File Agent, see the Managing Files
with Connect:Direct File Agent chapter in your Connect:Direct administration guide or getting
started guide. The Connect:Direct File Agent Help contains instructions for configuring File Agent.
Connect:Direct Secure+ Option for UNIX

The Connect:Direct Secure+ Option application provides enhanced security for Connect:Direct and
is available as a separate component. It uses cryptography to secure data during transmission. You
select the security protocol to use with Secure+ Option.
To use Connect:Direct Secure+ Option for communications with remote nodes, you must have node
records in the Secure+ Option parameters file that duplicate the adjacent node records in the
Connect:Direct network map. You can populate the Secure+ Option parameters file from entries
defined in an existing network map. For more information about creating the Connect:Direct
Secure+ Option parameters file and configuring nodes for Secure+ Option, refer to the
Connect:Direct Secure+ Option for UNIX Implementation Guide.
User Interfaces
Connect:Direct has the following user interfaces, which enable you to create, submit, and monitor
Processes.
Applications Programming Interface

The UNIX Applications Programming Interface (API) enables you to write programs that work
with Connect:Direct. Several API functions are provided to allow an End User Application (EUA)
to perform the following tasks:
Establish an API connection to the Connect:Direct server
Terminate an API connection to the Connect:Direct server
Send a command to Connect:Direct
Receive responses from commands
Command Line Interface

The Command Line Interface (CLI) enables you to perform the following tasks:
Issue Connect:Direct commands
Monitor Processes
The default CLI command prompt is direct >. Refer to the Controlling and Monitoring Processes
chapter in the Connect:Direct for UNIX Users Guide for additional information about the CLI.

Sterling Control Center

Sterling Control Center is a centralized management system that provides operations personnel with
continuous enterprise-wide business activity monitoring capabilities for Connect:Direct for z/OS,
UNIX, Windows, HP NonStop, and i5OS servers; Connect:Direct Select; and Connect:Enterprise
for UNIX and Connect:Enterprise for z/OS servers; and Gentran Integration Suite (GIS). Sterling
Control Center enables you to:
Manage multiple servers
Group individual servers into server groups for a single view of system-wide activity
View status and statistics on active or completed processing
Suspend, release, stop, and delete Connect:Direct Processes on z/OS, UNIX, Windows,
Select, and HP NonStop platforms
Stop Connect:Direct servers on z/OS, Windows, HP NonStop,i5OS, and UNIX platforms.
Monitor service levels
View active and completed processes across the servers within your network
Receive notification of data delivery events that occur or do not occur as scheduled
Define 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), run a system command, or issue a server
command
Monitor for alerts, such as a server failure or a Process not starting on time

User Interfaces
Create service level criteria (SLCs) that define processing schedules, monitor Processes,
files within Processes, and file transfers for compliance with these schedules, and generate
alerts when the schedules are not met
Analyze key operational metrics
Create customized reports to document and analyze processing activity based on criteria you
define
Validate user authenticity for console-to-engine connections using one or more of four
authentication methods, inclusing password validation, host name identification, Windows
doman, and TCP/IP address (or three methods in the case of the Web console, which does not
support domain authentication)
Identify additional Connect:Direct servers that may need to be monitored based on
communications with a currently monitored server
Sterling Control Center enhances operational productivity and improves the quality of service by:
Ensuring that critical processing windows are met
Reducing impact on downstream processing by verifying that expected processing occurs
Providing proactive notification for at-risk business processes
Consolidating information for throughput analysis, capacity planning, post-processing
operational or security audits, and workload analysis
Reducing the risk of errors associated with manual system administration, including
eliminating individual server logon to view activity, and the need to separately configure each
server for error and exception notifications
Sterling Control Center is available for purchase as a separate product. Contact your Sterling
Commerce representative to learn more about Sterling Control Center.
Connect:Direct Browser User Interface

Connect:Direct Browser User Interface allows you to build, submit, and monitor Connect:Direct
Processes from an Internet browser, such as Microsoft Internet Explorer.
You can also perform Connect:Direct system administration tasks, such as viewing and changing
the network map or initialization parameters, from Connect:Direct Browser. The specific
administration tasks that you can perform depend on the Connect:Direct platform that your browser
is signed on to and your security level.
Connect:Direct Browser is distributed on CD-ROM with Connect:Direct for z/OS, Connect:Direct
for Windows, Connect:Direct for UNIX, and Connect:Direct for HP NonStop. It can also be
downloaded from the Sterling Commerce Web site. Connect:Direct Browser is installed on a Web

server and can be accessed by administrators and users through a URL. The following example
shows the page used to graphically build a Process:
To learn more about Connect:Direct Browser, see the documentation on the Connect:Direct
Browser CD-ROM or available online from the Sterling Commerce Documentation Library.
Connect:Direct Concepts
This section introduces concepts and definitions to help you understand system operations.
Local and Remote Nodes

Each data transfer involves a local and a remote node. The two servers (local and remote) function
together to perform the work. Either Connect:Direct node can initiate the work.
Local and remote node connections are set up in the network map file. Refer to the Maintaining the
Network Map File chapter in the Connect:Direct for UNIX Administration Guide for a description
of the network map file.
Connect:Direct must be installed on each node. When Connect:Direct establishes a session between
the local node and remote node, the node that initiates the session has primary control (PNODE).
The other serves as the partner and has a secondary function (SNODE). The node that initiates the
session has primary control, regardless of the direction of information flow. The Process can specify
work destined for either the local or remote node. When Connect:Direct establishes a session, the
two nodes work together to transfer the information.
Processes
The Connect:Direct Process language provides instructions for transferring files, running programs,
submitting jobs on the adjacent node, and altering the sequence of Process step execution. You can
include one or more steps in a Process. A Process consists of a Process definition statement (Process
statement) and one or more additional statements. Parameters further qualify Process instructions.

The following table lists Process statements and their functions:
Process Statement Function
copy Copies files from one node to another.
conditionals Alters the sequence of Process execution based on the completion code of
previous steps with the if, then, else, eif (end if), goto, and exit
statements.
process Defines general Process characteristics.
run job Enables you to specify UNIX commands in a Process. The Process does
not wait until the job has finished running before executing the next step in
the Process.
run task Enables you to specify UNIX commands in a Process. The Process waits
until the job has finished running before executing the next step in the
Process.
submit Starts another Connect:Direct Process to either the local or remote node
during execution of a Process.
pend Marks the end of a Connect:Direct for UNIX Process.
Following is a sample Process:
ckpt01 process snode=unix.node

step01 copy from (
file=file1
snode
)
ckpt=1M
to (
file=file2
disp=new
pnode
)
pend;
Refer to the Connect:Direct Processes Web site at

http://www.sterlingcommerce.com/documentation/processes/processhome.html for instructions on
building a Process.
Transmission Control Queue

The Transmission Control Queue (TCQ) controls when Processes run. Connect:Direct stores
submitted Processes in the TCQ. The TCQ is divided into four logical queues: Execution, Wait,
Timer, and Hold. Processes are run from the Execution queue.
Connect:Direct places a Process in the appropriate queue based on Process statement parameters,
such as the hold, retain, and startt parameters.

Connect:Direct runs Processes based on their priority and when the Process is placed in the
Execution queue. Processes will run first based on their submitted date, and higher priority
Processes are selected for execution ahead of Processes with a lower priority. You can access the
queues and manage the Processes through Connect:Direct commands.
Refer to the Connect:Direct for UNIX Users Guide for more information on scheduling Processes
in the TCQ.
Commands
You use Connect:Direct commands to submit Processes to the TCQ. You can also use
Connect:Direct commands to perform the following tasks:
Manage Processes in the queue
Monitor and trace Process execution
Produce reports on Process activities
Stop Connect:Direct operation
The following table lists the commands and their functions:
Command Function
change process Changes the status and modifies specific characteristics of a nonexecuting
Process in the TCQ.
delete process Removes a nonexecuting Process from the TCQ.
flush process Removes an executing Process from the TCQ.
trace Runs Connect:Direct traces.
select process Displays or prints information about a Process in the TCQ.
select statistics Displays or prints statistics in the statistics log.
stop Stops Connect:Direct operation.
submit Submits a Process for execution.
For example, the following command submits the Process called onestep to the TCQ with a hold
status of yes:
Direct> submit file=onestep hold=yes;
Network Map
During the transfer of data, the Connect:Direct server where the Process is submitted is the primary
node and the secondary node is the remote node (partner). Connect:Direct identifies the remote
nodes that the local node is able to communicate with through the use Connect:Direct network map
(or netmap).

The network map includes the names of all the remote nodes that the Connect:Direct local node can
communicate with, the paths to contact those remote nodes, and characteristics of the sessions for
communication.
The remote Connect:Direct nodes also have network maps for their remote nodes. The following
sample displays the corresponding network map entries of UNIX-Dallas, z/OS-Miami, and
UNIX-Houston:
Connect:Direct for UNIX

UNIX-Dallas
Remote Nodes:
z/OS-Miami
UNIX-Houston
Connect:Direct for z/OS Connect:Direct for UNIX

z/OS-Miami UNIX-Houston
Remote Nodes: Remote Nodes:

UNIX-Dallas UNIX-Dallas
. .
. .
. .
User Authorization
Connect:Direct can authorize local and remote users to perform certain Connect:Direct tasks. In
order to use Connect:Direct, 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
Connect:Direct for UNIX, a second access file called the Strong Access Control (SACL) file is
created when you install 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
Connect:Direct for UNIX. If the SACL file is deleted or corrupted, access to Connect:Direct 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 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 Connect:Direct 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 Connect:Direct 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
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,
Connect:Direct 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:
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, Connect:Direct 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 Connect:Direct cold restart,
Connect:Direct checks the value defined in the restart parameter to determine whether to
perform the run task again.
Note: Run task restart works differently when Connect:Direct for UNIX runs behind a connection
load balancer. For more information on the considerations you need to know when running
Connect:Direct for UNIX in a load balancing environment, see the Connect:Direct for UNIX
for UNIX Release Notes, Connect:Direct for UNIX for UNIX Administration Guide, and the
Connect:Direct for UNIX Getting Started Guide.
Interruption of Process activity when the SNODE is a Connect:Direct for UNIX nodeWhen
the SNODE is a 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 Connect:Direct for UNIX Users 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

Connect:Direct for UNIX provides a utility to archive and purge statistics files. When you configure
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.
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

Connect:Direct provides sample Processes and shell scripts in d_dir/ndm/src, where d_dir indicates
the destination directory of the Connect:Direct 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+ Option Admin Tool
spcli.sh launch the Secure+ Option CLI (SPCLI)
spcust_sample1.sh configure Secure+ Option for the STS protocol
spcust_sample2.sh configure Secure+ Option for the STS protocol
spcust_sample3.sh configure Secure+ Option 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.

Connect:Direct for UNIX Files
Program Name Description
apicheck.C Same as apicheck.c, except that it is compiled with one of the C++
compilers listed in the Connect:Direct for UNIX Users Guide.
exit_skeleton.c This program is a skeleton of a user exit program that works in

conjunction with 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 Connect:Direct for UNIX Users 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
Connect:Direct for UNIX.

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

Connect:Direct for UNIX creates the following configuration files during installation and
customization. These files are required for the Connect:Direct server to operate correctly.
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 Connect:Direct for UNIX and allows, denies, or
limits root access control. This file is created when you install
Connect:Direct for UNIX. If the file is deleted or corrupted, access to
Connect:Direct is denied to all users.
Network map file Describes the local node and other Connect:Direct nodes in the network.
You can define a remote node record for each node that Connect:Direct
for UNIX communicates with.

Configuration File Description
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
Connect:Direct.
Client authentication key file Identifies Connect:Direct servers that a Connect:Direct client connects
to. You can have multiple entries for multiple servers.
Connect:Direct for UNIX Directory Structure

The following figure illustrates the 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 Connect:Direct 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 Connect:Direct node name.

Note: The secure+ directory is available only when Secure+ Option is purchased and 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 diskfree.so
ndmauths cliapi
initparm.cfg hostid.sh
ndmauthc snmpflst1.0
apnotify netmap.cfg
userfile.cfg cfg.convert
cdcustrpt spcust_sample1.sh
cdsacomp msgfile.cfg
msgfile.idx spcust_sample2.sh
cdstatm spcust_sample3.sh
cfgcheck license.key
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)

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/
work/
ndm/
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
Connect:Direct for UNIX Documentation

See Connect:Direct for UNIX Release Notes for a complete list of the product documentation.
About This Guide

The Connect:Direct for UNIX Administration Guide is for programmers and network operations
staff who maintain 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.

Connect:Direct for UNIX Documentation
Task Overview
The following table guides you to the information required to perform Connect:Direct for UNIX
tasks:
Task Reference
Understanding Connect:Direct for UNIX Chapter 1, About Connect:Direct for UNIX
Using unattended file management for Chapter 2, Managing Files with Connect:Direct File
Connect:Direct Agent
Working with Connect:Direct configuration files Chapter 2, Maintaining Configuration Files
Controlling system settings using initialization Chapter 3, Maintaining the Initialization Parameters
parameters File
Editing parameters that affect End User Chapter 4, Maintaining the Client Configuration File
Applications (EUA)
Specifying connectivity information for the local Chapter 5, Maintaining the Network Map File
node and the remote nodes in the network
Controlling access to Connect:Direct for UNIX Chapter 6, Maintaining Access Information Files
Maintaining client/server security using Chapter 7, Maintaining Client and Server

authentication keys Authentication Key Files
Enabling a test mode for production instances of Appendix C, Using Connect:Direct for UNIX in a Test
Connect:Direct for UNIX Mode


Chapter 2
Maintaining Configuration Files
Configuration files define the operating environment for 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 26, 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

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
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
4 asset.protection:\ License keyfile

5 keyfile=${CDUNIX_PATH}/ndm/cfg/main_node/license.key:
6 #Local 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 Connect:Direct configuration files using any text editor or create a new
configuration file using the cdcust command provided with Connect:Direct for UNIX.
Modifying Configuration Files with a Text EditorYou can modify 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 Connect:Direct for UNIX path name:
$ d_dir/etc/cdcust

Chapter 3
Maintaining the Initialization Parameters File
Initialization parameters determine various Connect:Direct settings that control system operation.
The initialization parameters file is created when you install Connect:Direct for UNIX and can be
updated as needed.
You can modify Connect:Direct initialization parameters file using any text editor. Before changing
a value in the file, first shut down the 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 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 Connect:Direct Browser to perform some of the procedures in this chapter. To
learn more about the Connect:Direct Browser, see the documentation on the Connect:Direct
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 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
Connect:Direct for UNIX node; the location of Connect:Direct for UNIX, the Pluggable
Authentication Modules (PAM) service configuration file, the shared work area for SNODE
work files, and the license management key file; 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.
Transmission Control Queue (TCQ) informationThe tcq record defines how long a Process
is held in error before being deleted.

Chapter 3 Maintaining the Initialization Parameters File
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:
asset.protection:keyfile=/sci/users/mscarbro/cd3800/ndm/cfg/mws_joshua_4000/license
.key:
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:

Updating Miscellaneous Parameters
# Global runtask parameters.

runtask.parms:\
:restart=y:
# Stat file info.

stats:\
:file.size=1048576:\
:log.commands=n:\
:log.select=n:\
:snmp.agent.port=1365:\
:snmp.agent.activated=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:

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 Connect:Direct files. The following table describes the
parameter available for this record:
Parameter Description Value
path The path to all Connect:Direct subdirectories and files. path specification

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:
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 Connect:Direct node. The following table
describes the parameter available for this record:
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 Connect:Direct Processes. If the service initialization parameter is defined and if PAM
is installed on the Connect:Direct for UNIX server, PAM is used to authenticate users for
service-providing applications. The following table describes the parameter available for this
record:
service PAM service configuration file name. File name

Updating the Quiesce/Resume Record

The ndm.quiesce record specifies whether Connect:Direct for UNIX 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 Connect:Direct for UNIX in a Test Mode.
The following table describes the parameter available for this record:
quiesce.resume Enables/disables the test mode for Connect:Direct y|n

for UNIX. 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:
default The default value of the Process priority. 115. The default value is 10.
15 is the highest priority.
Updating the License Management Key Record

The asset.protection record identifies the name and location of the license management key file.
The following table describes the parameter available for this record:
keyfile The license management key file. name and location of the key
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 63 and

Updating the Remote User Information Record on page 67. 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.
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:
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. 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.

Updating the TCQ Record
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
Updating the TCQ Record

The tcq record provides information pertaining to the Transmission Control Queue. The following
parameter is available for this record:
max.age The maximum number of days a A 3-digit decimal number. Connect:Direct

Process with Held-in-Error status does not automatically delete Processes
remains in the TCQ before it is when max.age=0.
automatically deleted. The default is 8 days.
Adding and Updating the Secure+ Record

The secure+ record provides information pertaining to remote configuration of Secure+ Option
from the 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:
certificate.directory Specifies a default certificate Directory path name

directory for Secure+ Option
commands issued from the
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+ Option y|n

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

The Global Copy record called copy.parms provides default information for the 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.

Updating the Global Copy Record
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.
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.

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
iIgnores the setting defined
in the .Local node record and
uses the settings for
strip.blanks as determined by
the default value of the remote
node type as follows:
z/OS, VM, VSE, and
i5OSy
All other platformsn

Updating the Global Run Task Record
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, Connect:Direct attempts to synchronize the previous run task step on the SNODE with
the current run task step. If synchronization fails, Connect:Direct reads the restart parameter to
determine whether to perform the run task step again. The following parameter is available for this
record:
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, 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.
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:
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 Connect:Direct creates a statistics y|n

record when a select process or select statistics yA statistics record is
command is executed. created.
nA statistics record is not
created. The default is n.
snmp.agent.port The SNMP agent monitoring port number. This The default is 1365.
number must match the port number listed in the
SNMP agent initialization file.
snmp.agent.activated Notifies the server if an SNMP agent is active. y|n

yNotifies the server.
nDoes not notify the
server. The default is n.
syslog.logd Enables Connect:Direct to send license Available values are:

management failure messages to the UNIX syslogd kernKernel
daemon. Refer to manual pages for instructions on
userUser level
configuring syslog.
mailMail subsystems
daemonSystem daemons
authSecurity or
authorization
syslogsyslogd daemon
lprLine-printer subsystem
newsNews subsystem
uucpuucp subsystem
The default value is
daemon.
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, 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.
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

Updating the Server Authentication Record
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:
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.
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:
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
Connect:Direct to use the
security exit, when it is acting in
the role of the SNODE. After
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
Connect:Direct is the PNODE.
sec_exit_onlyCauses
Connect:Direct to always use
the security exit. After
Connect:Direct receives a valid
message, it evaluates the proxy
and the secure point-of-entry to
establish the local user.
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 Connect:Direct sessions. These ports also need to be open on the firewall of the trading
partner to allow the inbound Connect:Direct sessions. This feature enables controlled access to a
Connect:Direct server if it is behind a packet-filtering firewall without compromising security
policies.

Updating the Firewall Navigation Record
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:
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 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.
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 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.

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:
Connect:Direct API configuration parameters
Connect:Direct CLI configuration parameters
Client authentication parameters
You can modify 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 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:

Chapter 4 Maintaining the Client Configuration File
Updating the API Configuration Record

The 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:
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:
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.

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

Chapter 4 Maintaining the Client Configuration File

Chapter 5
Maintaining the Network Map File
This chapter describes the parameters in the network map file. This file is created when you install
Connect:Direct for UNIX. 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 Connect:Direct Browser to perform some of the procedures in this chapter. To
learn more about the Connect:Direct Browser, see the documentation on the Connect:Direct
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 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.

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. Connect:Direct uses 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.
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 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.

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 Connect:Direct Name

administrator or operator.
contact.phone The phone number of the Connect:Direct Phone number

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 a Connect:Direct session to
nSpecifies that none of
be established. The comm.info record can
these security checks are
be the official network name, an alias name
made.
listed in the appropriate file (for example,
/etc/hosts, if the system is not running NIS The default value is n.
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.

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
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
else /*snodeid is NOT specified */
if submitter@PNODE found in userfile.cfg
security OK
else

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
Connect:Direct sessions allowed, which
can be as many as 999.
If sess.total exceeds the number of
sessions in the APS license key file, the
license key file silently overrides this value.
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 a Connect:Direct CLI/API. default is 32768 bytes.

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 Connect:Direct host
IP address where Connect:Direct is computer.
running. The port identifies the
IP addressis the IP address
communications port for Connect:Direct for
of a machine running
UNIX. Multiple host name/IP addresses
Connect:Direct:
and port combinations can be specified
when they are separated by a comma. This nnn.nnn.nnn.nnn (IPv4) or
parameter is required. nnnn:nnnn:nnnn:nnnn:nnnn:n
nnn:nnnn:nnnn (IPv6)
portidentifies the
communications port for
Connect:Direct for UNIX. 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
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.

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:
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.
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 Connect:Direct When set to 0, wait time is
attempts to re-establish a session with unlimited unless limited by the
the remote node. operating system.

Updating TCP/IP Settings for a Local Node
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 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
The value for this parameter has no
effect on LU6.2 connections.

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
:
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
: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 Connect:Direct/Plex, this list IP addressthe IP address of a
should include the address of machine running Connect:Direct in
each Connect:Direct/Server with IPv4 or IPv6 format:
a different IP address from the nnn.nnn.nnn.nnn (IPv4) or
Connect:Direct/Plex Manager.If nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nn
the IP address of the initiating nn:nnnn (IPv6)
node does not match the IP For example:
address specified on the
comm.info parameter, the :alternate.comminfo=10.23.107.5
alternate.comminfo parameter :alternate.comminfo=fe00:0:0:2014::7
is checked for other valid IP Specify multiple addresses/host
addresses. names by separating them with a
For more information on comma (,). A space can be added
specifying IP addresses and after the comma for readability. For
host names, see Appendix example:
B, Specifying IP Addresses, 10.23.107.5, fe00:0:0:2014::7,
Host Names, and Ports. msdallas-dt
*Accepts any IP address. This
turns off IP address validation.
Note: Partial pattern matches are
not supported, such as:
*.mydomain.com,
myplex??.mydomain.com.

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.

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
Connect:Direct node uses to
profile name, up to 8 characters.
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.
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.

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 Connect:Direct Name

contact.phone The phone number of the Phone number

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
The value for this parameter has
no effect on LU6.2 connections.

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.
If sess.total exceeds the number
of sessions in the APS license
key file, the license key file
silently overrides this value.
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.

Chapter 6
Maintaining Access Information Files
You can control access to Connect:Direct for UNIX 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 Connect:Direct for UNIX and use 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 Connect:Direct.
Connect:Direct may optionally use remote user information records to translate remote user IDs to
valid local user IDs where Connect:Direct for UNIX is installed. If an snodeid parameter is not
coded on the incoming Process, Connect:Direct for UNIX uses this proxy relationship to determine
the rights of remote users to issue Connect:Direct commands and statements.
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.

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:

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

all users.

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

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

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

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

statistics command. yAllows the user to issue the
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 Sterling Control yAllows the user to issue
Center or Java API, to configure Secure+ commands. The default is y.
Option.
Note: This parameter has no effect on commands.
local tools, such as spadmin.sh and
spcli.sh.

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

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

command. yAllows the user to issue the
command.
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.
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.
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.

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 Connect:Direct for UNIX Directory path name
is 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 31.

Updating the Remote User Information Record
pstmt.runjob Specifies whether the user can issue the run y|n
job statement. yAllows the user to issue the
statement.
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.
pstmt.submit Specifies whether the user can issue the y|n

submit statement. yAllows the user to issue the
statement.
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.

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.

Note: To prevent the remote user from using 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:
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
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.

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 31.
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.
pstmt.runtask Specifies whether the user can issue the y|n

run task statement. yAllows a user to issue the
statement.
pstmt.submit Specifies whether the user can issue the y|n

submit statement. yAllows a user to issue the
statement.
descrip Permits you to add descriptive notes to Text string

the record.

Updating the Strong Access Control File

To provide a method of preventing an ordinary user from gaining root access through
Connect:Direct for UNIX, 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
Connect:Direct for UNIX. If you want to give an ordinary root user access through 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 Connect:Direct for UNIX, the sysacl.cfg file
must exist. If the file is deleted or corrupted, all users are denied access to 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 Connect:Direct for UNIX. this parameter is required. The following values can be
specified for the root:deny.access parameter:
deny.access Allows, denies, or limits root access to y|n|d

Connect:Direct for UNIX 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,
Connect:Direct for UNIX detects the use of shadow passwords automatically, if available.
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

Security Exit
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.


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

Connect:Direct client/server security depends on a key, similar to a password, in a 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] ] ]

Chapter 7 Maintaining Client and Server Authentication Key Files
Updating Key File Parameters

The following table describes the available key file parameters:
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.

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
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
* MRLN SIMP keyany API3 MRLN SIMP key33
* MRLN SIMP keyany
API D SERVER D
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 Connect:Direct authentication procedure determines if the user is authorized to access the
system.
The goal of 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 from

Chapter 7 Maintaining Client and Server Authentication Key Files
the 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.

Appendix A
Configuring Firewall Navigation
Firewall navigation enables controlled access to a 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 Connect:Direct
sessions.
Before you configure source ports in the 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 Connect:Direct for UNIX:
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 Connect:Direct for UNIX 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 Connect:Direct node to
communicate with the remote 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 remote ports. Firewall

Appendix A Configuring Firewall Navigation
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
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
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
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

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 80 for a discussion of the differences between UDT and TCP
session establishment.
TCP Firewall Configuration Example

The 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:
PNODE session request Outbound 20002200 3364
SNODE session Inbound 2264 30003300
UDT Firewall Configuration Example

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

Based on this scenario, the firewall rules for the local node are the following:
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 Connect:Direct.
TCP Session Establishment

A Connect:Direct TCP client contacts a Connect:Direct TCP server on its listening port. The
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 Connect:Direct scans the list is
specified using the tcp.src.ports.list.iterations initialization parameter. If Connect:Direct finds an
available port, communication with the remote node proceeds.
UDT Session Establishment

When a Connect:Direct UDT client contacts a 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

Session Establishment
client attempts to contact the server on the session port. The 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 Connect:Direct scans the list is specified using the
udp.src.ports.list.iterations initialization parameter. If the Connect:Direct client finds an available
port, communication with the remote Connect:Direct server proceeds. If a session cannot be
established after a certain time interval, the server atempts to contact the client.


Appendix B
Specifying IP Addresses, Host Names, and

Ports
Connect:Direct for UNIX 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 Connect:Direct for UNIX, use the following
guidelines.
IP Addresses
Connect:Direct for UNIX accepts both IPv4 and IPv6 addresses. Wherever an IP address is
specified in Connect:Direct for UNIX, 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
Connect:Direct for Unix Administration Guide 83

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, Connect:Direct for UNIX 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.
84 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 Connect:Direct for
UNIX 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. Connect:Direct for UNIX 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)
Connect:Direct for Unix Administration Guide 85

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.
86 Connect:Direct for Unix Administration Guide

Appendix C
Using Connect:Direct for UNIX in a Test Mode
You can enable a test mode for production instances of Connect:Direct for UNIX 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
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 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 Connect:Direct submitter ID and submitter node combination

Appendix C Using Connect:Direct for UNIX in a Test Mode
In addition to telling 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 90.
When the testing mode is enabled, Connect:Direct for UNIX performs a syntax check on the
parameter table and fails initialization if the table is invalid. If the table is valid, Connect:Direct for
UNIX 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 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
Connect:Direct for UNIX. 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 31.
Note: If you enable the quiesce.resume initialization parameter, you must have an NDMPXTBL parameter
table.

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

Connect:Direct submitter ID and submitter node a specific ID and node combination.
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.

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 Connect:Direct Processes to run and not run.
Specifying Which Processes Run

In this example, 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

Sample Test Scenarios
Specifying Which Processes to Exclude

In this example, 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, 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 Connect:Direct submitter ID from node DI0049
The specific 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


Glossary
Application Programming Interface (API)

A library of function calls that enables End User Applications (EUAs) to interact with the
Connect:Direct software.
Client
A program that makes requests of the Connect:Direct server and accepts the servers responses.
Command Line Interface (CLI)

A program available to submit 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 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.
Connect:Direct
The family of data transfer software products that distributes information and manages production
activities among multiple data centers.
Connect:Direct Browser User Interface

As an alternative to submitting Connect:Direct commands through the command line interface, you
can use the Connect:Direct Browser User Interface to create, submit, and monitor Processes from
an Internet browser, such as Microsoft Internet Explorer or Netscape Navigator. You can also use

Glossary
the Connect:Direct Browser to perform Connect:Direct system administration tasks, such as

viewing and changing the network map or initialization parameters, if you have the appropriate
Connect:Direct authority.
Connect:Direct for UNIX

The UNIX implementation of the Connect:Direct product.
Connect:Direct Node
Any computer/workstation running Connect:Direct.
Connect:Direct Process
A series of statements, which can be predefined and stored in a directory, submitted through the API
to initiate Connect:Direct for UNIX activity. Examples of Process functions are copying files
and running jobs.
daemon
The long-running process that provides a service to a client. The PMGR is the Connect:Direct for
UNIX daemon.
Diagnostic Commands
Connect:Direct commands that assist in the diagnosis of 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 Connect:Direct node or it can be waiting for a connection to the remote
Connect:Direct node before it can perform its tasks.

Glossary
File Agent
An application program and component of Connect:Direct. It scans specified directories searching
for the presence of a file. When a file appears in a watched directory, Connect:Direct either
submits a Process or performs the action specified by the rules for the file.
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.
Monitoring Commands
Connect:Direct commands that allow you to display information from the statistics file and the TCQ
about Connect:Direct Process execution results.
Operational Control Commands

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
Connect:Direct.
Process Manager (PMGR)

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

Glossary
PNODE (Primary Node)

The 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.
Session
A connection between two Connect:Direct nodes.
Session Manager (SMGR)

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

The 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 Control Center

A centralized management system that provides operations personnel with continuous
enterprise-wide business activity monitoring capabilities for Connect:Direct z/OS, UNIX, and
Windows servers. It manages multiple Connect:Direct servers to suspend, release, and delete
Processes, stops Connect:Direct servers, and views detailed statistics on running or completed
Processes. It monitors service levels to view Connect:Direct processing across Connect:Direct
z/OS, UNIX, and 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 Connect:Direct when the Process is placed on the TCQ.
The status of a Process can be examined with a select process command.

Glossary
TCQ (Transmission Control Queue)

A queue that holds all Processes that are submitted to 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.
Wait Queue
A logical queue in the TCQ. Processes on the Wait Queue are waiting on a connection to or from
the remote Connect:Direct node.

Glossary

Index
A cmd.chgproc, Local User Information Record 63

cmd.delproc, Local User Information record 63
About the initialization parameters file 27
cmd.flsproc, Local User Information Record 64
admin.auth, Local User Information Record 63
cmd.selproc, Local User Information Record 64
alt.comm.outbound, remote connection parameter 57
cmd.selstats, Local User Information Record 64
API configuration parameters, listed 44
cmd.stopndm, Local User Information Record 64
API, description 9
cmd.submit, Local User Information Record 65
api.max.connects, local node connection parameter 49
cmd.trace, Local User Information Record 65
api.parms record 44
CMGR, description 8
asset.protection record 31
comm.bufsize
Authentication parameters, described 39
remote node parameter 57
Authentication record 45
comm.info, remote node connection parameter 32, 58
C comm.transport
LU 6.2 parameter 33, 58
cdcust script, modifying configuration files 26 remote node connection information 58
remote node connection parameter 33
ckpt.interval, copy parameters 34
CLI configuration parameter, listed 44
Command
CLI, description 9 change process 14
CLI/API Configuration file delete process 14
client.keyfile 45 flush process 14
client.program 45 for TCQ 14
location 43 select process 14
tcp.hostname 44 select statistics 14
tcp.port 44 stop 14
wait.time 44 submit 14
trace 14
Client and server authentication key files, about 73
Command line interface, overview 9
Client authentication key file
authentication parameters 76 Command manager, overview 8
overview 73 Configuration
permissions 76 files, modifying 26, 43
Client authentication parameters, listed 45 initialization parameters file 27
network map parameters 47
Client configuration file, defined 43 user authorization parameters 61
client.keyfile, CLI/API configuration parameter 45 conn.retry.ltattempts
client.program, CLI/API configuration parameter 45 local node parameter 49, 54

Index
conn.retry.ltwait
local node parameter 49, 54
E
remote node parameter 59 ecz.compression.level, copy parameters 35
conn.retry.stattempts ecz.memory.level, copy parameter 35
local node parameter 49, 54 ecz.windowsize, copy parameters 35
conn.retry.stwait
F
remote node parameter 58 file.open.exit.program, user exit parameter 40
Connect:Direct file.size, file information parameters 37
client authentication parameters 76 Files
concepts 12 client authentication key file 73
configuration overview 25 initialization parameters, modifying 27
security 73 server authentication key file 73
security, authentication procedure 75 strong access control file 70
server authentication parameters 76 user authorization information file, modifying 61
contact.name Firewall navigation parameters, described 40
remote node parameter 59 firewall.parms record 40
contact.phone
local node parameter 50, 55 G
remote node parameter 59 Generic, host name in server configuration file 74
continue.on.exception, copy parameter 35
Copy parameters, described 34 H
copy.parms record 34 Host names
multiple 85
CRC checking 36, 60, 65, 67
specifying 84
D I
default, priority parameter 31
Initialization parameters file
Definition about 27
local node 12 authentication 39
remote node 12 ckpt.interval 34
descrip comm.info 32
local node parameter 50, 55 comm.transport 33, 58
Local User Information Record 65 copy.parms 34
remote node parameter 59 defined 27
Remote User Information Record 69 ecz.compression.level 35
ecz.memory.level 35
Description ecz.windowsize 35
API 9 file.open.exit.program 40
CLI 9 file.size 37
CMGR 8 local.node 48
network map 14 location 27
PMGR 7 log.commands 37
SMGR 8 log.select 38
TCQ 13 max.age 33
user authorization 15 modifying 27

Index
ndm.pam 30
path parameter 29
L
priority record 31 License management messages 38
recid 32 Local node
restrict definition of 12
cmd 66, 69 in network map 14
retry.codes 35
retry.msgids 36 Local User Information Record
rnode.listen 32 about 63
runtask.parms 37 admin.auth 63
security.exit.program 40 cmd.chgproc 63
server.keyfile 39 cmd.delproc 63
server.program 39 cmd.flsproc 64
snmp.agent.activated 38 cmd.selproc 64
snmp.agent.port 38 cmd.selstats 64
stats.exit.program 39 cmd.stopndm 64
syslog.logd 38 cmd.submit 65
tcp.crc 36 cmd.trace 65
tcp.crc.override 36 descrip 65
tcp.src.ports 41, 77 name 65
tcp.src.ports.list.iterations 41, 42, 77 phone 65
TCQ 33 pstmt.copy 65, 68
ulimit 34 pstmt.copy.ulimit 65
xlate.dir 34 pstmt.crc 65, 67
xlate.recv 35 pstmt.download_dir 66, 69
xlate.send 34 pstmt.runjob 67, 69
pstmt.runtask 67, 69
IP address pstmt.submit 67, 69
masks 85 pstmt.submit_dir 67
IP address ranges, using masks 85 pstmt.upload 66, 68
pstmt.upload_dir 66, 68
IP addresses 83
snode.ovrd 67
IPv4 83
IPv6 83 local.id, Remote User Information Record 68
multiple 85 local.node, initialization parameter record 48
IPv4 83 log.commands, file information parameter 37
IPv4 addresses 83 log.select, file information parameters 38
IPv6 83
IPv6 addresses 83 M
guidelines 83
max.age, parameter 17
max.age, TCQ parameter 33
K
Modifying configuration files 26
Key files
overview 73
permissions required for the client 76 N
permissions required for the server 76 name
keyfile parameter, in asset.protection record 31 parameter, in ndm.node record 30
name, in Local User Information Record 65
ndm.node record 30

Index
ndm.path record 29 phone, Local User Information Record 65

ndm.pam record 30
PMGR, description 7
snode.work.path parameter 30
Port numbers
NDMPXTBL parameter table 88
specifying 85
NDMPXTBL table 87
Ports
netmap.check, local node parameter 50 multiple 85
Network map file proc.prio record 31
comm.bufsize 57
Process restart, overview 15
comm.info parameter 58
conn.retry.ltattempts 49, 54, 59 Process statements, listed 13
conn.retry.ltwait 49, 54, 59 Process, samples 17
conn.retry.stattempts 49, 54
conn.retry.stwait 49, 54, 58 profile name, LU 6.2 parameter 32, 58
contact.name 50, 55, 59 Program directory, about 70
contact.phone 50, 55, 59
proxy.attempt, local node parameter 51
descrip 50, 55, 59
description 14 pstmt.copy, Local User Information Record 65, 68
location 47 pstmt.copy.ulimit, Local User Information Record 65
modifying 47
netmap.check 50 pstmt.crc, Local User Information Record 65, 67
pacing.send.count 51, 56, 59 pstmt.download
pacing.send.delay 51, 55, 59 Local User Information 66, 68
proxy.attempt 51
pstmt.download_dir
runstep.max.time.to.wait 52, 55, 60
Local User Information Record 66, 69
sess.default 52, 55
sess.pnode.max 52, 55, 60 pstmt.run_dir
sess.snode.max 52, 55, 60 local user information record 66
sess.total 52, 55, 60 remote user information record 69
tcp.api 53 pstmt.runjob, Local User Information Record 67, 69
tcp.api.bufsize 52
tcp.crc 60 pstmt.runtask, Local User Information Record 67, 69
tcp.ip.default 54 pstmt.submit, Local User Information Record 67, 69
tcp.max.time.to.wait 53, 54
pstmt.submit_dir
Local User Information Record 67
P Remote User Information Record 69
pacing.send.count pstmt.upload
local node parameter 51 Local User Information Record 66, 68
remote node parameter 59 pstmt.upload_dir
tcp/ip settings for local node parameter 56 Local User Information Record 66, 68
pacing.send.delay
Q
quiesce and resume, testing mode 87
path parameter, for ndm.path record 29
quiesce.resume
Permissions
test mode 87
required for the client 76
required for the server 76

Index
R S
recid, remote node connection parameter 32 Samples
Processes 17
Record
shell scripts 18
api.parms 44
authentication 39 Security
copy.parms 34 authentication procedure 75
firewall.parms 40 client authentication parameters 76
local user information 63 format for key files 73
ndm.node 30 program directory 70
ndm.path 29 server authentication parameters 76
remote user information 67
Security Exit, in the Initialization parameters file 70
remote userid@remote node name 68
runtask.parms 37 security.exit.program, user exit parameter 40
stats 37 Server authentication key file, authentication
tcp.ip.default 54 parameters 76
tcq 33
Server authentication parameters
user.exits 39
described 39
Record, authentication 45 overview 73
Remote node permissions 76
definition of 12 server.keyfile, server authentication parameter 39
in network map 14
server.program, server authentication parameter 39
Remote node information record
sess.default, local node parameter 52, 55
creating 19
modifying 47 sess.pnode.max
Remote User Information Record
about 67
descrip 69 sess.snode.max
local.id 68 local node parameter 52, 55
pstmt.run_dir 69 remote node parameter 60
pstmt.submit_dir 69 sess.total
remote userid@remote node name, user authorization local node parameter 52, 55
information record 68 remote node parameter 60
restart, run task parameter 37 Session manager, overview 8
restrict Shadow password detection 70
cmd initialization parameter 66
Shell script, samples 18
cmd, initialization parameter 69
SMGR, description 8
Restricted shell, about 71
snmp.agent.activated, file information parameter 38
retry.codes, copy parameter 35
snmp.agent.port, file information parameter 38
retry.msgids, copy parameter 36
snode.ovrd, Local User Information Record 67
rnode.listen record 32
snode.work.path parameter 30
Run task, parameters 37
Statistics file information, parameters 37
runstep.max.time.to.wait
local node parameter 52, 55 stats record 37
remote node parameter 60 stats.exit.program, user exit parameter 39

Index
Sterling Control Center 10 User authorization information file

description 15
strip.blanks parameter 36
local user information 63
Strong Access Control File 70 modifying 61
sysacl.cfg, strong access control 70 program directory 70
remote user information 67
syslog.logd, file information parameter 38 remote userid@remote node name 68
userid 61
T User exit parameters, described 39
tcp.api, local node parameter 53 user.exits record 39
tcp.api.bufsize, local node parameter 52 userfile.cfg, content and use 61
tcp.api.inactivity.timeout, local node parameter 53
tcp.crc W
copy parameter 36 wait.time, CLI/API configuration parameter 44
tcp.crc.override, copy parameter 36
X
tcp.hostname CLI/API configuration parameter 44
xlate.dir, copy parameter 34
tcp.ip.default, initialization parameter record 54
xlate.recv, copy parameter 35
tcp.max.time.to.wait, local node parameter 53, 54
xlate.send, copy parameter 34
tcp.port, CLI/API configuration parameter 44
tcp.src.ports, firewall navigation parameter 41
tcp.src.ports.list.iterations, firewall navigation
parameter 41
TCP/IP Parameters, described 32
TCQ parameters, described 33
TCQ, description 13
Test mode
NDMPXTBL table 87
processing flow 87
sample scenarios 90
Testing mode 87
Testing mode, scenarios 90
Text editor, modifying configuration files 26
U
udp.src.ports, firewall navigation parameter 41
udp.src.ports.list.iterations, firewall navigation
parameter 42
ulimit, copy parameters 34
UNIX, restricted shell 71

Admin Guide 40

Uploaded by

Copyright:

Available Formats

Admin Guide 40

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Admin Guide 40

Uploaded by

Copyright:

Available Formats

Connect:Direct

Sterling Commerce, Inc.

Chapter 1 About Connect:Direct for UNIX 7

Chapter 2 Maintaining Configuration Files 25

About the Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Connect:Direct for UNIX Administration Guide 3

Chapter 3 Maintaining the Initialization Parameters File 27

About the Initialization Parameters File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 4 Maintaining the Client Configuration File 43

About the Client Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 5 Maintaining the Network Map File 47

About the Network Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 6 Maintaining Access Information Files 61

User Authorization Information File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4 Connect:Direct for UNIX Administration Guide

Chapter 7 Maintaining Client and Server Authentication Key Files 73

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

Appendix A Configuring Firewall Navigation 77

Implementing Firewall Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

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

Appendix C Using Connect:Direct for UNIX in a Test Mode 87

Processing Flow of the Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Connect:Direct for UNIX Administration Guide 5

6 Connect:Direct for UNIX Administration Guide

About Connect:Direct for UNIX

Connect:Direct for UNIX Administration Guide 7

8 Connect:Direct for UNIX Administration Guide

Connect:Direct Secure+ Option for UNIX

Applications Programming Interface

Command Line Interface

Connect:Direct for UNIX Administration Guide 9

Sterling Control Center

10 Connect:Direct for UNIX Administration Guide

Connect:Direct Browser User Interface

Connect:Direct for UNIX Administration Guide 11

Local and Remote Nodes

12 Connect:Direct for UNIX Administration Guide

The following table lists Process statements and their functions:

Process Statement Function

copy Copies files from one node to another.

process Defines general Process characteristics.

pend Marks the end of a Connect:Direct for UNIX Process.

Following is a sample Process:

ckpt01 process snode=unix.node

Refer to the Connect:Direct Processes Web site at

Transmission Control Queue

Connect:Direct for UNIX Administration Guide 13

delete process Removes a nonexecuting Process from the TCQ.

flush process Removes an executing Process from the TCQ.

trace Runs Connect:Direct traces.

select process Displays or prints information about a Process in the TCQ.

select statistics Displays or prints statistics in the statistics log.

stop Stops Connect:Direct operation.

submit Submits a Process for execution.

Direct> submit file=onestep hold=yes;

14 Connect:Direct for UNIX Administration Guide

Connect:Direct for UNIX

Connect:Direct for z/OS Connect:Direct for UNIX

Remote Nodes: Remote Nodes:

Connect:Direct for UNIX Administration Guide 15