|
|
|
After installing the components into the correct execution libraries, you must configure the dialog. The ISPF Dialog procedure NMFTSID and the NCL procedure $@NMFTS are available for this purpose.
This procedure is executed when the dialog is entered for the first time and is used to set various installation options and describe the operational environment of the region in which it is running. Parameters set by this initialization procedure are placed into the shared variable pool where they may be accessed by other components in the dialog. The following variables may be set by the installation:
Must contain the name by which the local region (on which this procedure will run) is to be known. For example, if the dialog is to be used on two regions, commonly known as PROD and TEST, then a copy of this procedure must be available on each region with &SYSID set to PROD and TEST, as required.
Contains the data set prefix to be used for any temporary files, such as staging data sets and IEBCOPY SYSIN control files, required by the application on this local system. By default, this is set to the TSO user’s standard TSO prefix but may be changed to any suitable prefix and can contain more than one qualifying name (for example, SYSFTS.&SYSUSER). Because certain unrecoverable transmission failures can result in temporary data sets not being deleted, it may be useful to provide an initial prefix in this manner that clearly identifies this type of data set for later cleanup processing.
Can contain the name of a generic unit on which any local temporary data sets are placed. It is set to SYSDA by default.
Can contain the name of a specific volume on which any local temporary data sets are placed.
Contains the data set prefix used for any temporary files, such as staging data sets, required by the application on a remote system. By default this is set to the TSO user’s standard TSO prefix but can be changed to any suitable prefix and can contain more than one qualifying name (for example, SYSFTS.&SYSUSER). Because certain unrecoverable transmission failures can result in temporary data sets not being deleted, it may be useful to provide an initial prefix in this manner that clearly identifies this type of data set for later cleanup processing.
Can contain the name of a generic unit on which any remote temporary data sets are placed. It is set to SYSDA by default.
Can contain the name of a specific volume on which any remote temporary data sets are placed.
Can contain the cylinder allocations for staging data sets if VSAM staged file transmission are used. Specify both the primary and secondary extents as shown in the procedure where the default of (5 5) is set.
Nominates the type of transmission that is used by this application and can be system or private. The default is system, which means that users must have system request privilege. Because the definitions are created by NCL procedures, users need not have system definition privilege. If the installation requires that only private requests be used, then the NCL procedure $USTSFTS must be modified.
This is used to determine the type of message handling required by the dialog. For TSOE installations, we recommend that you use a default value of E, which means that the dialog traps error messages where possible and displays them on full-screen panels. A value of Y means that messages are written to the terminal followed by *** in the usual ISPF manner. A value of N suppresses message delivery.
Are used to inform the dialog of the valid system combinations available to the user for file transfer. Each combination, identified by n (which must be serially allocated from 1 onwards), requires all four variables and represents a system from which a file transmission can be requested. The variable &SYSFIDn is the name by which a FROM or source system is known to the user (for example, PROD or TEST) and is nominated by the user when specifying the FROM system for the file transfer.
Where the SYSFIDn used in this manner has the same value as variable &SYSID (described above), then the file transfer is deemed to be from a local system and staged transmissions are permitted. The variable &SYSTIDn describes a to or target system that is accessible from &SYSFIDn. Note that a given from system may have more than one target system, in which case an additional set of variables is required to describe each such combination. The variable &NMAPPLn provides the network name that is running on the from system, which can be contacted to perform the file transmission. &NMLINKn provides the name of the link from the system that can be used to transmit the data set to the target (that is, &SYSTIDn) system. Code as many sets of these variables as are required for your configuration, starting with n=1.
Reverse (or bidirectional) links require two such definitions to allow transmission to be sourced from either end. See the procedure itself for examples of these parameters.
This NCL procedure is invoked following a staged file transmission in the source and target systems. It is used to reconstruct (if necessary) the prefix allocated to staging data sets so that the reload operation on the target data set and deletion of the staging file can proceed. It can also be used to return the console user ID when user notification is required after a remote request completes. The NCL procedure is driven with two passed parameters and must return the relevant NCL variable as described in the comments in the procedure. The second parameter passed is the TSO user ID of the user who requested the transmission, which may be useful in determining the data set prefix value to return. The following variables can be requested:
This is the staging data set prefix for this user.
This is the name of the user ID on this system, which can be used to establish a ROF session with the system that is running on the system where the TSO user originally requested the transfer. Unless completion notification is required after requesting a transmission from a remote system, this parameter need not be set. (Notification following a transfer from the local system is always available). The console user ID returned in this parameter must be able to issue the ROUTE command, to connect to the system where the TSO user originated the request, and on that system issue an OPSYS command to send the necessary notification to the user.
| Copyright © 2010 CA. All rights reserved. |
|