Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Setting up openFT instances

&pagelevel(4)&pagelevel

Instances are created by means of the FJGEN command (see Setting openFT installation parameters with FJGEN). They are identified and administered via the instance name that you specify with INSTANCE NAME in FJGEN. For the sake of clarity, the instance name should be a name part of all the openFT files and libraries that belong to the corresponding instance (e.g. FTAC files etc.).

WARNING!

The instance name should not be confused with the so-called instance identification that is defined using the IDENTIFICATION parameter in the FTMODOPT command. As of openFT V8.1, the instance identification is used by partner systems in order to authenticate your openFT instance. Similarly, you need these partner systems’ instance identifications in order to authenticate them in the local system.

If you are only working with one instance then you should use the standard instance STD. This name is also proposed as the default in FJGEN.

Instance-specific CONN file

There is a so-called CONN file associated with each instance. It contains information required for internal communication between the command client from the library <openft qualifier>.OPENFT.NCLOAD and openFT from the library
<openft qualifier>.OPENFT.LOAD and for encrypting this communication.

If you want to work with a specific instance then before you call any openFT functions, the instance-specific CONN file must be allocated by:

<openft qualifier>.<inst>.CONN

This is possible, for example, using the following call:

ALLOC DSNAME(’<openft qualifier>.<inst>.CONN’) DDNAME(OPENFT) SHR REUSE

Where <openft qualifier> and <inst> correspond to the OPENFT QUALIFIER and INSTANCE NAME specifications in the FJGEN command.

It is urgently recommended that you allocate the CONN file before calling the openFT command. This also applies if only the standard instance exists!

Instance-specific assignment of the NCLOAD

To allow openFT commands to be called under TSO or from a CLIST, the NCLOAD <openft qualifier>.OPENFT.NCLOAD must be entered in the search path/sequence for TSO commands. This can be done using the following command, for instance:

TSOLIB ACT DATASET(<openft qualifier>.OPENFT.NCLOAD)

Instance-specific CLIST

To administer openFT, it is also necessary to concatenate the instance-specific CLIST<openft qualifier>.<inst>.CLIST (either in the current TSO session or by incorporating it in the LOGON procedure, see Concatenating libraries with the openFT commands). This also applies to the standard instance.

If multiple openFT instances are to run in parallel on a computer under the same user ID, then different job names must be set in the FJBATCH members of the instance-specific CLISTS (for example, USERAX instead of USERAF). These are the batch jobs that load the appropriate openFT instances.

Exchange settings between instances

It is a simple matter to exchange partner entries between the instances using the LAYOUT=*ZOS-PROC parameter in the FTSHWPTN command (see the example for the FTSHWPTN command). FTAC components can be taken over using the commands FTEXPENV and FTIMPENV.

Show information about instances

You can use the FJGENPAR command to view the installation parameters of the current instance during operation (and modify them, if required, by means of a new FJGEN run). FTSHWINS allows you to obtain information on the known openFT instances running on a computer, provided that openFT has been started as a subsystem.