This form of the BDTNODE statement defines characteristics of the communication sessions between the home node (the node you are at) and remote nodes (nodes at other BDT subsystems). The BDTNODE statement can define a pacing rate, a checkpoint interval, data compression type, the use of automatic session startup and restart, the number of VLUs available, and other characteristics.

This form of the BDTNODE statement may be used for file-to-file or SNA NJE nodes.

How Many Allowed: 1-100 BDTNODE statements (home and remote combined) per initialization stream.

How Many Required: One or more BDTNODE statements are required to define sessions with remote nodes (one BDTNODE statement for each remote file-to-file or SNA NJE node).

Placement: Between the ENDRBAM and ENDINIT statements, before or after the SNABUF and SYSID statements.

N=remote-node-name

specifies a remote file-to-file or SNA NJE node. You must name each remote node that will establish a session with the home node. Users and operators at the home node will use this name to direct commands, file-to-file transactions, and SNA NJE jobs to the remote node. You must use a different name for each remote node. No remote node may have the same name as your home node.

Specified As: One to eight alphanumeric characters, the first of which must be alphabetic.

Default: None.

Related Parameters: For SNA NJE installations, be sure that remote-node-name is the same as the name specified on the NAME parameter of the corresponding JES3 NJERMT statement. Do not use the names ALL, NJE, or FTF.

APPL=lu-name

is the name that VTAM uses for the remote node being defined by this BDTNODE statement.

Specified As: One to eight alphanumeric characters.

Default: None.

Related Parameters: lu-name must match the name (label) of the VTAM CDRSC definition statement at the home node and the name (label) of the VTAM APPL definition statement at the remote node.

[A={YES|NO}]

defines whether BDT at the home node is to automatically start a session with BDT at the remote node named on this statement.

YES

instructs BDT to automatically start a session with the remote node each time the operator at the home node starts BDT and activates the BDT SNA manager.

NO

makes the operator responsible for starting the session.

Default: NO.

[ASR={YES|NO|restart-limit}]

defines whether BDT automatically tries to restart a failed session with the remote node. BDT can try to restart failing sessions with the remote node with the exception of sessions that failed because they were canceled by the BDT CANCEL command, and sessions that could not start because of a negotiable bind disagreement between the home node and the remote node.

YES

requests that BDT try automatic session restart an unlimited number of times.

NO

requests that BDT not attempt automatic session restart.

restart-limit

requests that BDT try automatic restart up to restart-limit number of times before giving up. restart-limit may be a decimal number from 1 to 32767.

Default: YES.

Related Parameters: The ASRTIME parameter of the OPTIONS statement specifies the time delay between restart attempts. This time delay applies to all sessions for which ASR is specified in the BDTNODE statement.

[BUFNO=num-buffs]

defines the pacing rate for communication that takes place between the remote node and the home node.

Each time the home node sends data to a remote node, it does so by sending the data in a data buffer. The home node retains a copy of this buffer until the remote node acknowledges receipt of the buffer. If a node has several VLUs actively sending data, each VLU could have sent one or more buffers for which an acknowledgment has not been received. Each of these buffers will occupy virtual storage until the acknowledgment is received.

The pacing rate defines the maximum number of data buffers that each home node VLU can send to the remote node before the remote node must acknowledge receipt of the buffer. If a VLU has sent the maximum number of buffers without receiving an acknowledgment, the VLU stops sending data buffers. The VLU resumes sending data buffers only after it receives the proper acknowledgment from the remote node.

The pacing rate that you define at your node may be different from the pacing rate defined at the remote node. If this happens, BDT uses the slower pacing rate (the smaller num-buffs value).

When selecting a pacing rate, you must consider the amount of virtual storage required for the buffers versus BDT’s performance. Initially, you should start with a pacing rate of 2 (the default). You should increase this value only if doing so improves the data throughput of BDT.

Specified As: A decimal number from 1 to 255.

Default: 2.

Related Parameters: If num-buffs exceeds the number of buffers specified on the SNABUF statement, BDT abend BD615 could occur. For example, if you defined BUFNO=30 on the BDTNODE statement and PRI=10,SEC=0 on the SNABUF statement, and if the 10 primary buffers were sent with no pacing response, the buffer pool could become exhausted.

File-to-File Consideration: For inbound VLUs, BDT receives and queues up to the value of num-buffs because that is the maximum that can be sent prior to an acknowledgment. For outbound VLUs, BDT allows up to the value of num-buffs+1 SNA buffers to be queued for transmission for each VLU, and transmits up to the value of num-buffs until an acknowledgment is received.

