Examples of Using DNI

Because of the flexible nature of DNI, it can be used in many ways. Your environment dictates how DNI can be most effectively used at your site. The following examples show how the platform server DNI can be used in some different scenarios.

Defining DNI for Each Node in Binary and Text Transfers

In this example, you have to define text and binary transfers for each remote platform server system. When a transfer is completed, it is renamed to indicate whether it works or fails.

Sample DNI definitions are as follows:

NODE1TXT 

REQUEST=SEND                  
DSN=PRODDNI.NODE1TXT.**
REMOTE_FILE=C:\PRODDNI\%NOHLQ 
TYPE=TEXT                     
IPNAME=NYOFFICE
TRY=5                         
FAIL_ACTION=RENAME            
FAIL_NEWDSN=%Q01.FAIL.%NOHLQ  
GOOD_ACTION=RENAME            
GOOD_NEWDSN=%Q01.GOOD.%NOHLQ

NODE1BIN 

REQUEST=SEND                  
DSN=PRODDNI.NODE1BIN.**
REMOTE_FILE=C:\PRODDNI\%NOHLQ 
TYPE=BINARY                     
IPNAME=NYOFFICE
TRY=5                         
FAIL_ACTION=RENAME            
FAIL_NEWDSN=%Q01.FAIL.%NOHLQ  
GOOD_ACTION=RENAME            
GOOD_NEWDSN=%Q01.GOOD.%NOHLQ

If you have twenty different remote platform server systems, you may have to create forty different DNI definitions (twenty for text and twenty for binary).

Using the %NODE and %IPNAME Substitutable Parameters

In this example, you have to define text and binary transfers for the platform server system. Take special care when creating file names because components of the file name will be used as the platform server node name or IP name.

When a transfer is completed, it is renamed to indicate whether it works or fails.

Note: When using this method, you must utilize the platform server user profiles to define the remote user ID and password combination.

Sample DNI definitions are as follows: 

TEXT
----
REQUEST=SEND                  
DSN=PRODDNI.%NODE.TEXT
REMOTE_FILE=C:\PRODDNI\%NOHLQ 
TYPE=TEXT                     
NODE=XXX
TRY=5                         
FAIL_ACTION=RENAME            
FAIL_NEWDSN=%Q01.FAIL.%NOHLQ  
GOOD_ACTION=RENAME            
GOOD_NEWDSN=%Q01.GOOD.%NOHLQ  
	
BINARY
------
REQUEST=SEND                  
DSN=PRODDNI.%NODE.BINARY
REMOTE_FILE=C:\PRODDNI\%NOHLQ 
TYPE=BINARY                     
NODE=XXX
TRY=5                         
FAIL_ACTION=RENAME            
FAIL_NEWDSN=%Q01.FAIL.%NOHLQ  
GOOD_ACTION=RENAME            
GOOD_NEWDSN=%Q01.GOOD.%NOHLQ

These two definitions support an unlimited number of remote platform server partners. The second qualifier of the data set name is used as the platform server node name. This node name must be configured as a platform server node. See TIBCO Managed File Transfer Platform Server for z/OS Installation and Operation Guide for more information on configuring platform server NODE definitions.

In this example, you can substitute the %IPNAME parameter for the %NODE parameter. If you use the %IPNAME parameter, you do not have to create any platform server NODE definitions.

Using the Email Related Parameters

Some transfer requests require an action to be performed when data is sent to a remote location. Using the EMAIL_FAIL and EMAIL_GOOD parameters, you can send a message to two different email addresses, based on whether the request is successful or unsuccessful.

Sample DNI definitions are as follows: 

TEXT
----
	REQUEST=SEND                  
	DSN=PRODDNI.ABC.COMPANY.DATA
	REMOTE_FILE=C:\PRODDNI\%NOHLQ 
	TYPE=TEXT                     
	IPNAME=ABC.COMPANY.COM
	TRY=5                         
	FAIL_ACTION=RENAME            
	FAIL_NEWDSN=%Q01.FAIL.%NOHLQ  
	GOOD_ACTION=RENAME            
	GOOD_NEWDSN=%Q01.GOOD.%NOHLQ  
	EMAIL_GOOD=theiruser@abc.company.com
	EMAIL_FAIL=techsup@mycompany.com

In this example, if the request is successful, the data set PRODDNI.ABC.COMPANY.DATA will be renamed to PRODDNI.GOOD.ABC.COMPANY.DATA and an email will be sent to theiruser@abc.company.com.

If the request is unsuccessful, the data set PRODDNI.ABC.COMPANY.DATA will be renamed to PRODDNI.FAIL.ABC.COMPANY.DATA and an email will be sent to techsup@mycompany.com.

Note: In this example, you can tell one user that a file has arrived and another user that the request has failed. If some users must perform some actions when data is received, you can use the EMAIL_GOOD parameter to notify them that the request was successful. You can also use the EMAIL_FAIL parameter to notify technical support if a request has failed.

Using the LIST Function

You can use Fusion to send a single file to a list of recipients, which is called the distribution list. The distribution list must be defined to the platform server before you initiate a request to that list. A distribution list can consist of different platform server nodes, SNA LUnames, IP addresses, and IP names. See TIBCO Managed File Transfer Platform Server for z/OS Installation and Operation Guide for more information about distribution lists, which is also called multi-casting.

First, you must define a distribution list. Sample DNI definitions are as follows: 

LIST1
 -----
	TYPE=LIST            
	NODE=SNANODE,TCPNODE
	IPADDR=127.128.129.1
	IPNAME=yourhost.companya.com
	IPPORT=2500
	IPADDR=127.128.129.2

You can set up a DNI configuration member that consists of the following parameters: 

REQUEST=SEND                  
	DSN=PRODDNI.ACCT.DATA
	REMOTE_FILE=C:\PRODDNI\%NOHLQ 
	TYPE=TEXT                     
	LIST=LIST1
	TRY=5                         
	FAIL_ACTION=RENAME            
	FAIL_NEWDSN=%Q01.FAIL.%NOHLQ  
	GOOD_ACTION=RENAME            
	GOOD_NEWDSN=%Q01.GOOD.%NOHLQ  
	EMAIL_GOOD=ACCT@mycompany.com
	EMAIL_FAIL=techsup@mycompany.com
When the PRODDNI.ACCT.DATA file is created, DNI schedules a file send request to all of the platform server systems defined in LIST1. The following nodes are processed in the file transfer:
  • SNANODE
  • TCPNODE
  • IPADDR 127.128.129.1: uses the IP port defined in the platform server Global file.
  • IPNAME yourhost.companya.com: uses the IP port defined in the platform server Global file.
  • IPADDR 127.128.129.2: uses IP port 2500.

If a request to one of those nodes is successful, an email will be sent to ACCT@mycompany.com. If a request to one of those nodes is unsuccessful, an email will be sent to techsup@mycompany.com.

When all of the requests are completed, either successfully or unsuccessfully, the DNI request are considered completed. If all requests are completed successfully, the file will be renamed to PRODDNI.GOOD.ACCT.DATA. If any of the requests fail, the file will be renamed to PRODDNI.FAIL.ACCT.DATA.