Autoinstalling APPC connections - preliminary considerations
- Local APPC single-session connections initiated by CINIT requests
Autoinstall of local APPC single-session connections that are initiated by CINIT requests works in the same way as autoinstall for terminals. You must provide a TERMINAL—TYPETERM model pair, and a customized version of one of the supplied autoinstall control programs, DFHZATDX or DFHZATDY. See Writing a program to control autoinstall of LUs.
- Local APPC parallel-session and single-session connections initiated by incoming bind requests.
(Incoming means that the request is initiated by the partner system.)
If autoinstall is enabled, and an incoming APPC BIND request is received for an APPC service manager (SNASVCMG) session (or for the only session of a single-session connection), and there is no matching CICS® CONNECTION definition, a new connection is created and installed automatically.
Like autoinstall for other resources, autoinstall for APPC connections requires model definitions. However, unlike the model definitions used to autoinstall terminals, those used to autoinstall APPC links do not need to be defined explicitly as models. Instead, CICS can use any previously-installed connection definition as a “template” for a new definition. In order for autoinstall to work, you must have a template for each kind of connection you want to be autoinstalled.
Autoinstall templates for APPC connections
The purpose of a template is to provide CICS with a definition that can be used for all connections with the same properties. You customize the supplied autoinstall control program, DFHZATDY, to select an appropriate template for each new connection, depending on the information it receives from the z/OS® Communications Server for SNA.
A template consists of a CONNECTION definition and its associated SESSIONS definitions. You should have a definition installed for each different set of session properties you are going to need.
Any installed connection definition can be used as a template, but for performance reasons, your template should be an installed connection definition that you do not use. The definition is locked while CICS is copying it, and if you have a lot of sessions autoinstalling, the delay may be noticeable.
Use cases for autoinstall
Autoinstall support is likely to be beneficial if you have lots of APPC parallel session devices with identical characteristics. For example, if you had 1000 personal computers (PCs), all with the same characteristics, you would set up one template to autoinstall all of them. If 500 of your PCs had one set of characteristics, and 500 had another set, you would set up two templates to autoinstall them.
Restart of any kind should be noticeably faster, especially when lots of terminals are involved.
Savings can also be made on systems management overheads, and on storage, as autoinstalled resources do not occupy space before they are used.
Requirements for autoinstall
Autoinstall of APPC connections works with any supported release of ACF/SNA.
You can have only one active autoinstall control program for terminals and connections. You must specify the name of the active program on the AIEXIT system initialization parameter. As well as providing function to autoinstall APPC connections initiated by BIND requests, the sample program, DFHZATDY, provides the same function for terminal autoinstall as the default control program, DFHZATDX, described in Writing a program to control autoinstall of LUs. Thus, you can use a customized version of DFHZATDY to autoinstall both terminals and APPC connections.
You may find the supplied version of DFHZATDY adequate for your purposes. If not, you can write a customized version of the supplied program, or create your own program to provide enhanced function.
Recovery and restart
Autoinstalled connections are not cataloged by CICS, so they are not recovered at an emergency restart or a warm restart.