As an example of the requirements for outbound SNA buffers, consider a connection that has five VLUs defined—one control VLU and four data transfer VLUs (two outbound and two inbound)—and BUFNO=3. Then six is the maximum number of SNA buffers that can be sent by each side of the session before receiving acknowledgment from the other side.

A slow receiver generally results in an accumulation of SNA buffers at the receiving side of the session, because the SNA buffers used at the sending side are released when the VTAM SEND completes, not when the BDT acknowledgment is received from the receiving VLU. The SNA buffers at the receiving side remain allocated and in use until the receiving side actually processes the data. Therefore, for the above example, and with a slow receiver, up to 15 SNA buffers may be in use at any given time. This includes up to eight outbound buffers (even though a maximum of six can be sent) as well as six inbound buffers and a control VLU buffer.

SNA NJE Consideration: For SNA NJE nodes, the communication VLU sends and receives data, and half of the data transfer VLUs send data and half receive data. So the total number of SNA buffers this session can use is (((num-buffs/2)+1) x (num-vlus+1)), where num-vlus is the number of VLUs specified on the LU parameter of this BDTNODE statement.

[BUFSZ=buff-size]

defines the data buffer size (in bytes) that is to be used for communication between the remote node and the home node. These buffers are allocated from the pool of buffers that you define on one or more SNABUF statements.

Specified As: A number of bytes. For file-to-file nodes, buff-size may be a decimal number from 0 to 4096. For SNA NJE nodes, buff-size may be a decimal number from 300 to 4096.

Default: 1024.

Related Parameters: buff-size must not exceed the largest SIZE parameter specified on a SNABUF statement. If it does, initialization will terminate.

When selecting a buff-size value, you should match the value to the speed of the communication line. For slow speed lines, use a buff-size value of 512 bytes or less. Increase the size only for high speed lines or if a larger size improves data throughput. A buff-size value that is too large may delay communication traffic and increase the use of virtual storage.

The amount of available space within a SNA buffer where BDT can store data for file transfers is reduced by one byte for each negotiated VLU present on the connection. This space is used to transfer BDT acknowledgments. The negotiated VLU corresponds to the smaller of the two values specified in the LU parameter of the BDTNODE statements for the two nodes in session.

In addition, a small amount of space within the SNA buffer is used for control information on each transfer, and is not available for transferring user file data. The reserved space varies with the logical record size being transferred.

In general, to calculate the amount of space available for transfer of file data within a SNA buffer, reduce the value of buff-size by 3, and subtract one byte for each negotiated VLU and two bytes for each logical record contained within the buffer. The above formula is an average, and the control information may vary somewhat at the start of a file transfer.

For instance, if a given connection has 30 VLUs defined at both nodes, buff-size is 256 bytes, and the length of the logical records is 80, the amount of file transfer data that could fit within each SNA buffer is 217, or 256 – (3+(1x30)) = 223 – (3 logical records x 2) = 217.

Note the following for cross-domain and channel-to-channel transmission:

• For cross-domain transmission: The value obtained by adding buff-size plus the length of the VTAM path information unit (PIU) header must be less than or equal to the value specified on the MAXDATA parameter of the VTAM PCCU macro for the network control program (NCP).

  The computation of (MAXBFRU x UNITSZ), which are the two parameters on the NCP HOST macro, must be equal to or greater than the largest PIU that can flow in the network. Therefore, an installation must ensure that, when specifying these values for the NCP, the product of the two is at least as large as the largest buff-size + space for the TH and RH portions of the PIU, for any connection that may go through that NCP.

  The MAXBFRU and UNITSZ operands on the NCP HOST macro are used in other VTAM parameter calculations (such as IOBUF size and XPANPT for the IOBUF pool). Consult VTAM publications for additional information.

• For channel-to-channel transmission: buff-size must be less than or equal to the value obtained by multiplying the MAXBUFRU parameter on the GROUP statement for a CTC link group times the size of the VTAM I/O buffer.

[CKPT=K-bytes] (file-to-file nodes only)

Periodically, BDT takes a checkpoint of sequential data set transfers. If the transfer fails and has to be restarted, the checkpoint information that BDT records enables BDT to restart the transfer from the last checkpoint. If the checkpoint were not taken, BDT would have to retransfer the entire data set. K-bytes defines how many 1K-byte blocks should be transferred before BDT checkpoints sequential data set transfers. (For a partitioned data set, BDT automatically takes a checkpoint after copying each member. You need not take any action.)

