# Connect:Direct configuration

## Sharing folders between Data Mover and the Connect:Direct node

When Data Mover and the Connect:Direct Node reside on different machines, the first and most important step is to correctly manage shared folders between them. Connect:Direct sends and receives files based on folder policies and the cdp script must contain a direct reference to the filesystems.

To configure the Data Mover Steng for the Connect:Direct server, follow these steps:

1. If the Connect:Direct server is remote, mount shared filesystems to exchange files.
2. Go to `${STENG_HOME}/cfg` and configure the `speng.cd.pathremap.table` file as described in the **Remapping shared folders** section below.&#x20;
3. Copy the Connect:Direct API library (CDJAI.jar) in this folder: `${STENG_HOME}/lib/cd`.

{% hint style="warning" %}
Once the installation and the configuration are completed, **restart the STENG before starting the server**!
{% endhint %}

### **Remapping shared folders**

To remap shared folders, edit the path remap configuration file `speng.cd.pathremap.table` in the directory `${STENG_HOME}/cfg`.

This configuration file consists of several pairs of folder paths that remap incoming and outgoing files. Below, you can find some examples.

{% hint style="info" %}
Paths may slightly change due to differences between Windows and Unix.
{% endhint %}

{% hint style="danger" %}
You can define a remote path containing a letter, a colon, and a Unix slash. Example: D:/dir1/dir2.
{% endhint %}

```shell
#########
## SpEng Path <----> Local CD Path
## ex:
## C:\share\cd=/home/connect/share/cd
##
## SpEng Path <----> Remote CD Path
## ex:
## /winCdrive/Out/=C:\Out\
#########

# First (incoming files)
C:\CDReceive=Z:\CDReceive

# Second (push files)
Z:\CDShared=C:\CDShared

# Third (pull files)
/winCdrive/Test/Out/=C:\Test\Out\
/masterInDirCd=C:\CDShared
C:/CDShared=Z:\CDShared
```

The first example applies to **incoming files**:

• "**Z:\CDReceive**" is the shared partition defined on the local machine (Data One)\
• "**C:/CDReceive**" is the shared partition on the remote Connect:Direct server

The file received by the Connect:Direct server will be placed in the "**C:/CDReceive**" folder.\
The DataOne\CD connector will be prompted that a new file has arrived.\
In Data One, the file is stored in the "**Z:\CDReceive**" folder, where it is taken and moved in the Data One filesystem.

The second example applies to **push operations**.\
Outgoing files are copied from the Data One filesystem to the shared folder "**Z:\CDShared**". When the DataOne\CD connector submits the “cdp” script to the remote Connect:Direct server, the correct remapped folder "**C:\CDShared**" will be specified in the Connect:Direct server.

The third example applies to **pull operations**.\
For Windows convention, we will use "**/winCdrive**" to indicate the "C:" drive path.\
The first step is to define a valid path for the Connect:Direct machine, for example: "**/winCdrive/Test/Out/SourceFile.txt**"\
and a virtual destination path, for example:\
"**/masterInDirCd/DestFile.txt**".\
Here below, you can find the remapping operations that are executed:

• From **/winCdrive/Test/Out/** to **C:\Test\Out\\** (remapped path to fetch the source file on the C:D remote node)\
• From **/masterInDirCd** to **C:\CDShared** (remapped path where the file is received on the C:D server)\
• From **C:/CDShared** to **Z:\CDShared** (remapped path when the file is received, see first example)

{% hint style="info" %}
If you need to use several Connect:Direct scripts (CDP) to connect with the same actor, you must define one or more REMOTE CONNECTION configurations, each one with the relevant RECEIVE FILE PROCESS TEMPLATE and SEND FILE PROCESS TEMPLATE.
{% endhint %}

### **Disabling shared folders remap on remote paths**

When a contract is defined, the remote path is remapped according to the specifications in the `speng.cd.pathremap.table` file. Remapping is enabled by default on the **remote destination path** (with sppush) or the **source path** (with sppull).

To disable remapping on the remote destination or source path, an advanced setting must be added in Data Mover:

1. Go to **Setup** → **Advanced Settings**.
2. Click the **New** button.
3. Enable the **Click to add a new module/section** toggle button.
4. In the **Module** edit box, enter **STENG**.
5. In the **Section** edit box, enter **mft**.&#x20;
6. In the **Property Name** edit box, enter **connectDirect.enableRemotePathRemap**.
7. In the **Property Value** edit box, enter **FALSE**. The remote destination or source path entered in the contract **is no longer remapped**; the contract path is taken as written.

{% hint style="info" %}
**Remapping is enabled** on the remote destination or source path if the property **is absent or set to TRUE**. This is the default setting.
{% endhint %}

