Global Copy Parameters
The global copy parameters define default information for the copy operation, such as the number of bytes transmitted in a copy operation before a checkpoint is taken.
See the IBM® Connect:Direct® Process Language Reference Guide for a description of the copy Process statement.
Parameter Name | Description | Valid Values | Restart Required |
---|---|---|---|
ckpt.interval |
The default checkpoint interval used. The interval is the number of bytes transmitted before a checkpoint is taken. The maximum possible value is gigabytes. |
no | bytesK | bytesM The default is 10240K bytes. |
No |
xlate.dir |
The default directory containing the translation table. The default is the XLATE subdirectory where Connect:Direct is installed. |
Valid, fully qualified path name. The default is X:\installation directory\XLATE. |
No |
xlate.send |
The name of the default translation table to use when sending data to a remote node. |
Valid name for the send translation table. The default is XLATESND.CDX |
No |
xlate.recv |
The name of the default translation table to use when copying data from a remote node. |
Valid name for the receive translation table. The default is XLATERCV.CDX |
No |
disable.cache |
Enables or disables the Microsoft Windows file cache. |
Y | N The default is N. |
No |
continue.on.exception |
Specifies whether a Process attempts to continue processing or goes into HOLD status if an abnormal termination occurs during a Connect:Direct session. Y—Attempt to continue processing. N—Go into HOLD status. |
Y | N The default is N. |
No |
ecz.cmprlevel |
The compression level to use. Level 1 is the fastest method and offers the least degree of compression. Level 9 provides the greatest degree of compression and is the slowest method. |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 The default is 1. |
No |
ecz.windowsize |
The size of the compression window or history buffer. The greater the window size, the greater the degree of compression, and the greater the amount of virtual memory used. |
9 | 10 | 11 | 12 | 13 | 14 | 15 The default is 15. |
No |
ecz.memlevel |
The amount of virtual memory allocated to maintain the internal compression rate. Memory level 1 uses the least amount of memory, but slows processing and reduces the degree of compression. |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 The default is 4. |
No |
strip.blanks |
Determines whether trailing blank characters at the end of each record are removed from a line of text before it is written to the Microsoft Windows text file or ignored (I). The strip.blanks parameter is ignored when datatype(binary) is specified. |
Y | N | I The default is I. |
No |
record.wrap |
Note: This parameter is needed only in certain circumstances because it restructures the
data.
Influences the way that a sending copy step works when a logical record size (LRECL) is specified for the remote platform. If record.wrap is set to N, and a record length greater than LRECL is encountered in the source file, Connect:Direct for Microsoft Windows reports an error. This is the desired behavior in most cases. If record.wrap is set to Y, and a record length greater than LRECL is encountered in the source file, the record is broken into records of length at most LRECLs before being sent to the remote node. |
Y | N The default is N. |
No |
retry.msgids |
The message IDs to use to support a file allocation retry attempt. 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. |
Any of the valid file allocation retry messages. |
No |
retry.codes |
The codes to recognize as a file allocation retry 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. |
Any valid error code |
No |