Except in the special case of the receiving transaction in SEND/RECEIVE asynchronous processing, the CICS® transaction is always the front-end transaction in CICS-to-IMS™ DTP.
The front-end transaction is responsible for acquiring a session to the remote IMS system and initiating the partner transaction.
Thereafter, the two transactions become equals. However, the front-end transaction is usually designed as the client, or driving, transaction.
You acquire an LUTYPE6.1 session to a remote IMS system by means of the ALLOCATE command, which has the following format:
ALLOCATE {SYSID(name)|SESSION(name)}
[PROFILE(name)]
[NOQUEUE]
You can use the SESSION option to request the use of a specific session to the remote IMS system, or you can use the SYSID option to name the partner system and allow CICS to select an available session. The use of the SESSION option is not normally recommended, because it can result in an application program queuing on a specific session when others are available. In most cases, therefore, you use the SYSID option to name the system with which the session is required.
If CICS cannot find the named system, or all sessions to that system are out of service, it raises the SYSIDERR condition. If CICS cannot find the named session, or that session is out of service, it raises the SESSIONERR condition.
The PROFILE option allows you to select a specified communication profile for an LUTYPE6.1 session. The profile, which is set up during resource definition, contains a set of terminal control processing options that are to be used for the session.
If you omit the PROFILE option, CICS uses the default profile DFHCICSA. This profile specifies INBFMH(ALL), which means that incoming function management headers are passed to your program and cause the INBFMH condition to be raised.
The NOQUEUE option allows you to specify explicitly that you do not want your request for a session to be queued if a session is not available immediately. A session is "not immediately available" in any of the following situations:
The action taken by CICS if a session is not immediately available depends on whether you specify NOQUEUE and also on whether your application has executed a HANDLE command for the SYSBUSY condition. The possible combinations are shown below:
Whether a delay in acquiring a session is acceptable is dependent on your application.
Similar considerations apply to an ALLOCATE command that specifies SESSION rather than SYSID. The associated condition is SESSBUSY.
When a session has been allocated, the name by which it is known is available in the EIBRSRCE field in the EIB. Because EIBRSRCE will probably be overwritten by the next EXEC CICS command, you must acquire the session name immediately. It is the name that you must use in the SESSION option of all subsequent commands that relate to this session.
[[ Contents Previous Page | Next Page Index ]]