Further VTAM applications must be generated for interconnection with FT partner systems via an SNA network, irrespective of the type of partner system in question (openFT (z/OS), openFT (Windows) and the connection method of Microsoft’s Host Integration Server used there):
a main station that receives all external transfer requests ("inbound submissions")
substations that are used for transfer requests initiated by the local openFT instance ("outbound submissions").
Naming conventions
The names of these VTAM applications are formed in accordance with a set of naming conventions. They start with a prefix (main station: FJM..., substations: A01..., A02... etc.) to which the ftid of the local openFT instance is added (see section “Generations for internal communication”).
This convention makes it possible to assign unique names to VTAM applications. These names are then used by the local openFT instance when establishing the SNA connection to remote systems.
It also provides unique identification of all interconnected partner systems at transport system level and therefore facilitates extended authentication (see Extended authentication check). If extended authentication is enabled in a remote FT system then, in the case of an SNA connection, the remote system will only accept inbound requests if it is able to assign the substation name (A01ftid, A02ftid etc.) that appears as the sender address to the name of the partner system’s main station entered in the partner list (FJMftid). You can activate extended authentication in z/OS by using PARTNER-CHECK=*TRANSPORT-ADDRESS in the command FTMODOPT. It is only possible to deviate from these main station and substation names ("free VTAM names"), which apply throughout the SNA network, if extended authentication is not used. For further information, refer to the notes below.
The following VTAM applications must therefore be generated:
FJMftid A01ftid A02ftid . . . Annftid
where:
ftid
FT identifier. This alphanumeric character string can consist of up to five characters and must be unique among all interconnected FT systems.
nn
is greater than or equal to the maximum number of transport connections (defined with the operating parameter CONNECTION-LIMIT, see FTMODOPT command). These numbers (01, 02,... nn) must be assigned in continuous ascending order as otherwise not all the generated VTAM applications can be used by openFT.
These VTAM applications are generated using the following statements:
FJMftid APPL ACBNAME=FJMftid, X
AUTH=(ACQ,VPACE), X
DLOGMOD=FJMLMOD, X
MODETAB=modtab, X
PARSESS=YES X
PRTCT=ft-password, X
VPACING=3
A01ftid APPL ACBNAME=A01ftid, X
AUTH=(ACQ,VPACE), X
DLOGMOD=FJMLMOD, X
MODETAB=modtab, X
PARSESS=YES X
PRTCT=ft-password, X
VPACING=3
A02ftid APPL ACBNAME=A02ftid, X
AUTH=(ACQ,VPACE), X
DLOGMOD=FJMLMOD, X
MODETAB=modtab, X
PRTCT=ft-password, X
VPACING=3
.
.
.
Annftid APPL ACBNAME=Annftid, X
AUTH=(ACQ,VPACE), X
DLOGMOD=FJMLMOD, X
MODETAB=modtab, X
PRTCT=ft-password, X
VPACING=3
where:
modtab
is the name of the LOGON mode table (see Extending the LOGON mode table (and, if applicable, the COS table)),
ft-password
is the FT password which may be used to protect the VTAM applications, the request file, the partner list and the trace files of an openFT installation. The password is specified in the FT parameter library (see Setting up the FT parameter library) or in the FT administration command FJGEN (see FJGEN - Set installation parameters). This password specification is optional for the VTAM applications described here.
The entry DLOGMOD=FJMLMOD is essential in these statements.
Notes
During VTAM or NCP generation, it is also necessary to enter the main station and substations of all FT partner systems which are connected via SNA. However, these entries depend on the type of partner system in question (openFT (z/OS), openFT (Windows)) and on the connection method used (Host Integration Server from Microsoft). These entries are therefore described in the sections dealing with the individual partner systems (openFT interconnection of two z/OS systems via an SNA network).
Entries in partner systems using openFT V10 and higher: The name of the main station (FJMftid) of the local openFT instance can be specified in the partner list of the remote FT system (e.g. in the PARTNER-ADDRESS operand of the FTADDPTN command). Examples of the interrelation of VTAM generation and the partner list entries can also be found in the sections dealing with the individual partner systems (openFT interconnection of two z/OS systems via an SNA network).
Entries in partner systems using openFT < V10: The name of the main station (FJMftid) of the local openFT instance must also be specified in the network description of the remote FT system, e.g. in the NETWORK-ADDRESS operand of the FTADDPTN command.
You are advised to generate at least 8 applications A01..., A02..., A03... etc. in order to avoid bottlenecks. The substations of the local openFT instance, A01ftid to Annftid, must be numbered in continuous ascending order, otherwise not all the applications and transport connections available can be used.
In general, the names formed in accordance with the naming conventions described above must be entered both as the name of the VTAM application and as the value of the ACBNAME name (see APPL statements above). Only then can the remote FT system perform extended authentication (see Extended authentication check) as specified in case of a remote openFT (z/OS) in the PARTNER-CHECK=*TRANSPORT-ADDRESS parameter of the FTMODPTN command.
However, if "free" main station and substation names (which apply throughout the SNA network) are to be used, then the following applies:
The "free name" is specified as the name in the APPL statement. However, the name formed in accordance with the naming conventions described above must still be specified for the ACBNAME parameter.
The remote FT systems must/can contain corresponding entries in the network description file/partner list. The entry is mandatory in systems using openFT < V10 and is optional in systems using openFT V10 and higher. If the remote FT system is also an openFT (z/OS), the "free VTAM name" of the local openFT instance’s main station must/can also be specified in the FTADDPTN command (as a value for the NETWORK-ADDRESS parameter in openFT < V10 or, as of V10, as a value of the PARTNER-ADDRESS parameter). If openFT (z/OS) V6 or earlier is used in the remote system then the "free VTAM name" of the local system’s main station must be specified there as a value for the RELADR parameter in the FJADDSYS command. The name of the local system’s main station formed in accordance with the naming conventions must still be specified as SYSADR, i.e. FJMftid.
If a connection is made to openFT (z/OS) or to openFT V8.1 for Windows with Microsoft’s Host Integration Server, then the corresponding entries in the conversion tables or name servers of these products must be made.
If a "VTAM Interpret Table" is generated in the local system, it must also contain the names of the openFT VTAM applications
FJMftid A01ftid A02ftid etc.
If "free VTAM names" are used for the stations of the local openFT instance, none of the partner systems to which this system is connected may operate extended authentication.
The following sections deal with the individual partner systems and contain examples of "free VTAM names".
"Free VTAM names" can only be used for main stations and substations (FJMftid, Annftid). They cannot be used for VTAM applications for internal openFT data communications (FJNADM, FJNNDMS0 ... FJNNDMS9, FJAftid, FJDftid)