Die Kommunikation zwischen zwei Anwendungen erfolgt aus Sicht von openUTM über Transportverbindungen (im Sinne von TRANSDATA), über die SNA-Sessions abgewickelt werden.
Die Sessions werden über Sessionnamen identifiziert. Die Sessionnamen dienen der Wiederherstellung einer unterbrochenen Kommunikation zwischen zwei Anwendungen. Wurde vor einer Störung mit einem Sessionnamen über eine der möglichen Transportverbindungen kommuniziert, so wird die Kommunikation nach Sessionwiederanlauf unter dem gleichen Sessionnamen, aber nicht unbedingt über die gleiche Transportverbindung fortgesetzt.
Eine Session wird mit der KDCDEF-Steueranweisung LSES definiert. Ihre Sessioneigenschaften werden mit der Steueranweisung SESCHA (Session Charakteristika) festgelegt, (z.B. wie die Session eröffnet, gesteuert und verwaltet wird).
Der Sessionname ist vergleichbar mit dem USER-Namen in UTM-Anwendungen: Ein USER kann ebenfalls einen unterbrochenen Vorgang an einer anderen Datenstation und damit über eine andere Transportverbindung fortsetzen. Damit die Sessionnamen in zwei miteinander verbundenen Anwendungen nicht gleich sein müssen, wird der Sessionname aus zwei Teilen zusammengesetzt (symbolisiert durch das ’+’-Zeichen):
sessionname = local-sessionname+remote-sessionname.
Jeder Teil des Sessionnamens ist maximal 8 Zeichen lang, d.h. der gemeinsame Sessionname hat max. 16 Bytes Länge. Der local-sessionname bezeichnet die gemeinsame Session in der lokalen Anwendung, der remote-sessionname die gleiche Session in der entfernten Anwendung. Daraus folgt, dass in der lokalen und der entfernten Anwendung die Sessionnamen der jeweils anderen Anwendung bekannt sein müssen. Der local-sessionname bildet in der lokalen Anwendung mit den dort definierten USER-Namen eine gemeinsame Namensmenge, der remote-sessionname bildet in der entfernten Anwendung mit den dort definierten USER-Namen eine andere gemeinsame Namensmenge.
Bei Vorgangsstart enthält das Feld "Benutzeridentifikation" im KB-Kopf einen lokalen Sessionnamen, wenn der Auftraggeber eine entfernte LU6.1-Anwendung ist.
Eine Session wird für die Dauer eines Dialogs zwischen einem Auftraggeber und Auftragnehmer exklusiv belegt (bracketing). D.h., dass ein anderer Auftraggeber:
solange warten muss, bis die Session freigegeben ist oder
seinen Auftrag später wiederholen muss, da er abgewiesen wird, oder
eine andere freie Session belegt und seinen Auftrag startet. Voraussetzung dafür ist, dass zur entfernten Anwendung mehrere Transportverbindungen und mehrere Sessions existieren.
Eine der Partner-Anwendungen steuert den Auf- und Abbau der Session (SESCHA-Anweisung). Diese Anwendung wird primary logical unit oder abgekürzt PLU genannt. Die Initiative zum Aufbau der Session kann aber von beiden beteiligten Anwendungen ausgehen.
Beim Aufbau der Session einigen sich die Partner, welche Anwendung die Belegung der Session durch Aufträge steuert. Die Anwendung, die die Session verwalten soll, wird Contention Winner genannt, die andere Contention Loser. Der Contention Winner kann, um einen Auftrag an den Partner zu geben, eine Session belegen, ohne vorher beim Contention Loser nachfragen zu müssen. Der Contention Loser muss erst beim Contention Winner nachfragen.