Connect:Direct for UNIX Overview
Connect:Direct® for UNIX links technologies and moves all types of information between networked systems and computers. It manages high-performance transfers by providing such features as automation, reliability, efficient use of resources, application integration, and ease of use. Connect:Direct for UNIX offers choices in communications protocols, hardware platforms, and operating systems. It provides the flexibility to move information among mainframe systems, midrange systems, desktop systems, and LAN-based workstations.
IBM Sterling Connect Direct for Unix is based on client-server architecture. The Connect:Direct for UNIX server components interact with the user interfaces (API, CLI, IBM® Connect:Direct Browser User Interface, and IBM Control Center) to enable you to submit, execute, and monitor Connect:Direct for UNIX statements and commands.
Process Manager
The Process Manager (PMGR) is the daemon that initializes the Connect:Direct for UNIX server environment. Any application, including End User Applications (EUA), can run on any computer as long as it can connect to the PMGR. The PMGR provides the following functions:
- Initializes Connect:Direct for UNIX
- Accepts connection requests from Connect:Direct for UNIX client APIs and remote nodes
- Creates Command Manager and Session Manager child Processes to communicate with APIs and remote nodes
- Accepts requests from Command Managers and Session Managers when centralized Connect:Direct for UNIX functions are required
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 for UNIX operation. You must define enough file descriptors to handle the number of concurrent Connect:Direct for UNIX sessions allowed, which can be as many as 999.
The CMGR provides the following functions:
- Executes commands sent by the API and sends the results back to the API
- Carries out the Connect:Direct for UNIX authentication procedure, in conjunction with the API, to determine access to Connect:Direct for UNIX
- Interacts with the PMGR when executing commands
Session Manager
The Session Manager (SMGR) is created and invoked by the PMGR when resources are available and either a Process is ready to run or a remote node requests a connection with a local node. The SMGR provides the following functions:
- Performs the necessary Connect:Direct for UNIX work
- Acts as a primary node (PNODE) and initiates Process execution
- Acts as a secondary node (SNODE) to participate in a Process initiated by the PNODE
When an SMGR is created to execute a Process submitted to a node, it creates the connection to the remote node. If the SMGR is started by the PMGR to execute local Processes, the SMGR runs each Process on this session until all Processes are completed.
If an SMGR is created because a remote node initiated a connection, the SMGR completes the connection. If the SMGR is started by the PMGR to execute remote Processes, the SMGR executes remote Process steps supplied by the remote SMGR until the remote SMGR completes all of its Processes.
The SMGR depends on the PMGR for Transmission Control Queue (TCQ) services and other centralized services.
User Authorization
Connect:Direct for UNIX can authorize local and remote users to perform certain Connect:Direct for UNIX tasks. In order to use Connect:Direct for UNIX, each user must have a record defined in the user authorization file, called userfile.cfg. Each local user must have a record in the user authorization file, and remote users may be mapped to a local user ID in a proxy relationship.
To provide a method of preventing an ordinary user from gaining root access through 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 for UNIX is denied to all users.
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 for UNIX facilities are available to enable Process recovery:
- Process step restart—As 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 retry—Two 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 restart—This feature is available with the copy statement.
Checkpoint restart can be explicitly configured within a copy step through the ckpt parameter. If it is not configured in the copy step, it can be configured in the Initparms through the ckpt.interval parameter.
- Run Task restart—If a Process is interrupted when a run task on an SNODE step is executing,
Connect:Direct for UNIX attempts to synchronize the previous run task step on the SNODE with the current run task step. Synchronization occurs in one of the following ways:
- 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 for UNIX reads the restart parameter in the run task step or the initialization parameters file to determine whether to perform the run task step again. The restart parameter on the run task step overrides the setting in the initialization parameter.
For example, if the SNODE loses the run task step results due to a Connect:Direct for UNIX cold restart, Connect:Direct for UNIX checks the value defined in the restart parameter to determine whether to perform the run task again.
Run task restart works differently when Connect:Direct for UNIX runs behind a connection load balancer.
- Interruption of Process activity when the SNODE is a
Connect:Direct for UNIX node—When 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. 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 for UNIX provides sample Processes and shell scripts in d_dir/ndm/src, where d_dir indicates the destination directory of the Connect:Direct for UNIX software. You can create similar files with a text editor. In addition, instructions for creating sample Processes and shell scripts are in the README file in the same directory.
The following list displays the file names of sample Processes and the type. Modify the Processes as required.
- cpunx.cd
copy
- rtunx.cd
run task
- rjunx.cd
run job
- sbunx.cd
submit
The following table displays the 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 |
staterestore.sh | restore statistics files that have been archived |
lcu.sh | launch the Local Connection Utility tool |
spadmin.sh | launch the Secure+ Admin Tool |
spcli.sh | launch the Secure+ CLI |
spcust_sample1.sh | configure Secure+ for the SSL or TLS protocol |
- apicheck.c - Submits a Process to copy a file to a remote system. MAXDELAY is used in this example, which means that the program will not finish execution until the file has been transferred. A standard c compiler is used to compile this module.
- apicheck.C - Same as apicheck.c, except that it is compiled with one of the C++ compilers listed in the Connect:Direct for UNIX User 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 User Guide.
- exit_sample.c - This is the same program as the skeleton user exit program, except that the security exit is demonstrated with code that approximates PassTicket functionality.
Configuration Files
Connect:Direct for UNIX creates the following configuration files during installation and customization. These files are required for the Connect:Direct for UNIX server to operate correctly.
- 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 file
Contains the local user information and remote user information record 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 for UNIX is denied to all users.
- Network map file
Describes the local node and other Connect:Direct for UNIX nodes in the network. You can define a remote node record for each node that Connect:Direct for UNIX communicates with.
- Server authentication key file
Verifies client API connection requests. Only verified clients are granted a connection.
- Client configuration file
Identifies the port and host name used by a client to connect to Connect:Direct for UNIX.
- Client authentication key file
Identifies Connect:Direct for UNIX servers that a Connect:Direct for UNIX client connects to. You can have multiple entries for multiple servers.