Specified As: A decimal number from 8 to 32767, indicating 1K-byte blocks of uncompressed data before the transfer.

Default: 40.

When you select a checkpoint frequency, try to match the frequency to the speed of the communication link. For slower speed links, you should take checkpoints more frequently than you take them for faster links. Each time BDT takes a checkpoint, communication takes place between the local node and the global node. Therefore, frequent checkpoints on fast links could create excessive communication traffic and adversely affect the performance of the link.

[CS={NJEDUP|REPDUP|(NJEDUP,REPDU P)}] (file-to-file nodes only)

defines the type of data compression, if any, that the home node will allow for file-to-file sessions with the remote node specified on this BDTNODE statement. Data compression removes duplicate strings of characters from data sets to be transferred. The character strings are removed before the data sets are transferred.

NJEDUP

requests compression of 3 to 63 duplicate characters (2 to 63 if the characters are blanks).

REPDUP

requests compression of 3 to 127 duplicate characters.

(NJEDUP,REPDUP)

requests compression of 3 to 127 duplicate characters (2 to 127 if the characters are blanks).

Default: If the CS parameter is not specified, compression does not take place.

The actual compression that takes place is determined by the CS parameter specified at this node, the CS parameter specified at the partner node, and the CSOPT transaction parameter specified by the user, according to the following table.

Table 1. CSOPT Transaction Parameters

CS Parameter Specified at the Home Node	CS Parameter Specified at the Remote Node	CSOPT Transaction Parameter Specified by the User	Compression Used
(NJEDUP,REPDUP)	(NJEDUP,REPDUP)	NJEDUP	NJEDUP
(NJEDUP,REPDUP)	(NJEDUP,REPDUP)	REPDUP	REPDUP
(NJEDUP,REPDUP)	(NJEDUP,REPDUP)	None	None
NJEDUP	(NJEDUP,REPDUP)	NJEDUP	NJEDUP
NJEDUP	(NJEDUP,REPDUP)	REPDUP	None
NJEDUP	(NJEDUP,REPDUP)	None	None
REPDUP	(NJEDUP,REPDUP)	NJEDUP	None
REPDUP	(NJEDUP,REPDUP)	REPDUP	REPDUP
REPDUP	(NJEDUP,REPDUP)	None	None
None	(NJEDUP,REPDUP)	NJEDUP	None
None	(NJEDUP,REPDUP)	REPDUP	None
None	(NJEDUP,REPDUP)	None	None
REPDUP	NJEDUP	NJEDUP	None
REPDUP	NJEDUP	REPDUP	None
REPDUP	NJEDUP	None	None

[L=logmode]

identifies the entry in the logmode table that VTAM is to use when the remote node named on this BDTNODE statement and the home node try to establish a session.

Specified As: One to eight alphanumeric characters. The first character must be alphabetic.

Default: If this parameter is not specified, VTAM uses the first entry from the standard IBM-supplied logmode table.

Related Parameters: Before you code logmode, ensure that the named entry has been defined in the ACF/VTAM logmode table associated with the VTAM APPL definition statement at the node defined by this BDTNODE statement.

[LU=({num-vlus},{fence-from},{fence- to})]

defines the number of virtual logical units (VLUs) that are available for communication between the remote node and the home node. The number of VLUs determine how many concurrent data transfers can take place between the remote node and the home node. This parameter also defines, for file-to-file transfers, how these VLUs are to be fenced.

num-vlus

is the total number of VLUs that are to be available. The first VLU (the communication VLU) always transfers control information. The remaining VLUs transfer data.

For File-to-File Nodes, Specified As: A decimal number from 1 to 255. The first VLU transfers control information and the remaining VLUs (up to 254) transfer data sets.

Default for File-to-File Nodes: 7.

For SNA NJE Nodes, Specified As: 5, 9, 13, 17, 21, 25, or 29. The first VLU transfers control information and the remaining VLUs (up to 28, divided into groups of four) transfer jobs and SYSOUT. Each group has one VLU for handling jobs received, one for jobs sent, one for SYSOUT received, and one for SYSOUT sent. See Table 2 for a summary of SNA NJE VLU allocation.

Default for SNA NJE Nodes: 5.

Table 2. Number of SNA NJE VLUs for Each num-vlus Value

