Use Connect:Direct in Test Mode

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.

You can enable test mode for production instances of Connect:Direct® for Microsoft Windows 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

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 /Server/samples directory.
Note: You can modify the quiesce.resume initialization parameter while the server is active.
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

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 in this section.

When the testing mode is enabled, Connect:Direct for Microsoft Windows performs a syntax check on the parameter table and fails initialization if the table is invalid. If the table is valid, Connect:Direct for Microsoft Windows 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).