When a transaction acquires a session to another system, either explicitly by means of an ALLOCATE command or implicitly because it uses, for example, function shipping, a communication profile is associated with the communication between the transaction and the session. The communication profile specifies the following information:
CICS provides a set of default profiles, described later in this section, which it uses for various forms of communication. Also, you can define your own profiles, and name a profile explicitly on an ALLOCATE command.
The options of the CEDA DEFINE PROFILE command that are relevant to intersystem sessions are shown in Figure 70. For further information about the CEDA DEFINE PROFILE command, see the CICS Resource Definition Guide.
A profile is always required for a session acquired by an ALLOCATE command; either a profile that you have defined and which is named explicitly on the command, or the default profile DFHCICSA. If CICS cannot find the profile, the CBIDERR condition is raised in the application program.
The only option shown in Figure 70 that applies to MRO sessions is INBFMH. And, for MRO sessions that are acquired by an ALLOCATE command, CICS always uses INBFMH(ALL), no matter what is specified in the profile.
For APPC conversations, INBFMH specifications are ignored; APPC FMHs are never passed to CICS application programs.
DEFINE PROFILE(name)
[GROUP(groupname)]
[MODENAME(name)]
Protocols
[INBFMH(NO|ALL)]
Journaling
[JOURNAL(NO|value)]
[MSGJRNL(NO|INPUT|OUTPUT|INOUT)]
Recovery
[NEPCLASS(0|value)]
[RTIMOUT(NO|value)]
It is usually important to ensure that an intercommunicating transaction never waits indefinitely for data from its partner transaction. The RTIMOUT option should be given a value suitable for intersystem working: rather less than the time-out periods typically specified for terminals used as operator interfaces. The RTIMOUT value should also be greater than the DTIMOUT value specified on the partner transaction definition.
A profile is also associated with the communication between a transaction and its principal facility. You can name the profile in the CEDA DEFINE TRANSACTION command, or you can allow the default to be taken. The CEDA DEFINE PROFILE command for a principal facility profile has more options than the form required for alternate facilities.
The RTIMOUT value defined for a back-end transaction needs to be at least as great as that specified for its front-end partner’s principal facility. This is to cover the possibility of the back-end transaction waiting almost that period of time (plus some execution and network time) to receive data from its front-end.
CICS provides a set of communication profiles, which it uses when the user does not or cannot specify a profile explicitly:
You should not modify this profile.
This profile is also used as a principal facility profile for some CICS-supplied transactions.
Note that, if you use DPL, you may need to increase the value specified for RTIMEOUT--see Modifying the default profiles.
Note that the user-transaction’s principal facility is the surrogate TCTTE in the transaction-owning region, for which the default profile is DFHCICST.
You can modify a default profile by means of the CEDA transaction.
A typical reason for modification is to include a modename to provide class of service selection for, say, function shipping requests on APPC links. If you do this, you must ensure that every APPC link in your installation has a group of sessions with the specified modename.
You must not modify DFHCICSV, which is used exclusively by some CICS-supplied transactions.
You can modify DFHCICSP, used by the CSPG page-retrieval transaction. The supplied version of DFHCICSP specifies UCTRAN(YES). Be aware that, if you specify UCTRAN(NO), terminals defined with UCTRAN(NO) will be unable to make full use of page-retrieval facilities.
If you modify DFHCICSA, you must retain INBFMH(ALL), because it is required by some CICS-supplied transactions. Modifying this profile does not affect the profile options assumed for MRO sessions.
You can modify DFHCICSF, used for function shipping and DPL requests. One reason for doing so might be to increase the value of the RTIMEOUT option. For example, the default value may be adequate for single function shipping requests, but inadequate for a DPL call to a back-end program that retrieves a succession of records from a data base.