Organizing your pools and property sets

When you have done the analysis work described in the previous section, you can decide how to organize your pools, their properties, and the connections between nodes and targets.

Organizing pools

There are several ways of organizing your pools:

Do not use names starting with "DFH" for pools.

Organizing property sets

Property sets allow you to define the properties of pools (such as the data format and special functions they use) separately from the definition of the pool itself. You can use a single property set to define any number of pools. You must define as many property sets as you need to satisfy every unique pool requirement. Because the overhead associated with a property set is very small, there is no reason why you should not define a large number of them.

The properties are:

Device attributes
This specifies which family the simulated terminal belongs to, SLU2 or SLU P. For SLU2, it also determines the presentation size of the display (24 x 80, 32 x 80, and so on), and whether it supports extended attributes such as color.

Many back-end applications can be run with any terminal type, so you can use the default device type (SLU2, 3278 model 2). But if you have applications that demand particular terminal types, you need to define pools with the appropriate device types.

Data handling
This specifies which command level to use (high-level with formatted data, or data stream), how much data can be handled, and how contention is to be handled.

High-level is simpler to use and suits many front-end applications; applications that require sophisticated functions or use SLU P, and those performing a simple pass-through, need the more complex data-stream-level. In most cases the default data size of 4096 is adequate; increase it only if you know there are large amounts of data to send and receive in a single command. Set contention handling so that the front end wins--as for a real terminal--unless you have some particular reason for not doing so.

Session management
This specifies whether begin-session and end-session are to be handled by special transactions, and whether initial inbound data is expected. For SLU P, it also includes whether message resynchronization ("set and test sequence number" (STSN)) is to be handled.

The use of event handlers was introduced in topic Signon and signoff procedures; it is generally preferable to use specially written transactions for session management, rather than to leave it to be handled individually by applications.

If a back-end system sends initial data (a "good morning" message) you must specify this as a property of the pool, so that FEPI waits for the data to arrive and ensures that the front-end application receives it; otherwise the results will be unpredictable. For SLU2, IMS™ always sends initial data; CICS® might or might not do so, depending on your system definition.

FEPI does all the necessary STSN handling automatically, but you can specify a transaction to handle it yourself.

Unexpected events
This specifies how unsolicited data and other unexpected events (including setup errors) are to be handled.

General considerations of the need for transactions and queues have been discussed earlier in this chapter. If you choose not to handle unsolicited data in your own transaction, you can tell FEPI how to handle it for you--positively or negatively; if the back-end system is IMS, you must specify that FEPI should respond positively. All unexpected events are logged in the FEPI message log (CSZL), even if you specify no unexpected event queue.

Journaling
This specifies what sort of data journaling is required, and which journal to use.

Do not use names starting with "DFH" for property sets.

[[ Contents Previous Page | Next Page Index ]]