num-vlus Value	Number of Communication VLUs	Number of VLUs for Jobs Received	Number of VLUs for Jobs Sent	Number of VLUs for SYSOUT Received	Number of VLUs for SYSOUT Sent
5	1	1	1	1	1
9	1	2	2	2	2
13	1	3	3	3	3
17	1	4	4	4	4
21	1	5	5	5	5
25	1	6	6	6	6
29	1	7	7	7	7

When you allocate VLUs, keep in mind that:

• It may take only a few active VLUs to saturate the capacity of a communication line.
• If the total number of VLUs active across all sessions is too large, the storage capacity of BDT private virtual storage may be exceeded.
• Transferring a data set that has a large block size uses more private virtual storage than does transferring a data set of a smaller block size.

fence-from (file-to-file nodes only)

fence-to (file-to-file nodes only)

Many file-to-file transactions, each wishing to transfer data in the same direction, could enter the system. These transactions could monopolize the VLUs for some time. During this time, other transactions wishing to transfer data in the other direction would be unable to do so. Whether this situation would ever occur at your node depends on the number and characteristics of the transactions that users submit. You can prevent this situation from happening, however, by fencing VLUs.

Fencing is a way of reserving some VLUs for transactions that will transfer data in a specific direction. You can fence VLUs for transactions that will send data to another node; you can also fence VLUs for transactions that will receive data from another node.

For example, assume that you define nine VLUs and that you fence four in the “from” direction and two in the “to” direction. BDT may pair the four “from” VLUs only with transactions that are to receive data from the remote node and the two “to” VLUs only with transactions that will send data to the remote node. BDT may pair the remaining VLUs with any transaction.

You may fence VLUs only for a remote node that is local with respect to the home node. The remote node is local if this BDTNODE statement does not contain the T=LOCAL parameter.

fence-from defines the number of VLUs that may be used only to receive data from the remote node. fence-to defines the number of VLUs that may be used only to send data to the remote node.

Specified As: Each parameter may be a decimal number from 0 to 254.

Default: 0.

The sum of the values of fence-from and fence-to must be at least 1 less than the value of num-vlus. This is because BDT uses one VLU to pass control information and this VLU is unavailable for data transfers.

[PIN=receive-password]

[POUT=send-password]

For each remote node you may define a pair of passwords. When the home node and the remote node try to establish a session, BDT checks the passwords. If either the home node or the remote node has failed to provide the correct password, BDT will not allow the session.

receive-password is the password that the home node expects to receive from the remote node. send-password is the password that the remote node expects to receive from the home node.

Specified As: Each parameter may be one to eight alphanumeric characters.

Default: A character string of eight blanks (hex 4040404040404040).

[T=LOCAL] (file-to-file nodes only)

defines the global-local relationship between the home file-to-file node and a remote file-to-file node.

The global-local relationship determines which of the two nodes schedules and manages work that takes place between the nodes. Before you decide which node should be global, consider that:

• All transactions are queued and scheduled at the global node.
• The operator at the global node generally needs to be more experienced than the operator at the local node.

A given node may be global in its relationship with one remote node and local in its relationship with a different remote node.

In a JES3 complex, the BDT global-local relationship has no relationship to the JES3 global-local relationship.

See Step 1. Plan Global and Local Relationships (File-to-File Customers Only) for more information.

Specified As: T=LOCAL if the home file-to-file node (the node at which this BDTNODE statement will execute) is local with respect to the remote file-to-file node (the node defined by this BDTNODE statement), code T=LOCAL. If the home file-to-file node is global with respect to the remote file-to-file node, omit this parameter.

Default: If you omit this parameter from a file-to-file initialization stream, the home node is defined as global with respect to this remote node. You should omit this parameter from a SNA NJE initialization stream, although if you specify it will be ignored.

Related Parameters: T=LOCAL and fencing (specified by the LU parameter) cannot be specified on the same BDTNODE statement; fencing is not allowed from a local node to a global node.

You must ensure that you and the system programmer at the remote node define the same global-local relationship. If you define your node as the global node, the system programmer at the remote node must also define your node as the global node; if you define your node as the local node, the other system programmer must do likewise. If you and the other system programmer fail to define the same global-local relationship, the home node and the remote node will be unable to establish a session.

[TYPE={FTF|NJE}]

specifies the type of data transfers that may occur between the home node and the remote node specified on this BDTNODE statement.

FTF

specifies that the home and remote BDT nodes may send and receive only data sets. This parameter corresponds to the BDT File-to-File feature.

NJE

specifies that the home and remote BDT nodes may send and receive only SNA NJE jobs and SYSOUT. This parameter corresponds to the BDT SNA NJE feature for JES3 installations.

Default: FTF.