An APPC link consists of one or more "sets" of sessions. The sessions in each set have identical characteristics, apart from being either contention winners or contention losers. Each set of sessions can be assigned a modename that enables it to be mapped to a VTAM® logmode name and from there to a class of service (COS). A set of APPC sessions is therefore referred to as a modeset.
To define an APPC link to a remote system, you must:
However, you must not have more than one APPC connection installed at the same time between an LU-LU pair. Nor should you have an APPC and an LUTYPE6.1 connection installed at the same time between an LU-LU pair.
For all APPC links, except single-session links to APPC terminals, CICS® automatically builds a set of special sessions for the exclusive use of the LU services manager, using the modename SNASVCMG. This is a reserved name, and cannot be used for any of the sets that you define.
If you are defining a VTAM logon mode table, remember to include an entry for the SNASVCMG sessions. (See ACF/VTAM LOGMODE table entries for CICS.)
The form of definition for an APPC system is shown in Figure 43.
DEFINE
CONNECTION(name)
GROUP(groupname)
NETNAME(name)
ACCESSMETHOD(VTAM)
PROTOCOL(APPC)
SINGLESESS(NO)
QUEUELIMIT(NO|0-9999)
MAXQTIME(NO|0-9999)
AUTOCONNECT(NO|YES|ALL)
SECURITYNAME(value)
ATTACHSEC(LOCAL|IDENTIFY|VERIFY|PERSISTENT|MIXIDPE)
BINDPASSWORD(password)
BINDSECURITY(YES|NO)
USEDFLTUSER(NO|YES)
PSRECOVERY(SYSDEFAULT|NONE)
You must specify ACCESSMETHOD(VTAM) and PROTOCOL(APPC) to define an APPC system. The CONNECTION name (that is, the sysidnt) and the netname have the meanings explained in Identifying remote systems (but see the box that follows).
If you are defining an APPC link to a terminal-owning region that is a member of a VTAM generic resource group, NETNAME can specify either the TOR’s generic resource name, or its applid. (See the note about VTAM generic resource names in Generic and specific applids for XRF.) For advice on coding NETNAME for connections to a generic resource, see Installation considerations for VTAM generic resources.
Because this connection will have multiple sessions, you must specify SINGLESESS(N), or allow it to default. (The definition of single-session APPC terminals is described in Defining single-session APPC terminals.)
The AUTOCONNECT option specifies which of the sessions associated with the connection are to be bound when CICS is initialized. Further information is given in The AUTOCONNECT option.
The QUEUELIMIT option specifies the maximum number of requests permitted to queue for free sessions to the remote system. The MAXQTIME option specifies the maximum time between a queue becoming full and it being purged because the remote system is unresponsive. Further information is given in Intersystem session queue management.
If you are using VTAM persistent session support, the PSRECOVERY option specifies whether sessions to the remote system are recovered, if the local CICS fails and restarts within the persistent session delay interval. Further information is given in Using VTAM persistent sessions on APPC links.
For information about security options, see the CICS RACF® Security Guide.
Each group of sessions for an APPC system is defined by means of a DEFINE SESSIONS command. The definition is shown in Figure 44.
Each individual group of sessions is referred to as a modeset.
DEFINE
SESSIONS(csdname)
GROUP(groupname)
CONNECTION(name)
MODENAME(name)
PROTOCOL(APPC)
MAXIMUM(m1,m2)
SENDSIZE(size)
RECEIVESIZE(size)
SESSPRIORITY(number)
AUTOCONNECT(NO|YES|ALL)
USERAREALEN(value)
RECOVOPTION(SYSDEFAULT|UNCONDREL|NONE)
The CONNECTION option specifies the name (1-4 characters) of the APPC system for which the group is being defined; that is, the CONNECTION name in the associated DEFINE CONNECTION command.
The MODENAME option enables you to specify a name (1-8 characters) to identify this group of related sessions. The name must be unique among the modenames for any one APPC intersystem link, and you must not use the reserved names SNASVCMG or CPSVCMG.
The MAXIMUM(m1,m2) option specifies the maximum number of sessions that are to be supported for the group. The parameters of this option have the following meanings:
The RECEIVESIZE option, which specifies the maximum size of request unit (RU) to be received, must be in the range 256 through 30 720.
The AUTOCONNECT option specifies whether the sessions are to be bound when CICS is initialized. Further information is given in The AUTOCONNECT option.
If you are using VTAM persistent session support, and CICS fails and restarts within the persistent session delay interval, the RECOVOPTION option specifies how CICS recovers the sessions. (The RECOVNOTIFY option does not apply to APPC sessions.) Further information is given in Using VTAM persistent sessions on APPC links.
When you are defining an APPC link between two CICS systems, you must ensure that the definitions of the link in each of the systems are compatible.
The compatibility requirements are summarized in Figure 45.
CICSA CICSB
DFHSIT TYPE=CSECT DFHSIT TYPE=CSECT
,APPLID=CICSA 1 3 ,APPLID=CICSB
DEFINE CONNECTION(CICB) 2 10 DEFINE CONNECTION(CICA)
GROUP(groupname) GROUP(groupname)
NETNAME(CICSB) 3 1 NETNAME(CICSA)
ACCESSMETHOD(VTAM) ACCESSMEHOD(VTAM)
PROTOCOL(APPC) PROTOCOL(APPC)
SINGLESESS(N) 4 4 SINGLESESS(N)
QUEUELIMIT(500) QUEUELIMIT(NO)
MAXQTIME(500) ATTACHSEC(IDENTIFY)
BINDPASSWORD(pw) 5 5 BINDPASSWORD(pw)
DEFINE SESSIONS(csdname) DEFINE SESSIONS(csdname)
GROUP(groupname) GROUP(groupname)
CONNECTION(CICB) 2 10 CONNECTION(CICA)
MODENAME(M1) 6 6 MODENAME(M1)
PROTOCOL(APPC) PROTOCOL(APPC)
MAXIMUM(ss,ww) 7 7 MAXIMUM(ss,ww)
SENDSIZE(kkk) 8 9 SENDSIZE(jjj)
RECEIVESIZE(jjj) 9 8 RECEIVESIZE(kkk)
In Figure 45, related options and operands are shown by identical numbers.
You can use the CICS autoinstall facility to allow APPC links to be defined dynamically on their first usage, thereby saving on storage for installed definitions, and on time spent creating the definitions.
If autoinstall is enabled, and an 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 terminals, autoinstall for APPC links 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 link definition as a "template" for a new definition. In order for autoinstall to work, you must have a template for each kind of link you want to be autoinstalled.
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 user program, DFHZATDY, to select an appropriate template for each new link, based on the information it receives from VTAM.
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 link definition can be used as a template but, for performance reasons, your template should be an installed link definition that you do not actually use. The definition is locked while CICS is copying it, and if you have a very large number of sessions autoinstalling, the delay may be noticeable.
Autoinstall support is likely to be beneficial if you have large numbers 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.
For further information about using autoinstall with APPC links, see the CICS Resource Definition Guide. For programming information about the autoinstall user program, see the CICS Customization Guide.
There are two methods available for defining a single-session APPC terminal: you can define a CONNECTION-SESSIONS pair, with SINGLESESS(Y) specified for the connection; or you can define a TERMINAL-TYPETERM pair.
You can define a CONNECTION-SESSIONS pair to represent a single-session APPC terminal.
The forms of DEFINE CONNECTION and DEFINE SESSIONS commands that are required are similar to those shown in Figure 43 and Figure 44. The differences are shown below:
DEFINE CONNECTION(sysidnt)
.
SINGLESESS(Y)
.
DEFINE SESSIONS(csdname)
.
MAXIMUM(1,0)
.
You must specify SINGLESESS(Y) for the connection. The MAXIMUM option must specify only one session. The second value has no meaning for a single session definition as CICS always binds as a contention winner. However, CICS accepts a negotiated bind or a negotiated bind response in which it is changed to the contention loser.
You can define a single-session APPC terminal as a TERMINAL with an associated TYPETERM. This method of definition has two principal advantages:
Autoinstall for APPC single sessions initiated by a VTAM CINIT works in the same way as autoinstall for other terminals, in that you must supply a TERMINAL--TYPETERM model pair. For further information about using autoinstall with APPC single-session terminals, see the CICS Resource Definition Guide.
The basic method for defining an APPC terminal is as follows:
DEFINE TERMINAL(sysid)
MODENAME(modename)
TYPETERM(typeterm)
.
.
DEFINE TYPETERM(typeterm)
DEVICE(APPC)
.
.
Note that, because all APPC devices are seen as systems by CICS, the name in the TERMINAL option is effectively a system name. You would, for example, use CEMT INQUIRE CONNECTION, not CEMT INQUIRE TERMINAL, to inquire about an APPC terminal.
A single, contention-winning session is implied by DEFINE TERMINAL. However, for APPC terminals, CICS accepts a negotiated bind in which it is changed to the contention loser.
The CICS-supplied CSD group DFHTYPE contains a TYPETERM, DFHLU62T, suitable for APPC terminals. You can either use this TYPETERM as it stands, or use it as the basis for your own definition.
If you plan to use automatic installation for your APPC terminals, you need the model terminal definition (LU62) that is provided in the CICS-supplied CSD group DFHTERM. You also have to write an autoinstall user program, and provide suitable VTAM LOGMODE entries.
For further information about TERMINAL and TYPETERM definition, the CICS-supplied CSD groups, and automatic installation, see:
For guidance about VTAM LOGMODE entries, see . For programming information about the autoinstall user program, see .
You can use the AUTOCONNECT option of DEFINE CONNECTION and DEFINE SESSIONS (and of DEFINE TYPETERM for APPC terminals) to control CICS attempts to establish communication with the remote APPC system.
Except for single-session APPC terminals (see Defining single-session APPC terminals), two events are necessary to establish sessions to a remote APPC system.
These events are controlled in part by the AUTOCONNECT option of the DEFINE CONNECTION command, and in part by the AUTOCONNECT of the DEFINE SESSIONS command.
On the DEFINE CONNECTION command, the AUTOCONNECT option specifies whether CICS is to try to bind the LU services manager sessions at the earliest opportunity (when the VTAM ACB is opened). It can have the following values:
The LU services manager sessions cannot, of course, be bound if the remote system is not available. If for any reason they are not bound during CICS initialization, they can be bound by means of a CEMT SET CONNECTION INSERVICE ACQUIRED command. They are also bound if the remote system itself initiates communication. For a single-session APPC terminal, AUTOCONNECT(YES) or AUTOCONNECT(ALL) on the DEFINE CONNECTION command has no effect. This is because a single-session connection has no LU services manager.
On the DEFINE SESSIONS command, the AUTOCONNECT option specifies which sessions are to be bound when the associated LU services manager sessions have been bound. (No user sessions can be bound before this time.)
The option can have the following values:
AUTOCONNECT(ALL) allows CICS to bind contention-losing sessions with remote systems that cannot send bind requests. By specifying AUTOCONNECT(ALL), you may cause CICS to bind a number of contention winners other than the number originally specified in this system. The number of contention winners that CICS binds depends on the reply that the partner system gives to the request to initiate sessions (CNOS exchange). CICS will try to bind as contention winners all sessions that are not designated as contention losers in the CNOS reply. For example, suppose that you define a modegroup with DEFINE SESSIONS MAXIMUM(10,4) on this system and DEFINE SESSIONS MAXIMUM(10,2) on the remote system. If the sessions are acquired from this system, and the contention-losing sessions bind successfully, the result is 8 primary contention-winning sessions.
If AUTOCONNECT(NO) is specified, the sessions can be bound and made available by means of a CEMT SET MODENAME ACQUIRED AVAILABLE command. (For details of the CEMT SET MODENAME command, see the CICS Supplied Transactions manual.) If this is not done, sessions are bound individually according to the demands of your application program.
For a single-session APPC terminal, the value specified for AUTOCONNECT on DEFINE SESSIONS or DEFINE TYPETERM determines whether CICS tries to bind the single session or not.
You can use VTAM persistent sessions to improve the availability of APPC links. After a failed CICS has been restarted, CICS persistent session support enables sessions to be recovered without the need for network flows. CICS determines for how long the sessions should be retained from the PSDINT system initialization parameter. Thus, for persistent session support you must specify a PSDINT value greater than zero (and, on the XRF system initialization parameter, a value of 'NO'--persistent session support is incompatible with XRF). If a failed CICS is restarted within the PSDINT interval, it can use the retained sessions immediately--there is no need for network flows to rebind them. The interval can be changed using the CEMT SET VTAM command, or the EXEC CICS SET VTAM command.
If CICS is terminated through CEMT PERFORM SHUTDOWN IMMEDIATE, or if it fails, sessions are placed in "recovery pending" state. During emergency restart, CICS restores APPC sessions that are defined as persistent to an "in session" state.
In a CICS region running with persistent session support, you use this to specify whether the APPC sessions used by this connection are recovered on system restart within the persistent session delay interval. It can have the following values:
In a CICS region running with persistent session support, the RECOVOPTION option of DEFINE SESSIONS specifies how APPC sessions are to be recovered, after a system restart within the persistent session delay interval.
If you want the sessions to be persistent, you should allow the value to default to SYSDEFAULT. This specifies that CICS is to select the optimum procedure to recover a session on system restart within the persistent delay interval.
For a single-session APPC terminal, the RECOVOPTION option of DEFINE SESSIONS or DEFINE TYPETERM specifies how the terminal is to be returned to service after a system restart within the persistent session delay interval.
Without persistent session support, if AUTOCONNECT(YES) is specified for a terminal, the end-user must wait until the GMTRAN transaction has run before being able to continue working. If AUTOCONNECT(NO) is specified, the user has no way of knowing (unless told by support staff) when CICS is operational again unless he or she tries to log on. In either case, the user is disconnected from CICS and needs to reestablish his session, to regain his working environment. With persistent session support, the session is put into recovery pending state on a CICS failure. If CICS starts within the specified interval, and RECOVOPTION is set to SYSDEFAULT, the user does not need to reestablish his session to regain his working environment.
For definitive information about the SYSDEFAULT value, and about the other possible values of RECOVOPTION, see the CICS Resource Definition Guide.
For further information about CICS support for persistent sessions, see Intercommunication and VTAM persistent sessions.