Using IBM Connect:Direct in a test mode

Edit online

You can enable a test mode for production instances of IBM® Connect:Direct® to perform the following functions:

  • Test new applications and customer connections
  • Prevent future production work from executing until testing is complete after you have terminated all active production work using the Flush Process command
  • Resume regular production work after testing
  • Control individual file transfers by application
  • Enable and disable individual nodes and applications

While testing is being conducted, only Processes, particularly file transfers, involved with the testing activity are executed. No production data is transferred to applications being tested while at the same time no test data is transferred to production applications.

Processing Flow of the Test Mode

Edit online

You enable the testing mode using the quiesce.resume initialization parameter and specify which IBM 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 IBM 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 IBM Connect:Direct submitter ID and submitter node combination

In addition to telling IBM 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.

When the testing mode is enabled, IBM Connect:Direct performs a syntax check on the parameter table and fails initialization if the table is invalid. If the table is valid, IBM Connect:Direct scans it looking for a pattern that matches the Process that is about to execute. If a match is found, the Process is permitted to execute if the “I” (Include) command code is in effect. If command code “X” (Exclude) is in effect, the process is not permitted to execute. If a match is not found in the table, the opposite processing occurs from the case where a match is found, that is, if no match is found and command code “I” is in effect, the Process is not permitted to execute, whereas if command code “X” is in effect, the Process is permitted to execute.

If a Process is not permitted to execute, the disposition specified in the NDMPXTBL parameter table to either hold, retry, or flush the Process is implemented and a non-zero return code is returned. When a Process is prevented from executing in testing mode, appropriate messages are issued and can be viewed in the statistics log.

For Processes initiated on remote nodes, the testing mode functions in the same manner as it does for Processes submitted on the local IBM 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

Edit online

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

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

NDMPXTBL Parameter Table

Edit online

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 Code Description Subparameters/Examples
* Comment line. * Only run the following Processes.
E Enables execution of Processes based on table entries. Either “E” or “D” must be the first non-comment entry in the table. The second column in this entry must contain one of the following values which indicates the disposition of a PNODE Process if it is not allowed to run.

H—Places the Process in the Hold queue

R—Places the Process in the Timer queue in session retry

F—Flushes the Process from the queue
D Disables the execution of all Processes regardless of the contents of the parameter table and fails Process execution with a non-zero (error) return code and message LPRX003E. Either “E” or “D” must be the first non-comment entry in the table The parameter for command code “E” can also be specified in column two. This is a convenience to make it easier to change from “E” to “D” and vice versa without having to change column two to a blank for command code “D.”
P Matches Processes based on a full or partial Process name. Supports the wild card trailing asterisk (*). Can be used to enable or disable Process execution for a particular application by using naming conventions to match an application. PCOPY—Matches a single Process

PACH*—Matches all Processes beginning with “ACH”

P*—Matches all Processes
N Matches Processes based on a full or partial remote node name. Supports the wild card trailing asterisk (*). NCD.NODE1—Matches a single 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 IBM Connect:Direct submitter ID and submitter node combination. The format is <id>@<node>. SACTQ0ACD@TPM002—Matches a specific ID and node combination.

S*@TPM002—Matches 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.
I Includes Processes for execution that match the patterns in the table which follow this command code. Either “I” or “X” must be the second non-comment entry in the table. Processes which do not match a pattern in the table are not executed.
Note: To choose which command code to use to select Processes, determine which group is smaller and use the corresponding command Code. For example, if the 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.
 ER

I

NCD.BOSTON


Includes Processes for execution on the CD.BOSTON node only. Processes destined for all other remote nodes are placed in the Timer queue in session retry
X Excludes from execution those Processes that match the patterns in the table which follow this command code. Either “X” or “I” must be the second non-comment entry in the table. Processes which do not match a pattern in the table are executed. EH

X

SDALLASOPS@*


Excludes Processes for execution submitted by the ID DALLASOPS from any node
L Last entry in table.  

Sample Test Scenarios

Edit online

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

Specifying Which Processes Run

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

Specifying Which Processes to Exclude

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