Communication between two applications is, from the openUTM point of view, carried out using transport connections (in the sense of TRANSDATA), via which the SNA sessions are handled.
The sessions are identified using session names. The session names serve to restart interrupted communication between two applications. If, prior to an interruption, communication via one of the possible transport connections is taking place using a given session name, then when the session is restarted, it is started under the same session name, but not necessarily using the same transport connection.
A session is defined using the KDCDEF control statement LSES, while its characteristics (e.g. the way in which it is opened, controlled, and managed) are defined using the SESCHA control statement.
The session name can be likened to the USER name in UTM applications: a USER can also continue an interrupted service on another terminal, thus using a different transport connection. In order to ensure that the session name in two connected applications does not have to be the same, the session name is made up of two parts (symbolized using the ’+’ character):
session-name = local-session-name+remote-session-name.
Each part of the session name is a maximum of 8 characters in length, thus the entire session name has maximum length of 16 bytes. The local-session-name refers to a common session in the local application, and the remote-session-name refers to the same session in the remote application. This means that the both the local and remote applications are required to know the session names of the partner application. The local-session-name uses the USER name defined in the local application to create a common name for the local application, and the remote-sessionname uses the USER names defined in the remote application to create a common name for the remote application.
At the start of a service, the “user ID" field in the KB header contains a local session name if the requester is a remote LU6.1 application.
A session is exclusively occupied for the duration of the dialog between the job-sending application and the job-receiving application (bracketing). In other words, another job-sending application will be required to:
wait until the session has been released or
repeat its job later, as it will be rejected at this time or
occupy a different free session and start its job from there. The prerequisite for this is that there are several transport connections and sessions available for the remote application.
The opening and closing of a session is always controlled by one of the partner applications. This application is then referred to as the primary logical unit or PLU. However, the initiative for opening a session may come from both applications involved.
When opening a session, the partners agree on which application is to be responsible for for controlling the reservation of the session by jobs. The application which shall control the session is known as the contention winner, while the other application is referred to as the contention loser. In order to submit a job to the partner, the contention winner can reserve a session without consulting the contention loser beforehand. The contention loser, on the other hand, must request a session from the contention winner.