Analysis and planning

First, you need to consider the following:

Then you can decide how to organize your pools, their properties, and the connections.

These are now discussed in turn.

Back-end applications and systems

You need to know whether the back-end systems are CICS® or IMS™, the terminal types they use, and the timing and volume of transactions expected. Also, are there any restrictions on the use of the terminals? For example:

Names of nodes and targets

Nodes

Decide which VTAM® node names are available for use by FEPI as simulated terminals. (Remember that FEPI nodes are VTAM APPL definitions, not logical units (LUs).) Do not use names starting with "DFH".

Targets

The back-end system already has defined VTAM primary PLU names (applids) which you must use. However, you can define your own local target names to associate with these applids. This means that FEPI applications are not affected if an applid is changed; you simply associate the local name with the new back-end target name. Do not use names starting with "DFH".

Operator control requirements

The CEMT INQUIRE and SET master terminal transactions can be used to view and amend the state of FEPI resources. CEMT DISCARD can be used to remove resources from FEPI. This is described in Operator control of FEPI. If you decide you need extra functions for operators, you will need to write appropriate programs.

Journaling requirements

Journaling is available if you need it. Among the reasons for using FEPI journaling are:

For further information, see FEPI journaling.

Signon and signoff procedures

You need to know if there are any specific requirements for signon and signoff to back-end systems. Central control may be required, or applications may perform signon and signoff individually.

Special event handling

In addition to signon and signoff, you need to consider what should be done in the following circumstances, and whether they are to be handled by central functions or by applications individually:

If some sort of enforcement is required, or you want central provision for convenience, commonality, or the upholding of conventions and standards, you must supply a set of standard handlers. Otherwise, the application programs must handle each event. If you need special back-end processing when CICS shuts down, you need an end-session handler.

Unexpected events (including errors in setup) are reported to a transient data (TD) queue, so that a monitoring transaction can be triggered to handle them; they also send a message to the FEPI message log CSZL. You must decide how to handle these events, and which queues to use.

For more detailed information about the design and structure of applications, including information about using the various event handlers, see FEPI application design.

If you want central control over the range of FEPI commands that applications are permitted to issue, you can use the XSZBRQ global user exit, which is described in FEPI global user exits.

Using pools for control reasons

You can use pools for a number of control purposes. For example, you could define them so as to:

Using pools for functional reasons

Pools determine the data format and special event handlers used by your FEPI applications. These attributes may be specified by the application programmer, or they may be imposed by the system programmer for central control, especially of signon and signoff.

If you need several types of special event handling, you might need to define your own pool-specific transient data queues, as well as the default queues.

Number of nodes

The number of nodes required depends on:

The number of concurrent sessions to a particular target may depend on the volumes of data to be transmitted and the speed of the network.

Although a node can have only one session with a particular target at a time, it can communicate with several different targets concurrently, and several nodes can communicate with the same target concurrently.

Setup program organization

You must decide:

[[ Contents Previous Page | Next Page Index ]]