If this property is set to true, you must use these naming conventions to distinguish a Windows network share and support empty paths on z/OS:&#x20;

* Windows network share: /\_WINSHAR&#x45;*\_*/host/dir1&#x20;
  * Example: /\_WINSHAR&#x45;*\_*/host/dir1  (which becomes \\\host\dir1)
* Empty paths on z/OS: /\_EMPTYDI&#x52;*\_*/
  * Esempio /\_EMPTYDI&#x52;*\_*/

## Using DFIC information in CDP template execution

In a Connect:Direct CDP template, you can leverage [DFIC](/data-mover-1.21/workflow-templates/dataflow-instance-context-dfic.md) (Dataflow Instance Context) information to reference the variables:

* use DFIC\_dfiid to retrieve the unique identifier for the [DFIC instance](/data-mover-1.21/workflow-templates/dataflow-instance-context-dfic.md#how-to-use-dfic).
* use DFIC\_SYS\* to retrieve [DFIC system attributes](/data-mover-1.21/workflow-templates/dataflow-instance-context-dfic.md#system-attributes).
* use DFIC\_USR\* to retrieve [DFIC user attributes](/data-mover-1.21/workflow-templates/dataflow-instance-context-dfic.md#user-attributes).

CDP templates are written with the **Freemarker v. 2.3.20 syntax**.&#x20;

Here is the supported syntax:

<table><thead><tr><th width="153.4000244140625">DFIC attribute type</th><th>Syntax</th><th>Example</th><th>Result</th></tr></thead><tbody><tr><td>DFIID</td><td><code>'${DFIC_dfiid!"UNDEFINED"}'</code> </td><td><code>${DFIC_dfiid!"UNDEFINED"}</code> </td><td><code>DFIC_dfiid='d569s44b-091q-512n-056i-1e8t6lw878pr'</code></td></tr><tr><td>DFIC system attributes</td><td><code>'${DFIC_SYS["&#x3C;original_attribute_name>"]!"UNDEFINED"}'</code></td><td><code>${DFIC_SYS["original-filename"]!"UNDEFINED"}</code></td><td><code>ASCII_OToWIN_ffhf8o3f.txt</code></td></tr><tr><td>DFIC user attributes</td><td><code>'${DFIC_USR["&#x3C;user_attribute_name>"]!"UNDEFINED"}'</code><br>where &#x3C;user_attribute_name> is the name of the user attribute you want to retrieve. </td><td><code>${DFIC_USR["user-location"]!"UNDEFINED"}</code></td><td><code>milan-italy</code></td></tr></tbody></table>

## Correct management of Connect:Direct process in status HOLD

When Connect:Direct detects a transfer problem (e.g., an inactive partner), the operation to be performed at the end of the retry attempts is configured in the Connect:Direct `netmap.cfg` file. The operation to be performed can be either to delete or to hold:

* If `delete` is set, the process is deleted, and a record with the identifier PERR is issued in the statistics. Data One intercepts this record and acts accordingly, setting the transfer to FAILED.
* If `hold` is set, the process is not deleted and set to HOLD. Data One intercepts this status and, when the set timeout expires, sets the transfer to FAILED.\
  If a process in HOLD is restarted in Connect:Direct (even after a long time), a mismatch between Connect:Direct and Data One could occur. To avoid the mismatch, a hold timeout can be set in DMCFG ext\_cfg manually (see [How to modify DMCFG and deploy it](/data-mover-1.21/how-to.../...-modify-dmcfg-and-deploy-it.md) for details):
  * `connect.direct.hold.timeout.sec=<seconds>`
  * `connect.direct.hold.delete=true|false`

The addition and tuning of these parameters depend on the client's environment and system policies.

`connect.direct.hold.timeout.sec=<seconds>`\
It sets the number of seconds after which Data One considers a transfer failed.\
Values:

* 0 / not defined / default: wait forever.
* \> 0: seconds after which Data One considers a transfer failed.

`connect.direct.hold.delete=true|false`\
It is evaluated only if `connect.direct.hold.timeout.sec` is set to a value higher than 0.\
Values:

* **true**: when the Connect:Direct process is restarted during the timeout, the Data One transfer will also be restarted. If the timeout expires and the process is still on HOLD, the Data One transfer will be set to FAILED and the Connect:Direct process will be deleted.
* **false (default)**: after the transfer is declared FAILED, the process in Connect:Direct is left in HOLD.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.primeur.com/data-mover-1.21/transfer-protocols-and-connectors/client-connections/client-connection-ibm-sterling-connect-direct/connect-direct-configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
