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.
There are several ways of organizing your pools:
Do not use names starting with "DFH" for pools.
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:
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.
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.
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.
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.
Do not use names starting with "DFH" for property sets.
[[ Contents Previous Page | Next Page Index ]]