Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Fachwörter

&pagelevel(2)&pagelevel


&pagelevel(2)&pagelevel

Fachwörter, die an anderer Stelle erklärt werden, sind mit kursiver Schrift ausgezeichnet.

Ablaufinvariantes Programm 
reentrant program

siehe reentrant-fähiges Programm.

Abnormale Beendigung einer UTM-Anwendung 
abnormal termination of a UTM application

Beendigung einer UTM-Anwendung, bei der die KDCFILE nicht mehr aktualisiert wird. Eine abnormale Beendigung wird ausgelöst durch einen schwerwiegenden Fehler, z.B. Rechnerausfall, Fehler in der Systemsoftware. Wird die Anwendung erneut gestartet, führt openUTM einen Warmstart durch.

Abstrakte Syntax (OSI) 
abstract syntax

Eine abstrakte Syntax ist die Menge der formal beschriebenen Datentypen, die zwischen Anwendungen über OSI TP ausgetauscht werden sollen. Eine abstrakte Syntax ist unabhängig von der eingesetzten Hardware und der jeweiligen Programmiersprache.

Access-List 
access list

Eine Access-List definiert die Berechtigung für den Zugriff auf einen bestimmten Service, auf eine bestimmte TAC-Queue oder auf eine bestimmte USER-Queue. Eine Access-List ist als Keyset definiert und enthält einen oder mehrere Keycodes, die jeweils eine Rolle in der Anwendung repräsentieren. Benutzer, LTERMs oder (OSI-)LPAPs dürfen nur dann auf den Service oder die TAC-Queue/USER-Queue zugreifen, wenn ihnen die entsprechenden Rollen zugeteilt wurden, d.h. wenn ihr Keyset und die Access-List mindestens einen gemeinsamen Keycode enthalten.

Access Point (OSI)

siehe Dienstzugriffspunkt.

ACID-Eigenschaften 
ACID properties

Abkürzende Bezeichnung für die grundlegenden Eigenschaften von Transaktionen: Atomicity, Consistency, Isolation und Durability.

Administration
administration

Verwaltung und Steuerung einer UTM-Anwendung durch einen Administrator oder ein Administrationsprogramm.

Administrations-Journal 
administration journal

siehe Cluster-Administrations-Journal

Administrationskommando 
administration command

Kommandos, mit denen der Administrator einer UTM-Anwendung Administrationsfunktionen für diese Anwendung durchführt. Die Administrationskommandos sind als Transaktionscodes realisiert.

Administrationsprogramm 
administration program

Teilprogramm, das Aufrufe der Programmschnittstelle für die Administration enthält. Dies kann das Standard-Administrationsprogramm KDCADM sein, das mit openUTM ausgeliefert wird, oder ein vom Anwender selbst erstelltes Programm.

Administrator
administrator

Benutzer mit Administrationsberechtigung.

AES

AES (Advanced Encryption Standard) ist der aktuelle symmetrische Verschlüsselungsstandard, festgelegt vom NIST (National Institute of Standards and Technology), basierend auf dem an der Universität Leuven (B) entwickelten Rijndael-Algorithmus. Wird das AES-Verfahren verwendet, dann erzeugt der UPIC-Client für jede Sitzung einen AES-Schlüssel.

Akzeptor (CPI-C) 
acceptor

Die Kommunikationspartner einer Conversation werden Initiator und Akzeptor genannt. Der Akzeptor nimmt die vom Initiator eingeleitete Conversation mit Accept_Conversation entgegen.

Anmelde-Vorgang (KDCS) 
sign-on service

Spezieller Dialog-Vorgang, bei dem die Anmeldung eines Benutzers an eine UTM-Anwendung durch Teilprogramme gesteuert wird.

Anschlussprogramm 
linkage program

siehe KDCROOT.

Anwendungsinformation 
application information

Sie stellt die Gesamtmenge der von der UTM-Anwendung benutzten Daten dar. Dabei handelt es sich um Speicherbereiche und Nachrichten der UTM-Anwendung, einschließlich der aktuell auf dem Bildschirm angezeigten Daten. Arbeitet die UTM-Anwendung koordiniert mit einem Datenbanksystem, so gehören die in der Datenbank gespeicherten Daten ebenfalls zur Anwendungsinformation.

Anwendungs-Kaltstart 
application cold start

siehe Kaltstart.

Anwendungsprogramm 
application program

Ein Anwendungsprogramm bildet den Hauptbestandteil einer UTM-Anwendung. Es besteht aus der Main Routine KDCROOT und den Teilprogrammen. Es bearbeitet alle Aufträge, die an eine UTM-Anwendung gerichtet werden.

Anwendungs-Warmstart 
application warm start

siehe Warmstart.

Apache Axis

Apache Axis (Apache eXtensible Interaction System) ist eine SOAP-Engine zur Konstruktion von darauf basierenden Web Services und Client-Anwendungen. Es existiert eine Implementierung in C++ und Java.

Apache Tomcat

Apache Tomcat stellt eine Umgebung zur Ausführung von Java-Code auf Web-Servern bereit, die im Rahmen des Jakarta-Projekts der Apache Software Foundation entwickelt wird. Es handelt sich um einen in Java geschriebenen Servlet-Container, der mithilfe des JSP-Compilers Jasper auch JavaServer Pages in Servlets übersetzen und ausführen kann. Dazu kommt ein kompletter HTTP-Server.

Application Context (OSI) 
application context

Der Application Context ist die Menge der Regeln, die für die Kommunikation zwischen zwei Anwendungen gelten sollen. Dazu gehören z.B. die abstrakten Syntaxen und die zugeordneten Transfer-Syntaxen.

Application Entity (OSI) 
application entity

Eine Application Entity (AE) repräsentiert alle für die Kommunikation relevanten Aspekte einer realen Anwendung. Eine Application Entity wird durch einen global (d.h. weltweit) eindeutigen Namen identifiziert, den Application Entity Title (AET). Jede Application Entity repräsentiert genau einen Application Process. Ein Application Process kann mehrere Application Entities umfassen.

Application Entity Qualifier (OSI) 
application entity qualifier

Bestandteil des Application Entity Titles. Der Application Entity Qualifier identifiziert einen Dienstzugriffspunkt innerhalb der Anwendung. Ein Application Entity Qualifier kann unterschiedlich aufgebaut sein. openUTM unterstützt den Typ "Zahl".

Application Entity Title (OSI) 
application entity title

Ein Application Entity Title ist ein global (d.h. weltweit) eindeutiger Name für eine Application Entity. Er setzt sich zusammen aus dem Application Process Title des jeweiligen Application Process und dem Application Entity Qualifier. 

Application Process (OSI) 
application process

Der Application Process repräsentiert im OSI-Referenzmodell eine Anwendung. Er wird durch den Application Process Title global (d.h. weltweit) eindeutig identifiziert.

Application Process Title (OSI) 
application process title

Gemäß der OSI-Norm dient der Application Process Title (APT) zur global (d.h. weltweit) eindeutigen Identifizierung von Anwendungen. Er kann unterschiedlich aufgebaut sein. openUTM unterstützt den Typ Object Identifier.

Application Service Element (OSI) 
application service element

Ein Application Service Element (ASE) repräsentiert eine Funktionsgruppe der Anwendungsschicht (Schicht 7) des OSI-Referenzmodells.

Association (OSI)
association

Eine Association ist eine Kommunikationsbeziehung zwischen zwei Application Entities. Dem Begriff Association entspricht der LU6.1-Begriff Session.

Asynchron-Auftrag 
queued job

Auftrag, der vom Auftraggeber zeitlich entkoppelt durchgeführt wird. Zur Bearbeitung von Asynchron-Aufträgen sind in openUTM Message Queuing Funktionen integriert, vgl. UTM-gesteuerte Queue und Service-gesteuerte Queue. Ein Asynchron-Auftrag wird durch die Asynchron-Nachricht, den Empfänger und ggf. den gewünschten Ausführungszeitpunkt beschrieben. 
Ist der Empfänger ein Terminal, ein Drucker oder eine Transportsystem-Anwendung, so ist der Asynchron-Auftrag ein Ausgabe-Auftrag; ist der Empfänger ein Asynchron-Vorgang derselben oder einer fernen Anwendung, so handelt es sich um einen Hintergrund-Auftrag.
Asynchron-Aufträge können zeitgesteuerte Aufträge sein oder auch in einen Auftrags-Komplex integriert sein.

Asynchron-Conversation 
asynchronous conversation

CPI-C-Conversation, bei der nur der Initiator senden darf. Für den Akzeptor muss in der UTM-Anwendung ein asynchroner Transaktionscode generiert sein.

Asynchron-Nachricht 
asynchronous message

Asynchron-Nachrichten sind Nachrichten, die an eine Message Queue gerichtet sind. Sie werden von der lokalen UTM-Anwendung zunächst zwischengespeichert und dann unabhängig vom Auftraggeber weiter verarbeitet. Je nach Empfänger unterscheidet man folgende Typen von Asynchron-Nachrichten: 

              • Bei Asynchron-Nachrichten an eine UTM-gesteuerte Queue wird die Weiterverarbeitung komplett durch openUTM gesteuert. Zu diesem Typ gehören Nachrichten, die einen lokalen oder fernen Asynchron-Vorgang starten (vgl. auch Hintergrund-Auftrag) und Nachrichten, die zur Ausgabe an ein Terminal, einen Drucker oder eine Transportsystem-Anwendung geschickt werden (vgl. auch Ausgabe-Auftrag).

              • Bei Asynchron-Nachrichten an eine Service-gesteuerte Queue wird die Weiterverarbeitung durch einen Service der Anwendung gesteuert. Zu diesem Typ gehören Nachrichten an eine TAC-Queue, Nachrichten an eine USER-Queue und Nachrichten an eine Temporäre Queue. Die User-Queue und die Temporäre Queue müssen dabei zur lokalen Anwendung gehören, die TAC-Queue kann sowohl in der lokalen als auch in einer fernen Anwendung liegen.

Asynchron-Programm 
asynchronous program

Teilprogramm, das von einem Hintergrund-Auftrag gestartet wird.

Asynchron-Vorgang (KDCS) 
asynchronous service

Vorgang , der einen Hintergrund-Auftrag bearbeitet. Die Verarbeitung erfolgt entkoppelt vom Auftraggeber. Ein Asynchron-Vorgang kann aus einem oder mehreren Teilprogrammen/Transaktionen bestehen. Er wird über einen asynchronen  Transaktionscode gestartet.

Auftrag 
job

Anforderung eines Services , der von einer UTM-Anwendung zur Verfügung gestellt wird, durch Angabe eines Transaktionscodes . Siehe auch: Ausgabe-Auf trag , Dialog-Auftrag , Hintergrund-Auftrag , Auftrags-Komplex.

Auftraggeber-Vorgang 
job-submitting service

Ein Auftraggeber-Vorgang ist ein Vorgang, der zur Bearbeitung eines Auftrags einen Service von einer anderen Server-Anwendung (Auftragnehmer-Vorgang) anfordert.

Auftragnehmer-Vorgang 
job-receiving service

Ein Auftragnehmer-Vorgang ist ein Vorgang, der von einem Auftraggeber-Vorgang einer anderen Server-Anwendung gestartet wird.

Auftrags-Komplex 
job complex

Auftrags-Komplexe dienen dazu, Asynchron-Aufträgen Quittungsaufträge zuzuordnen. Ein Asynchron-Auftrag innerhalb eines Auftrags-Komplexes wird Basis-Auftrag genannt.

Ausgabe-Auftrag 
queued output job

Ausgabeaufträge sind Asynchron-Aufträge, die die Aufgabe haben, eine Nachricht, z.B. ein Dokument, an einen Drucker, ein Terminal oder eine Transportsystem-Anwendung auszugeben. 
Ausgabeaufträge werden ausschließlich von UTM-Systemfunktionen bearbeitet, d.h. für die Bearbeitung müssen keine Teilprogramme erstellt werden.

Authentisierung
authentication

siehe Zugangskontrolle.

Autorisierung
authorization

siehe Zugriffskontrolle.

Axis

siehe Apache Axis.

Basis-Auftrag 
basic job

Asynchron-Auftrag in einem Auftrags-Komplex.

Basisformat 
basic format

Format, in das der Terminal-Benutzer alle Angaben eintragen kann, die notwendig sind, um einen Vorgang zu starten.

Basisname
filebase

Basisname der UTM-Anwendung. 
Auf BS2000-Systemen ist Basisname das Präfix für die KDCFILE, die Benutzerprotokoll-Datei USLOG und die System-Protokolldatei SYSLOG.
Auf Unix-, Linux- und Windows-Systemen ist Basisname der Name des Verzeichnisses, unter dem die KDCFILE, die Benutzerprotokoll-Datei USLOG, die System-Protokolldatei SYSLOG und weitere Dateien der UTM-Anwendung abgelegt sind.

Basisname der Knoten-Anwendung 
node filebase

Dateinamens-Präfix bzw. Verzeichnisname für die KDCFILEBenutzerprotokoll-Datei und Systemprotokoll-Datei der Knoten-Anwendung.

Basisname der UTM-Cluster-Anwendung 
cluster filebase

Dateinamens-Präfix bzw. Verzeichnisname für die UTM-Cluster-Dateien.

Benutzerausgang 
user exit

Begriff ersetzt durch Event-Exit. 

Benutzerkennung 
user ID

Bezeichner für einen Benutzer, der in der Konfiguration der UTM-Anwendung festgelegt ist (optional mit Passwort zur Zugangskontrolle) und dem spezielle Zugriffsrechte (Zugriffskontrolle) zugeordnet sind. Ein Terminal-Benutzer muss bei der Anmeldung an die UTM-Anwendung diesen Bezeichner (und ggf. das zugeordnete Passwort) angeben. Auf BS2000-Systemen ist außerdem eine Zugangskontrolle über Kerberos möglich. 
Für andere Clients ist die Angabe der Benutzerkennung optional, siehe auch Verbindungs-Benutzerkennung
UTM-Anwendungen können auch ohne Benutzerkennungen generiert werden.

Benutzer-Protokolldatei 
user log file

Datei oder Dateigeneration, in die der Benutzer mit dem KDCS-Aufruf LPUT Sätze variabler Länge schreibt. Jedem Satz werden die Daten aus dem KB-Kopf des KDCS-Kommunikationsbereichs vorangestellt. Die Benutzerprotokolldatei unterliegt der Transaktionssicherung von openUTM.

Berechtigungsprüfung 
sign-on check

siehe Zugangskontrolle.

Beweissicherung (BS2000-Systeme)
audit

Im Betrieb einer UTM-Anwendung können zur Beweissicherung sicherheitsrelevante UTM-Ereignisse von SAT protokolliert werden.

Bildschirm-Wiederanlauf 
screen restart

Wird ein Dialog-Vorgang unterbrochen, gibt openUTM beim Vorgangswiederanlauf die Dialog-Nachricht der letzten abgeschlossenen Transaktion erneut auf dem Bildschirm aus, sofern die letzte Transaktion eine Nachricht auf den Bildschirm ausgegeben hat.

Browsen von Asynchron-Nachrichten 
browsing asynchronous messages

Ein Vorgang liest nacheinander die Asynchron-Nachrichten, die sich in einer Service-gesteuerten Queue befinden. Die Nachrichten werden während des Lesens nicht gesperrt und verbleiben nach dem Lesen in der Queue. Dadurch ist gleichzeitiges Lesen durch unterschiedliche Vorgänge möglich.

Bypass-Betrieb (BS2000-Systeme) 
bypass mode

Betriebsart eines Druckers, der lokal an ein Terminal angeschlossen ist. Im Bypass-Betrieb wird eine an den Drucker gerichtete Asynchron-Nachricht an das Terminal gesendet und von diesem auf den Drucker umgeleitet, ohne auf dem Bildschirm angezeigt zu werden. 

Cache-Speicher
cache

Pufferbereich zur Zwischenspeicherung von Anwenderdaten für alle Prozesse einer UTM-Anwendung. Der Cache-Speicher dient zur Optimierung der Zugriffe auf den Pagepool und für UTM-Cluster-Anwendungen zusätzlich auf den Cluster-Pagepool.

CCR (Commitment, Concurrency and Recovery)

CCR ist ein von OSI definiertes Application Service Element (ASE) für die OSI-TP-Kommunkation, welches die Protokollelemente (Services) zum Beginn und Abschluss (Commit oder Rollback) einer Transaktion enthält. CCR unterstützt das Zwei-Phasen-Commitment.

CCS-Name (BS2000-Systeme) 
CCS name

siehe Coded-Character-Set-Name .

Client 
client

Clients einer UTM-Anwendung können sein:

              • Terminals

              • UPIC-Client-Programme

              • Transportsystem-Anwendungen (z.B. DCAM-, PDN-, CMX-, Socket-Anwendungen oder UTM-Anwendungen, die als Transportsystem-Anwendung generiert sind)

Clients werden über LTERM-Partner an die UTM-Anwendung angeschlossen. 
Hinweis: UTM-Clients mit Trägersystem OpenCPIC werden wie OSI TP-Partner behandelt.

Client-Seite einer Conversation 
client side of a conversation

Begriff ersetzt durch Initiator.

Cluster

Eine Anzahl von Rechnern, die über ein schnelles Netzwerk verbunden sind und die von außen in vielen Fällen als ein Rechner gesehen werden können. Das Ziel des "Clustering" ist meist die Erhöhung der Rechenkapazität oder der Verfügbarkeit gegenüber einem einzelnen Rechner.

Cluster-Administrations-Journal 
cluster administration journal

Das Cluster-Administrations-Journal besteht aus:

              • zwei Protokolldateien mit Endungen JRN1 und JRN2 für globale Administrationsaktionen,

              • der JKAA-Datei, die eine Kopie der KDCS Application Area (KAA) enthält. Aus dieser Kopie werden administrative Änderungen übernommen, die nicht mehr in den beiden Protokolldateien enthalten sind.

Die Administrations-Journal-Dateien dienen dazu, administrative Aktionen, die in einer UTM-Cluster-Anwendung Cluster-weit auf alle Knoten-Anwendungen wirken sollen, an die anderen Knoten-Anwendungen weiterzugeben.

Cluster-GSSB-Datei 
cluster GSSB file

Datei zur Verwaltung von GSSBs in einer UTM-Cluster-Anwendung. Die Cluster-GSSB-Datei wird mit dem UTM-Generierungstool KDCDEF erstellt.

Cluster-Konfigurationsdatei 
cluster configuration file

Datei, die die zentralen Konfigurationsdaten einer UTM-Cluster-Anwendung enthält. Die Cluster-Konfigurationsdatei wird mit dem UTM-Generierungstool KDCDEF erstellt.

Cluster-Lock-Datei 
cluster lock file

Datei einer UTM-Cluster-Anwendung, die dazu dient, Knoten-übergreifende Sperren auf Anwenderdatenbereiche zu verwalten.

Cluster-Pagepool 
cluster pagepool

Der Cluster-Pagepool besteht aus einer Verwaltungsdatei und bis zu 10 Dateien, in denen die Cluster-weit verfügbaren Anwenderdaten (Vorgangsdaten inklusive LSSB, GSSB und ULS) einer UTM-Cluster-Anwendung gespeichert werden. Der Cluster-Pagepool wird mit dem UTM-Generierungstool KDCDEF erstellt.

Cluster-Startserialisierungs-Datei 
cluster start serialization file

Lock-Datei, mit der die Starts einzelner Knoten-Anwendungen serialisiert werden (nur auf Unix-, Linux- und Windows-Systemen).

Cluster-ULS-Datei 
cluster ULS file

Datei zur Verwaltung von ULS-Bereichen einer UTM-Cluster-Anwendung. Die Cluster-ULS-Datei wird mit dem UTM-Generierungstool KDCDEF erstellt.

Cluster-User-Datei 
cluster user file

Datei, die die Verwaltungsdaten der Benutzer einer UTM-Cluster-Anwendung enthält. Die Cluster-User-Datei wird mit dem UTM-Generierungstool KDCDEF erstellt.

Coded-Character-Set-Name (BS2000-Systeme) 
coded character set name

Bei Verwendung des Produkts XHCS (eXtended Host Code Support) wird jeder verwendete Zeichensatz durch einen Coded-Character-Set-Namen (abgekürzt: "CCS-Name" oder "CCSN") eindeutig identifiziert. 

Communication Resource Manager 
communication resource manager

Communication Resource Manager (CRMs) kontrollieren in verteilten Systemen die Kommunikation zwischen den Anwendungsprogrammen. openUTM stellt CRMs für den internationalen Standard OSI TP, für den Industrie-Standard LU6.1 und für das openUTM-eigene Protokoll UPIC zur Verfügung.

Contention Loser 
contention loser

Jede Verbindung zwischen zwei Partnern wird von einem der Partner verwaltet. Der Partner, der die Verbindung verwaltet, heißt Contention Winner. Der andere Partner ist der Contention Loser.

Contention Winner 
contention winner

Der Contention Winner einer Verbindung übernimmt die Verwaltung der Verbindung. Aufträge können sowohl vom Contention Winner als auch vom Contention Loser gestartet werden. Im Konfliktfall, wenn beide Kommunikationspartner gleichzeitig einen Auftrag starten wollen, wird die Verbindung vom Auftrag des Contention Winner belegt.

Conversation 
conversation

Bei CPI-C nennt man die Kommunikation zwischen zwei CPI-C-Anwendungsprogrammen Conversation. Die Kommunikationspartner einer Conversation werden Initiator und Akzeptor genannt.

Conversation-ID 
conversation ID

Jeder Conversation wird von CPI-C lokal eine Conversation-ID zugeordnet, d.h. Initiator und Akzeptor haben jeweils eine eigene Conversation-ID. Mit der Conversation-ID wird jeder CPI-C-Aufruf innerhalb eines Programms eindeutig einer Conversation zugeordnet.

CPI-C

CPI-C (Common Programming Interface for Communication) ist eine von X/Open und dem CIW (CPI-C Implementor's Workshop) normierte Programmschnittstelle für die Programm-Programm-Kommunikation in offenen Netzen. Das in openUTM implementierte CPI-C genügt der CPI-C V2.0 CAE Specification  von X/Open. Die Schnittstelle steht in COBOL und C zur Verfügung. 
CPI-C in openUTM kann über die Protokolle OSI TP, LU6.1, UPIC und mit openUTM-LU6.2 kommunizieren.

Cross Coupled System / XCS

Verbund von BS2000-Rechnern mit Highly Integrated System Complex Multiple System Control Facility (HIPLEX® MSCF). 

Datenraum (BS2000-Systeme) 
data space

Virtueller Adressraum des BS2000, der in seiner gesamten Größe vom Anwender genutzt werden kann. 
In einem Datenraum können nur Daten und als Daten abgelegte Programme adressiert werden, es kann kein Programmcode zum Ablauf gebracht werden.

Dead Letter Queue 
dead letter queue

Die Dead Letter Queue ist eine TAC-Queue mit dem festen Namen KDCDLETQ. Sie steht immer zur Verfügung, um Asynchron-Nachrichten an Transaktionscodes, TAC-Queues, LPAP- oder OSI-LPAP-Partner zu sichern, die nicht verarbeitet werden konnten. 
Die Sicherung von Asynchron-Nachrichten in der Dead Letter Queue kann durch den Parameter DEAD-LETTER-Q der TAC-, LPAP- oder OSI-LPAP-Anweisung für jedes Nachrichtenziel einzeln ein- und ausgeschaltet werden.

DES

DES (Data Encryption Standard) ist eine internationale Norm zur Verschlüsselung  von Daten. Bei diesem Verfahren wird ein Schlüssel zum Ver- und Entschlüsseln verwendet. Wird das DES-Verfahren verwendet, dann erzeugt der UPIC-Client für jede Sitzung einen DES-Schlüssel.

Dialog-Auftrag 
dialog job, interactive job

Auftrag, der einen Dialog-Vorgang startet. Der Auftrag kann von einem Client oder - bei Server-Server-Kommunikation - von einer anderen Anwendung erteilt werden.

Dialog-Conversation 
dialog conversation

CPI-C-Conversation, bei der sowohl der Initiator als auch der Akzeptor senden darf. Für den Akzeptor muss in der UTM-Anwendung ein Dialog-Transaktionscode generiert sein.

Dialog-Nachricht 
dialog message

Nachricht, die eine Antwort erfordert oder selbst eine Antwort auf eine Anfrage ist. Dabei bilden Anfrage und Antwort einen Dialog-Schritt.

Dialog-Programm 
dialog program

Teilprogramm, das einen Dialog-Schritt teilweise oder vollständig bearbeitet.

Dialog-Schritt 
dialog step

Ein Dialog-Schritt beginnt mit dem Empfang einer Dialog-Nachricht durch die UTM-Anwendung. Er endet mit der Antwort der UTM-Anwendung. 

Dialog-Terminalprozess (Unix-, Linux- und Windows-Systeme) 
dialog terminal process

Ein Dialog-Terminalprozess verbindet ein Unix-, Linux- oder Windows-Terminal mit den Workprozessen der UTM-Anwendung. Dialog-Terminalprozesse werden entweder vom Benutzer durch Eingabe von utmdtp oder über die LOGIN-Shell gestartet. Für jedes Terminal, das an eine UTM-Anwendung angeschlossen werden soll, ist ein eigener Dialog-Terminalprozess erforderlich.

Dialog-Vorgang 
dialog service

Vorgang , der einen Auftrag im Dialog (zeitlich gekoppelt) mit dem Auftraggeber (Client oder eine andere Server-Anwendung) bearbeitet. Ein Dialog-Vorgang verarbeitet Dialog-Nachrichten vom Auftraggeber und erzeugt Dialog-Nachrichten für diesen. Ein Dialog-Vorgang besteht aus mindestens einer Transaktion. Ein Dialog-Vorgang umfasst in der Regel mindestens einen Dialog-Schritt. Ausnahme: Bei Vorgangskettung können auch mehrere Vorgänge einen Dialog-Schritt bilden.

Dienst 
service

Programm auf Windows-Systemen, das im Hintergrund unabhängig von angemeldeten Benutzern oder Fenstern abläuft.

Dienstzugriffspunkt 
service access point

Im OSI-Referenzmodell stehen einer Schicht am Dienstzugriffspunkt die Leistungen der darunterliegenden Schicht zur Verfügung. Der Dienstzugriffspunkt wird im lokalen System durch einen Selektor identifiziert. Bei der Kommunikation bindet sich die UTM-Anwendung an einen Dienstzugriffspunkt. Eine Verbindung wird zwischen zwei Dienstzugriffspunkten aufgebaut.

Distributed Transaction Processing

X/Open-Architekturmodell für die transaktionsorientierte verteilte Verarbeitung.

Druckadministration 
print administration

Funktionen zur Drucksteuerung und Administration von Ausgabeaufträgen, die an einen Drucker gerichtet sind.

Druckerbündel 
printer pool

Mehrere Drucker, die demselben LTERM-Partner zugeordnet sind. 

Druckergruppe (Unix- und Linux-Systeme) 
printer group

Die Unix- oder Linux-Plattform richtet für jeden Drucker standardmäßig eine Druckergruppe ein, die genau diesen Drucker enthält. Darüber hinaus lassen sich mehrere Drucker einer Druckergruppe, aber auch ein Drucker mehreren Druckergruppen zuordnen.

Druckerprozess (Unix- und Linux-Systeme) 
printer process

Prozess, der vom Mainprozess zur Ausgabe von Asynchron-Nachrichten an eine Druckergruppe eingerichtet wird. Er existiert, solange die Druckergruppe an die UTM-Anwendung angeschlossen ist. Pro angeschlossener Druckergruppe gibt es einen Druckerprozess.

Druckersteuerstation 
printer control terminal

Begriff wurde ersetzt durch Druckersteuer-LTERM.

Druckersteuer-LTERM 
printer control LTERM

Über ein Druckersteuer-LTERM kann sich ein Client oder ein Terminal-Benutzer an eine UTM-Anwendung anschließen. Von dem Client-Programm oder Terminal aus kann dann die Administration der Drucker erfolgen, die dem Druckersteuer-LTERM zugeordnet sind. Hierfür ist keine Administrationsberechtigung notwendig.

Drucksteuerung 
print control

openUTM-Funktionen zur Steuerung von Druckausgaben.

Dynamische Konfiguration 
dynamic configuration

Änderung der Konfiguration durch die Administration. Im laufenden Betrieb der Anwendung können UTM-Objekte wie z.B. TeilprogrammeTransaktionscodesClientsLU6.1-Verbindungen, Drucker oder Benutzerkennungen in die Konfiguration aufgenommen, modifiziert oder teilweise auch gelöscht werden. Hierzu können die Administrationsprogramme WinAdmin oder WebAdmin verwendet werden, oder es müssen eigene Administrationsprogramme erstellt werden, die die Funktionen der Programmschnittstelle der Administration nutzen.

Einschritt-Transaktion 
single-step transaction

Transaktion, die genau einen Dialog-Schritt umfasst.

Einschritt-Vorgang 
single-step service

Dialog-Vorgang, der genau einen Dialog-Schritt umfasst.

Ereignisgesteuerter Vorgang 
event-driven service

Begriff ersetzt durch Event-Service

Event-Exit 
event exit

Routine des Anwendungsprogramms, das bei bestimmten Ereignissen (z.B. Start eines Prozesses, Ende eines Vorgangs) automatisch gestartet wird. Diese darf - im Gegensatz zu den Event-Services - keine KDCS-, CPI-C- und XATMI-Aufrufe enthalten.

Event-Funktion 
event function

Oberbegriff für Event-Exits und Event-Services.

Event-Service 
event service

Vorgang, der beim Auftreten bestimmter Ereignisse gestartet wird, z.B. bei bestimmten UTM-Meldungen. Die Teilprogramme ereignisgesteuerter Vorgänge müssen KDCS-Aufrufe enthalten.

Funktionseinheit, Functional Unit (FU) 
functional unit

Teilmenge des OSI-TP-Protokolls, die eine bestimmte Funktionalität beinhaltet. Das OSI-TP-Protokoll ist in folgende Funktionseinheiten aufgeteilt:

              • Dialogue

              • Shared Control

              • Polarized Control

              • Handshake

              • Commit

              • Chained Transactions

              • Unchained Transactions

              • Recovery

Ein Hersteller, der OSI-TP implementiert, muss nicht alle Funktionseinheiten realisieren, sondern kann sich auf eine Teilmenge beschränken. Eine Kommunikation zwischen Anwendungen zweier unterschiedlicher OSI-TP-Implementierungen ist nur dann möglich, wenn die realisierten Funktionseinheiten zueinander passen.

Generierung
generation

siehe UTM-Generierung.

Globaler Sekundärer Speicherbereich/GSSB 
global secondary storage area

siehe Sekundärspeicherbereich.

Hardcopy-Betrieb 
hardcopy mode

Betriebsart eines Druckers, der lokal an ein Terminal angeschlossen ist. Dabei wird eine Nachricht, die auf dem Bildschirm angezeigt wird, zusätzlich auf dem Drucker abgedruckt.

Heterogene Kopplung 
heterogeneous link

Bei Server-Server-Kommunikation: Kopplung einer UTM-Anwendung mit einer Nicht-UTM-Anwendung, z.B. einer CICS- oder TUXEDO-Anwendung.

Highly Integrated System Complex / HIPLEX ®

Produktfamilie zur Realisierung eines Bedien-, Last- und Verfügbarkeitsverbunds mit mehreren BS2000-Servern.

Hintergrund-Auftrag 
background job

Hintergrund-Aufträge sind Asynchron-Aufträge, die an einen Asynchron-Vorgang der eigenen oder einer fernen Anwendung gerichtet sind. Hintergrund-Aufträge eignen sich besonders für zeitintensive oder zeitunkritische Verarbeitungen, deren Ergebnis keinen direkten Einfluss auf den aktuellen Dialog hat.

HIPLEX ® MSCF

(MSCF = Multiple System Control Facility) 
stellt bei HIPLEX® die Infrastruktur sowie Basisfunktionen für verteilte Anwendungen bereit.

Homogene Kopplung 
homogeneous link

Bei Server-Server-Kommunikation: Kopplung von UTM-Anwendungen. Dabei spielt es keine Rolle, ob die Anwendungen auf der gleichen oder auf unterschiedlichen Betriebssystem-Plattformen ablaufen.

Inbound-Conversation (CPI-C) 
inbound conversation

siehe Incoming-Conversation.

Incoming-Conversation (CPI-C) 
incoming conversation

Eine Conversation, bei der das lokale CPI-C-Programm Akzeptor ist, heißt Incoming-Conversation. In der X/Open-Specification wird für Incoming-Conversation auch das Synonym Inbound-Conversation verwendet.

Initiale KDCFILE 
initial KDCFILE

In einer UTM-Cluster-Anwendung die KDCFILE, die von KDCDEF erzeugt wurde und vor dem Start der Knoten-Anwendungen für jeden Knoten kopiert werden muss.

Initiator (CPI-C)
initiator

Die Kommunikationspartner einer Conversation werden Initiator und Akzeptor genannt. Der Initiator baut die Conversation mit den CPI-C-Aufrufen Initialize_Conversation und Allocate auf. 

Insert 
insert

Feld in einem Meldungstext, in das openUTM aktuelle Werte einträgt.

Inverser KDCDEF 
inverse KDCDEF

Funktion, die aus den Konfigurationsdaten der KDCFILE, die im laufenden Betrieb dynamisch angepasst wurde, Steueranweisungen für einen KDCDEF-Lauf erzeugt. Der inverse KDCDEF kann "offline" unter KDCDEF oder "online" über die Programmschnittstelle zur Administration gestartet werden.

IUTMDB 
IUTMDB

Schnittstelle für die koordinierte Zusammenarbeit mit externen Resource Managern auf BS2000-Systemen. Dazu gehören Datenhaltungssysteme (LEASY) und Datenbanksysteme (SESAM/SQL,UDS/SQL).

JConnect-Client 
JConnect client

Bezeichung für Clients auf Basis des Produkts openUTM-JConnect. Die Kommunikation mit der UTM-Anwendung erfolgt über das UPIC-Protokoll.

JDK

Java Development Kit 
Standard-Entwicklungsumgebung von Oracle Corporation für die Entwicklung von Java-Anwendungen.

Kaltstart 
cold start

Starten einer UTM-Anwendung nach einer normalen Beendigung der Anwendung oder nach einer Neugenerierung (vgl. auch Warmstart).

KDCADM

Standard-Administrationsprogramm, das zusammen mit openUTM ausgeliefert wird. KDCADM stellt Administrationsfunktionen zur Verfügung, die über Transaktionscodes (Administrationskommandos) aufgerufen werden.

KDCDEF

UTM-Tool für die Generierung von UTM-Anwendungen. KDCDEF erstellt anhand der Konfigurationsinformationen in den KDCDEF-Steueranweisungen die UTM-Objekte KDCFILE und die ROOT-Tabellen-Source für die Main Routine KDCROOT
In UTM-Cluster-Anwendungen erstellt KDCDEF zusätzlich die Cluster-Konfigurationsdatei, die Cluster-User-Datei, den Cluster-Pagepool, die Cluster-GSSB-Datei und die Cluster-ULS-Datei.  

KDCFILE

Eine oder mehrere Dateien, die für den Ablauf einer UTM-Anwendung notwendige Daten enthalten. Die KDCFILE wird mit dem UTM-Generierungstool KDCDEF erstellt. Die KDCFILE enthält unter anderem die Konfiguration der Anwendung.

KDCROOT

Main Routine eines Anwendungsprogramms, die das Bindeglied zwischen Teilprogrammen und UTM-Systemcode bildet. KDCROOT wird zusammen mit den Teilprogrammen zum Anwendungsprogramm gebunden.

KDCS-Parameterbereich 
KDCS parameter area

siehe Parameterbereich.

KDCS-Programmschnittstelle 
KDCS program interface

Universelle UTM-Programmschnittstelle, die den nationalen Standard 
DIN 66 265 erfüllt und Erweiterungen enthält. Mit KDCS (Kompatible Datenkommunikationsschnittstelle) lassen sich z.B. Dialog-Services erstellen und Message Queuing Funktionen nutzen. Außerdem stellt KDCS Aufrufe zur verteilten Verarbeitung zur Verfügung.

Kerberos

Kerberos ist ein standardisiertes Netzwerk-Authentisierungsprotokoll (RFC1510), das auf kryptographischen Verschlüsselungsverfahren basiert, wobei keine Passwörter im Klartext über das Netzwerk gesendet werden.

Kerberos-Principal 
Kerberos principal

Eigentümer eines Schlüssels. 
Kerberos arbeitet mit symmetrischer Verschlüsselung, d.h. alle Schlüssel liegen an zwei Stellen vor, beim Eigentümer eines Schlüssels (Principal) und beim KDC (Key Distribution Center).

Keycode 
key code

Code, der in einer Anwendung eine bestimmte Zugriffsberechtigung oder eine bestimmte Rolle repräsentiert. Mehrere Keycodes werden zu einem Keyset zusammengefasst.

Keyset
key set

Zusammenfassung von einem oder mehrerer Keycodes unter einem bestimmten Namen. Ein Keyset definiert Berechtigungen im Rahmen des verwendeten Berechtigungskonzepts (Lock-/Keycode-Konzept oder Access-List -Konzept). 
Ein Keyset kann einer Benutzerkennung , einem LTERM-Partner , einem (OSI-) LPAP-Partner , einem Service oder einer TAC-Queue zugeordnet werden. 

Knoten 
node

Einzelner Rechner eines Clusters.

Knoten-Anwendung 
node application

UTM-Anwendung, die als Teil einer UTM-Cluster-Anwendung auf einem einzelnen Knoten zum Ablauf kommt.

Knoten-Recovery 
node recovery

Wenn für eine abnormal beendete Knoten-Anwendung zeitnah kein Warmstart auf ihrem eigenen Knoten-Rechner möglich ist, kann man für diesen Knoten auf einem anderen Knoten des UTM-Clusters eine Knoten-Recovery (Wiederherstellung) durchführen. Dadurch können Sperren, die von der ausgefallenen Knoten-Anwendung gehalten werden, freigegeben werden, um die laufende UTM-Cluster-Anwendung nicht unnötig zu beeinträchtigen.

Knotengebundener Vorgang 
node bound service

Ein knotengebundener Vorgang eines Benutzers kann nur an der Knoten-Anwendung fortgesetzt werden, an der der Benutzer zuletzt angemeldet war. Folgende Vorgänge sind immer knotengebunden:

              • Vorgänge, die eine Kommunikation mit einem Auftragnehmer über LU6.1 oder OSI TP begonnen haben und bei denen der Auftragnehmervorgang noch nicht beendet wurde

              • eingeschobene Vorgänge einer Vorgangskellerung

              • Vorgänge, die eine SESAM-Transaktion abgeschlossen haben

Außerdem ist der Vorgang eines Benutzers knotengebunden, solange der Benutzer an einer Knoten-Anwendung angemeldet ist.

Kommunikationsbereich/KB (KDCS) 
communication area

Transaktionsgesicherter KDCS-Primärspeicherbereich, der Vorgangs-spezifische Daten enthält. Der Kommunikationsbereich besteht aus 3 Teilen:

              • dem KB-Kopf mit allgemeinen Vorgangsdaten

              • dem KB-Rückgabebereich für Rückgaben nach KDCS-Aufrufen

              • dem KB-Programmbereich zur Datenübergabe zwischen UTM-Teilprogrammen innerhalb eines Vorgangs.

Kommunikationsendpunkt
communication end point

siehe Transportsystem-Endpunkt

Konfiguration
configuration

Summe aller Eigenschaften einer UTM-Anwendung. Die Konfiguration beschreibt:

              • Anwendungs- und Betriebsparameter

              • die Objekte der Anwendung und die Eigenschaften dieser Objekte. Objekte sind z.B. Teilprogramme und Transaktionscodes, Kommunikationspartner, Drucker, Benutzerkennungen

              • definierte Zugriffsschutz- und Zugangsschutzmaßnahmen

Die Konfiguration einer UTM-Anwendung wird bei der UTM-Generierung festgelegt (statische Konfiguration) und kann per Administration dynamisch (während des Anwendungslaufs) geändert werden (dynamische Konfiguration). Die Konfiguration ist in der KDCFILE abgelegt.

Logging-Prozess 
logging process

Prozess auf Unix-, Linux- und Windows-Systemen, der die Protokollierung von Abrechnungssätzen oder Messdaten steuert.

Logische Verbindung 
virtual connection

Zuordnung zweier Kommunikationspartner.

Log4j

Log4j ist ein Teil des Apache Jakarta Projekts. Log4j bietet Schnittstellen zum Protokollieren von Informationen (Ablauf-Informationen, Trace-Records,...) und zum Konfigurieren der Protokoll-Ausgabe. WS4UTM verwendet das Softwareprodukt Log4j für die Trace- und Logging-Funktionalität.

Lockcode

Code, um einen LTERM-Partner oder einen Transaktionscode vor unberechtigtem Zugriff zu schützen. Damit ist ein Zugriff nur möglich, wenn das Keyset des Zugreifenden den passenden Keycode enthält (Lock-/Keycode-Konzept).

Lokaler Sekundärer Speicherbereich/LSSB 
local secondary storage area

siehe Sekundärspeicherbereich. 

LPAP-Bündel 
LPAP bundle

LPAP-Bündel ermöglichen die Verteilung von Nachrichten an LPAP-Partner auf mehrere Partner-Anwendungen. Soll eine UTM-Anwendung sehr viele Nachrichten mit einer Partner-Anwendung austauschen, kann es für die Lastverteilung sinnvoll sein, mehrere Instanzen der Partner-Anwendung zu starten und die Nachrichten auf die einzelnen Instanzen zu verteilen. In einem LPAP-Bündel übernimmt openUTM die Verteilung der Nachrichten an die Instanzen der Partner-Anwendung. Ein LPAP-Bündel besteht aus einem Master-LPAP und mehreren Slave-LPAPs. Die Slave-LPAPs werden dem Master-LPAP bei der UTM-Generierung zugeordnet. LPAP-Bündel gibt es sowohl für das OSI TP-Protokoll als auch für das LU6.1-Protokoll.

LPAP-Partner 
LPAP partner

Für die verteilte Verarbeitung über das LU6.1-Protokoll muss in der lokalen Anwendung für jede Partner-Anwendung ein LPAP-Partner konfiguriert werden. Der LPAP-Partner spiegelt in der lokalen Anwendung die Partner-Anwendung wider. Bei der Kommunikation wird die Partner-Anwendung nicht über ihren Anwendungsnamen oder ihre Adresse, sondern über den Namen des zugeordneten LPAP-Partners angesprochen. 

LTERM-Bündel 
LTERM bundle

Ein LTERM-Bündel (Verbindungsbündel) besteht aus einem Master-LTERM und mehreren Slave-LTERMs. Mit einem LTERM-Bündel (Verbindungsbündel) verteilen Sie asynchrone Nachrichten an eine logische Partner-Anwendung gleichmäßig auf mehrere parallele Verbindungen.

LTERM-Gruppe 
LTERM group

Eine LTERM-Gruppe besteht aus einem oder mehreren Alias-LTERMs, den Gruppen-LTERMs, und einem Primary-LTERM. In einer LTERM-Gruppe ordnen Sie mehrere LTERMs einer Verbindung zu.

LTERM-Partner 
LTERM partner

Um Clients oder Drucker an eine UTM-Anwendung anschließen zu können, müssen in der Anwendung LTERM-Partner konfiguriert werden. Ein Client oder Drucker kann nur angeschlossen werden, wenn ihm ein LTERM-Partner mit entsprechenden Eigenschaften zugeordnet ist. Diese Zuordnung wird i.A. in der Konfiguration festgelegt, sie kann aber auch dynamisch über Terminal-Pools erfolgen.

LTERM-Pool 
LTERM pool

Statt für jeden Client eine LTERM- und eine PTERM-Anweisung anzugeben, kann mit der Anweisung TPOOL ein Pool von LTERM-Partnern definiert werden. Schließt sich ein Client über einen LTERM-Pool an, wird ihm dynamisch ein LTERM-Partner aus dem Pool zugeordnet. 

LU6.1

Geräteunabhängiges Datenaustauschprotokoll (Industrie-Standard) für die transaktionsgesicherte Server-Server-Kommunikation.

LU6.1-LPAP-Bündel 
LU6.1-LPAP bundle

LPAP-Bündel für LU6.1-Partner-Anwendungen. 

LU6.1-Partner 
LU6.1 partner

Partner der UTM-Anwendung, der mit der UTM-Anwendung über das Protokoll LU6.1 kommuniziert. 
Beispiele für solche Partner sind:

              • eine UTM-Anwendung, die über LU6.1 kommuniziert

              • eine Anwendung im IBM-Umfeld (z.B. CICS, IMS oder TXSeries), die über LU6.1 kommuniziert 

Mainprozess (Unix-, Linux- und Windows-Systeme) 
main process

Prozess, der die UTM-Anwendung startet. Er startet die Workprozesse, die UTM-System-ProzesseDruckerprozesse, Netzprozesse, Logging-Prozess und den Timerprozess und überwacht die UTM-Anwendung

Main Routine KDCROOT 
main routine KDCROOT

siehe KDCROOT.

Management Unit 
management unit

Komponente des SE Servers; ermöglicht mit Hilfe des SE Managers ein zentrales, web-basiertes Management aller Units eines SE Servers.

Meldung / UTM-Meldung 
UTM message

Meldungen werden vom Transaktionsmonitor openUTM oder von UTM-Tools (wie z.B. KDCDEF) an Meldungsziele ausgegeben. Eine Meldung besteht aus einer Meldungsnummer und dem Meldungstext, der ggf. Inserts mit aktuellen Werten enthält. Je nach Meldungsziel werden entweder die gesamte Meldung oder nur Teile der Meldung (z.B. nur die Inserts) ausgegeben.

Meldungsdefinitionsdatei 
message definition file

Die Meldungsdefinitionsdatei wird mit openUTM ausgeliefert und enthält standardmäßig die UTM-Meldungstexte in deutscher und englischer Sprache und die Definitionen der Meldungseigenschaften. Aufbauend auf diese Datei kann der Anwender auch eigene, individuelle Meldungsmodule erzeugen. 

Meldungsziel 
message destination

Ausgabemedium für eine Meldung. Mögliche Meldungsziele von Meldungen des Transaktionsmonitors openUTM sind z.B. Terminals, TS-Anwendungen, der Event-Service MSGTAC, die System-Protokolldatei SYSLOG oder TAC-Queues, Asynchron-TACs, USER-Queues, SYSOUT/SYSLST bzw. stderr/stdout. Meldungsziele von Meldungen der UTM-Tools sind SYSOUT/SYSLST bzw. stderr/stdout. 

Mehrschritt-Transaktion 
multi-step transaction

Transaktion, die aus mehr als einem Verarbeitungsschritt besteht. 

Mehrschritt-Vorgang (KDCS) 
multi-step service

Vorgang, der in mehreren Dialog-Schritten ausgeführt wird.

Message Queuing 
message queuing

Message Queuing (MQ) ist eine Form der Kommunikation, bei der die Nachrichten (Messages) nicht unmittelbar, sondern über zwischengeschaltete Message Queues ausgetauscht werden. Sender und Empfänger können zeitlich und räumlich entkoppelt ablaufen. Die Übermittlung der Nachricht hängt nicht davon ab, ob gerade eine Netzverbindung besteht oder nicht. Bei openUTM gibt es UTM-gesteuerte Queues und Service-gesteuerte Queues.

Message Queue 
message queue

Warteschlange, in der bestimmte Nachrichten transaktionsgesichert bis zur Weiterverarbeitung eingereiht werden. Je nachdem, wer die Weiterverarbeitung kontrolliert, unterscheidet man Service-gesteuerte Queues und UTM-gesteuerte Queues.

MSGTAC 
MSGTAC

Spezieller Event-Service, der Meldungen mit dem Meldungsziel MSGTAC per Programm verarbeitet. MSGTAC ist ein Asynchron-Vorgang und wird vom Betreiber der Anwendung erstellt.

Multiplex-Verbindung (BS2000-Systeme) 
multiplex connection

Spezielle Möglichkeit, die OMNIS bietet, um Terminals an eine UTM-Anwendung anzuschließen. Eine Multiplex-Verbindung ermöglicht es, dass sich mehrere Terminals eine Transportverbindung teilen. 

Nachrichten-Bereich/NB (KDCS) 
KDCS message area

Bei KDCS-Aufrufen: Puffer-Bereich, in dem Nachrichten oder Daten für openUTM oder für das Teilprogramm bereitgestellt werden. 

Network File System/Service / NFS

Ermöglicht den Zugriff von Unix- und Linux-Rechnern auf Dateisysteme über das Netzwerk.

Netzprozess (Unix-, Linux- und Windows-Systeme) 
net process

Prozess einer UTM-Anwendung zur Netzanbindung. 

Netzwerk-Selektor 
network selector

Der Netzwerk-Selektor identifiziert im lokalen System einen Dienstzugriffspunkt zur Vermittlungsschicht des OSI-Referenzmodells

Normale Beendigung einer UTM-Anwendung 
normal termination of a UTM application

Kontrollierte Beendigung einer UTM-Anwendung; das bedeutet u.a., dass die Verwaltungsdaten auf der KDCFILE aktualisiert werden. Eine normale Beendigung veranlasst der Administrator (z.B. mit KDCSHUT N). Den Start nach einer normalen Beendigung führt openUTM als Kaltstart durch.

Object Identifier 
object identifier

Ein Object Identifier ist ein weltweit eindeutiger Bezeichner für Objekte im OSI-Umfeld. Ein Object Identifier besteht aus einer Folge von ganzen Zahlen, die einen Pfad in einer Baumstruktur repräsentiert. 

Offener Terminalpool 
open terminal pool

Terminalpool, der nicht auf Clients eines Rechners oder eines bestimmten Typs beschränkt ist. An diesen Terminalpool können sich alle Clients anschließen, für die kein Rechner- oder Typ-spezifischer Terminalpool generiert ist.

OMNIS (BS2000-Systeme)
OMNIS

OMNIS ist ein „Session-Manager“ auf einem BS2000-System, der die gleichzeitige Verbindungsaufnahme von einem Terminal zu mehreren Partnern in einem Netzwerk ermöglicht. OMNIS ermöglicht es außerdem, mit Multiplex-Verbindungen zu arbeiten. 

Online-Import 
online import

Als Online-Import wird in einer UTM-Cluster-Anwendung das Importieren von Anwendungsdaten aus einer normal beendeten Knoten-Anwendung in eine laufende Knoten-Anwendung bezeichnet. 

Online-Update 
online update

Als Online-Update wird in einer UTM-Cluster-Anwendung die Änderung der Konfiguration der Anwendung oder des Anwendungsprogramms oder der Einsatz einer neuen UTM-Korrekturstufe bei laufender UTM-Cluster-Anwendung bezeichnet. 

OpenCPIC

Trägersystem für UTM-Clients, die das OSI TP Protokoll verwenden. 

OpenCPIC-Client 
OpenCPIC client

OSI TP Partner-Anwendungen mit Trägersystem OpenCPIC.

openSM2

Die Produktlinie openSM2 ist eine einheitliche Lösung für das unternehmensweite Performance Management von Server- und Speichersystemen. openSM2 bietet eine Messdatenerfassung, Online-Überwachung und Offline-Auswertung.

openUTM-Cluster 
openUTM cluster

aus der Sicht von UPIC-Clients, nicht aus Server-Sicht:
Zusammenfassung mehrerer Knoten-Anwendungen einer UTM-Cluster-Anwendung zu einer logischen Anwendung, die über einen gemeinsamen Symbolic Destination Name adressiert wird.

openUTM-D

openUTM-D (openUTM-Distributed) ist eine openUTM-Komponente, die verteilte Verarbeitung ermöglicht. openUTM-D ist integraler Bestandteil von openUTM.

OSI-LPAP-Bündel 
OSI-LPAP bundle

LPAP-Bündel für OSI TP-Partner-Anwendungen. 

OSI-LPAP-Partner 
OSI-LPAP partner

OSI-LPAP-Partner sind die bei openUTM generierten Adressen der OSI TP-Partner. Für die verteilte Verarbeitung über das Protokoll OSI TP muss in der lokalen Anwendung für jede Partner-Anwendung ein OSI-LPAP-Partner konfiguriert werden. Der OSI-LPAP-Partner spiegelt in der lokalen Anwendung die Partner-Anwendung wider. Bei der Kommunikation wird die Partner-Anwendung nicht über ihren Anwendungsnamen oder ihre Adresse, sondern über den Namen des zugeordneten OSI-LPAP-Partners angesprochen. 

OSI-Referenzmodell 
OSI reference model

Das OSI-Referenzmodell stellt einen Rahmen für die Standardisierung der Kommunikation von offenen Systemen dar. ISO, die Internationale Organisation für Standardisierung, hat dieses Modell im internationalen Standard
ISO IS7498 beschrieben. Das OSI-Referenzmodell unterteilt die für die Kommunikation von Systemen notwendigen Funktionen in sieben logische Schichten. Diese Schichten haben jeweils klar definierte Schnittstellen zu den benachbarten Schichten. 

OSI TP

Von der ISO definiertes Kommunikationsprotokoll für die verteilte Transaktionsverarbeitung. OSI TP steht für Open System Interconnection Transaction Processing. 

OSI TP-Partner 
OSI TP partner

Partner der UTM-Anwendung, der mit der UTM-Anwendung über das OSI TP-Protokoll kommuniziert. 
Beispiele für solche Partner sind:

              • eine UTM-Anwendung, die über OSI TP kommuniziert

              • eine Anwendung im IBM-Umfeld (z.B. CICS), die über openUTM-LU62 angeschlossen ist

              • ein OpenCPIC-Client

              • Anwendungen anderer TP-Monitore, die OSI TP unterstützen

Outbound-Conversation (CPI-C) 
outbound conversation

siehe Outgoing-Conversation.

Outgoing-Conversation (CPI-C) 
outgoing conversation

Eine Conversation, bei der das lokale CPI-C-Programm der Initiator ist, heißt Outgoing-Conversation. In der X/Open-Specification wird für Outgoing-Conversation auch das Synonym Outbound-Conversation verwendet. 

Pagepool 
page pool

Teil der KDCFILE, in dem Anwenderdaten gespeichert werden. 
In einer stand-alone Anwendung sind dies z.B. Dialog-Nachrichten, Nachrichten an Message QueuesSekundärspeicherbereiche
In einer UTM-Cluster-Anwendung sind dies z.B. Nachrichten an Message Queues, TLS.

Parameterbereich 
parameter area

Datenstruktur, in der ein Teilprogramm bei einem UTM-Aufruf die für diesen Aufruf notwendigen Operanden an openUTM übergibt. 

Partner-Anwendung 
partner application

Partner einer UTM-Anwendung bei verteilter Verarbeitung. Für die verteilte Verarbeitung werden höhere Kommunikationsprotokolle verwendet (LU6.1OSI TP oder LU6.2 über das Gateway openUTM-LU62). 

Postselection (BS2000-Systeme)
postselection

Auswahl der protokollierten UTM-Ereignisse aus der SAT-Protokolldatei, die ausgewertet werden sollen. Die Auswahl erfolgt mit Hilfe des Tools SATUT. 

Programmraum (BS2000-Systeme) 
program space

In Speicherklassen aufgeteilter virtueller Adressraum des BS2000, in dem sowohl ablauffähige Programme als auch reine Daten adressiert werden.

Prepare to commit (PTC) 
prepare to commit

Bestimmter Zustand einer verteilten Transaktion: 
Das Transaktionsende der verteilten Transaktion wurde eingeleitet, es wird jedoch noch auf die Bestätigung des Transaktionsendes durch den Partner gewartet.

Preselection (BS2000-Systeme)
preselection

Festlegung der für die SAT-Beweissicherung zu protokollierenden UTM-Ereignisse. Die Preselection erfolgt durch die UTM-SAT-Administration. Man unterscheidet Ereignis-spezifische, Benutzer-spezifische und Auftrags-(TAC-)spezifische Preselection. 

Presentation-Selektor 
presentation selector

Der Presentation-Selektor identifiziert im lokalen System einen Dienstzugriffspunkt zur Darstellungsschicht des OSI-Referenzmodells.

Primärspeicherbereich 
primary storage area

Bereich im Arbeitsspeicher, auf den das KDCS-Teilprogramm direkt zugreifen kann, z.B. Standard Primärer ArbeitsbereichKommunikationsbereich.

Printerprozess (Unix- und Linux-Systeme) 
printer process

siehe Druckerprozess.

Programmschnittstelle zur Administration 
program interface for administration

UTM-Programmschnittstelle, mit deren Hilfe der Anwender eigene Administrationsprogramme erstellen kann. Die Programmschnittstelle zur Administration bietet u.a. Funktionen zur dynamischen Konfiguration, zur Modifikation von Eigenschaften und Anwendungsparametern und zur Abfrage von Informationen zur Konfiguration und zur aktuellen Auslastung der Anwendung.

Prozess 
prozess

In den openUTM-Handbüchern wird der Begriff "Prozess" als Oberbegriff für Prozess (Unix-, Linux- und Windows-Systeme) und Task (BS2000-Systeme) verwendet.

Queue
queue

siehe Message Queue

Quick Start Kit

Beispielanwendung, die mit openUTM (Windows-Systeme) ausgeliefert wird.

Quittungs-Auftrag 
confirmation job

Bestandteil eines Auftrags-Komplexes, worin der Quittungs-Auftrag dem Basis-Auftrag zugeordnet ist. Es gibt positive und negative Quittungsaufträge. Bei positivem Ergebnis des Basis-Auftrags wird der positive Quittungs-Auftrag wirksam, sonst der negative.

Redelivery
redelivery

Erneutes Zustellen einer Asynchron-Nachricht, nachdem diese nicht ordnungsgemäß verarbeitet werden konnte, z.B. weil die Transaktion zurückgesetzt oder der Asynchron-Vorgang abnormal beendet wurde. Die Nachricht wird wieder in die Message Queue eingereiht und lässt sich damit erneut lesen und/oder verarbeiten. 

Reentrant-fähiges Programm 
reentrant program

Programm, dessen Code durch die Ausführung nicht verändert wird.
Auf BS2000-Systemen ist dies Voraussetzung dafür, Shared Code zu nutzen.

Request 
request

Anforderung einer Service-Funktion durch einen Client oder einen anderen Server.

Requestor
requestor

In XATMI steht der Begriff Requestor für eine Anwendung, die einen Service aufruft.

Resource Manager 
resource manager

Resource Manager (RMs) verwalten Datenressourcen. Ein Beispiel für RMs sind Datenbank-Systeme. openUTM stellt aber auch selbst Resource Manager zur Verfügung, z.B. für den Zugriff auf Message Queues, lokale Speicherbereiche und Logging-Dateien. Anwendungsprogramme greifen auf RMs über RM-spezifische Schnittstellen zu. Für Datenbank-Systeme ist dies meist SQL, für die openUTM-RMs die Schnittstelle KDCS.

RFC1006

Von IETF (Internet Engineering Task Force) definiertes Protokoll der TCP/IP-Familie zur Realisierung der ISO-Transportdienste (Transportklasse 0) auf TCP/IP-Basis. 

RSA

Abkürzung für die Erfinder des RSA-Verschlüsselungsverfahrens Rivest, Shamir und Adleman. Bei diesem Verfahren wird ein Schlüsselpaar verwendet, das aus einem öffentlichen und einem privaten Schlüssel besteht. Eine Nachricht wird mit dem öffentlichen Schlüssel verschlüsselt und kann nur mit dem privaten Schlüssel entschlüsselt werden. Das RSA-Schlüsselpaar wird von der UTM-Anwendung erzeugt.

SAT-Beweissicherung (BS2000-Systeme) 
SAT audit

Beweissicherung durch die Komponente SAT (Security Audit Trail) des BS2000-Softwareproduktes SECOS.

SE Manager 
SE manager

Web-basierte Benutzeroberfläche (GUI) für Business Server der SE Serie. Der SE Manager läuft auf der Management Unit und ermöglicht die zentrale Bedienung und Verwaltung von Server Units (mit /390-Architektur und/oder x86-Architektur), Application Units (x86-Architektur), Net Unit und der Peripherie.

SE Server 
SE server

Ein Business Server der SE Serie von Fujitsu.

Sekundärspeicherbereich 
secondary storage area

Transaktionsgesicherter Speicherbereich, auf den das KDCS-Teilprogramm mit speziellen Aufrufen zugreifen kann. Lokale Sekundärspeicherbereiche (LSSB) sind einem Vorgang zugeordnet, auf globale Sekundärspeicherbereiche (GSSB) kann von allen Vorgängen einer UTM-Anwendung zugegriffen werden. Weitere Sekundärspeicherbereiche sind der Terminal-spezifische Langzeitspeicher (TLS) und der User-spezifische Langzeitspeicher (ULS) .

Selektor 
selector

Ein Selektor identifiziert im lokalen System einen Zugriffspunkt auf die Dienste einer Schicht des OSI-Referenzmodells. Jeder Selektor ist Bestandteil der Adresse des Zugriffspunktes. 

Semaphor (Unix-, Linux- und Windows-Systeme) 
semaphore

Betriebsmittel auf Unix-, Linux- und Windows-Systemen, das zur Steuerung und Synchronisation von Prozessen dient.

Server
server 

Ein Server ist eine Anwendung, die Services zur Verfügung stellt. Oft bezeichnet man auch den Rechner, auf dem Anwendungen laufen, als Server.

Server-Seite einer Conversation (CPI-C) 
server side of a conversation

Begriff ersetzt durch Akzeptor.

Server-Server-Kommunikation 
server-server communication

siehe verteilte Verarbeitung

Service Access Point

siehe Dienstzugriffspunkt. 

Service
service

Services bearbeiten die Aufträge, die an eine Server-Anwendung geschickt werden. Ein Service in einer UTM-Anwendung wird auch Vorgang genannt und setzt sich aus einer oder mehreren Transaktionen zusammen. Ein Service wird über den Vorgangs-TAC aufgerufen. Services können von Clients oder anderen Services angefordert werden. 

Service-gesteuerte Queue 
service controlled queue

Message Queue, bei der der Abruf und die Weiterverarbeitung der Nachrichten durch Services gesteuert werden. Ein Service muss zum Lesen der Nachricht explizit einen KDCS-Aufruf (DGET) absetzen.
Service-gesteuerte Queues gibt es bei openUTM in den Varianten USER-Queue, TAC-Queue und Temporäre Queue.

Service Routine 
service routine

siehe Teilprogramm.

Session 
session

Kommunikationsbeziehung zweier adressierbarer Einheiten im Netz über das SNA-Protokoll LU6.1. 

Session-Selektor 
session selector

Der Session-Selektor identifiziert im lokalen System einen Zugriffspunkt zu den Diensten der Kommunikationssteuerschicht (Session-Layer) des OSI-Referenzmodells.

Shared Code (BS2000-Systeme) 
shared code

Code, der von mehreren Prozessen gemeinsam benutzt werden kann.

Shared Memory 
shared memory

Virtueller Speicherbereich, auf den mehrere Prozesse gleichzeitig zugreifen können.

Shared Objects (Unix-, Linux- und Windows-Systeme) 
shared objects

Teile des Anwendungsprogramms können als Shared Objects erzeugt werden. Diese werden dynamisch zur Anwendung dazugebunden und können im laufenden Betrieb ausgetauscht werden. Shared Objects werden mit der KDCDEF-Anweisung SHARED-OBJECT definiert. 

Sicherungspunkt 
synchronization point, consistency point

Ende einer Transaktion. Zu diesem Zeitpunkt werden alle in der Transaktion vorgenommenen Änderungen der Anwendungsinformation gegen Systemausfall gesichert und für andere sichtbar gemacht. Während der Transaktion gesetzte Sperren werden wieder aufgehoben. 

Single System Image

Unter single system image versteht man die Eigenschaft eines Clusters, nach außen hin als ein einziges, in sich geschlossenes System zu erscheinen. Die heterogene Natur des Clusters und die interne Verteilung der Ressourcen im Cluster ist für die Benutzer des Clusters und die Anwendungen, die mit dem Cluster kommunizieren, nicht sichtbar.

SOA

SOA (Service-oriented architecture). 
SOA ist ein Konzept für eine Systemarchitektur, in dem Funktionen in Form von wieder verwendbaren, technisch voneinander unabhängigen und fachlich lose gekoppelten Services implementiert werden. Services können unabhängig von zugrunde liegenden Implementierungen über Schnittstellen aufgerufen werden, deren Spezifikationen öffentlich und damit vertrauenswürdig sein können. Service-Interaktion findet über eine dafür vorgesehene Kommunikationsinfrastruktur statt.

SOAP

SOAP (Simple Object Access Protocol) ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich auf die Dienste anderer Standards, XML zur Repräsentation der Daten und Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten.

Socket-Verbindung 
socket connection

Transportsystem-Verbindung, die die Socket-Schnittstelle verwendet. Die Socket-Schnittstelle ist eine Standard-Programmschnittstelle für die Kommunikation über TCP/IP.

Stand-alone Anwendung 
stand-alone application

siehe stand-alone UTM-Anwendung.

Stand-alone UTM-Anwendung 
stand-alone UTM application

Herkömmliche UTM-Anwendung, die nicht Bestandteil einer UTM-Cluster-Anwendung ist.

Standard Primärer Arbeitsbereich/SPAB (KDCS) 
standard primary working area

Bereich im Arbeitsspeicher, der jedem KDCS-Teilprogramm zur Verfügung steht. Sein Inhalt ist zu Beginn des Teilprogrammlaufs undefiniert oder mit einem Füllzeichen vorbelegt. 

Startformat 
start format

Format, das openUTM am Terminal ausgibt, wenn sich ein Benutzer erfolgreich bei der UTM-Anwendung angemeldet hat (ausgenommen nach Vorgangs-Wiederanlauf und beim Anmelden über Anmelde-Vorgang).

Statische Konfiguration 
static configuration

Festlegen der Konfiguration bei der UTM-Generierung mit Hilfe des UTM-Tools KDCDEF.

SYSLOG-Datei 
SYSLOG file

siehe System-Protokolldatei.

System-Protokolldatei 
system log file

Datei oder Dateigeneration, in die openUTM während des Laufs einer UTM-Anwendung alle UTM-Meldungen protokolliert, für die das Meldungsziel SYSLOG definiert ist.

TAC
TAC

siehe Transaktionscode.

TAC-Queue 
TAC queue

Message Queue, die explizit per KDCDEF-Anweisung generiert wird. Eine TAC-Queue ist eine Service-gesteuerte Queue und kann unter dem generierten Namen von jedem Service aus angesprochen werden.

Teilprogramm 
program unit

UTM-Services werden durch ein oder mehrere Teilprogramme realisiert. Die Teilprogramme sind Bestandteile des Anwendungsprogramms. Abhängig vom verwendeten API müssen sie KDCS-, XATMI- oder CPIC-Aufrufe enthalten. Sie sind über Transaktionscodes ansprechbar. Einem Teilprogramm können mehrere Transaktionscodes zugeordnet werden.

Teilnachricht (KDCS)
message segment

Die KDCS-Schnittstelle ermöglicht es, Nachrichten mittels einzelner Teilnachrichten zu strukturieren, die dann als ganze Nachricht an den Kommunikationspartner übermittelt werden.

Temporäre Queue 
temporary queue

Message Queue, die dynamisch per Programm erzeugt wird und auch wieder per Programm gelöscht werden kann, vgl. Service-gesteuerte Queue.

Terminal-spezifischer Langzeitspeicher/TLS (KDCS) 
terminal-specific long-term storage

Sekundärspeicher, der einem LTERM-, LPAP- oder OSI-LPAP-Partner zugeordnet ist und über das Anwendungsende hinaus erhalten bleibt.

Timerprozess (Unix-, Linux- und Windows-Systeme) 
timer process

Prozess, der Aufträge zur Zeitüberwachung von Workprozessen entgegennimmt, sie in ein Auftragsbuch einordnet und nach einer im Auftragsbuch festgelegten Zeit den Workprozessen zur Bearbeitung wieder zustellt.

TLS Termination Proxy
TLS termination proxy

Ein TLS-Terminierungsproxy ist ein Proxy-Server, der verwendet wird, um eingehende TLS-Verbindungen zu verarbeiten, die Daten zu entschlüsseln und die unverschlüsselte Anforderung an andere Server weiterzugeben.

TNS (Unix-, Linux- und Windows-Systeme)

Abkürzung für den Transport Name Service, der einem Anwendungsnamen einen Transport-Selektor und das Transportsystem zuordnet, über das die Anwendung erreichbar ist.

Tomcat

siehe Apache Tomcat 

Transaktion
transaction

Verarbeitungsabschnitt innerhalb eines Services, für den die Einhaltung der ACID-Eigenschaften garantiert wird. Von den in einer Transaktion beabsichtigten Änderungen der Anwendungsinformation werden entweder alle konsistent durchgeführt oder es wird keine durchgeführt (Alles-oder-Nichts Regel). Das Transaktionsende bildet einen Sicherungspunkt.

Transaktionscode/TAC 
transaction code

Name, über den ein Teilprogramm aufgerufen werden kann. Der Transaktionscode wird dem Teilprogramm bei der statischen oder dynamischen Konfiguration zugeordnet. Einem Teilprogramm können auch mehrere Transaktionscodes zugeordnet werden.

Transaktionsrate 
transaction rate

Anzahl der erfolgreich beendeten Transaktionen pro Zeiteinheit.

Transfer-Syntax 
transfer syntax

Bei OSI TP werden die Daten zur Übertragung zwischen zwei Rechnersystemen von der lokalen Darstellung in die Transfer-Syntax umgewandelt. Die Transfer-Syntax beschreibt die Daten in einem neutralen Format, das von allen beteiligten Partnern verstanden wird. Jeder Transfer-Syntax muss ein Object Identifier zugeordnet sein.

Transport Layer Security 
transport layer security

Der Transport Layer Security, ist ein  hybrides   Verschlüsselungsprotokoll  zur sicheren  Datenübertragung  im  Internet

Transport-Selektor 
transport selector

Der Transport-Selektor identifiziert im lokalen System einen Dienstzugriffspunkt zur Transportschicht des OSI-Referenzmodells.

Transportsystem-Anwendung 
transport system application

Anwendung, die direkt auf einer Transportsystem-Schnittstelle wie z.B. CMX, DCAM oder Socket aufsetzt. Für den Anschluss von Transportsystem-Anwendungen muss bei der Konfiguration als Partnertyp APPLI oder SOCKET angegeben werden. Eine Transportsystem-Anwendung kann nicht in eine Verteilte Transaktion eingebunden werden.

Transportsystem-Endpunkt 
transport system end point

Bei der Client-/Server- oder Server-/Server-Kommunikation wird eine Verbindung zwischen zwei Transportsystem-Endpunkten aufgebaut. Ein Transportsystem-Endpunkt wird auch als lokaler Anwendungsname bezeichnet und wird mit der Anweisung BCAMAPPL oder mit MAX APPLINAME definiert.

Transportsystem-Zugriffspunkt 
transport system access point

siehe Transportsystem-Endpunkt.

Transportverbindung 
transport connection

Im OSI-Referenzmodell eine Verbindung zwischen zwei Instanzen der Schicht 4 (Transportschicht).

TS-Anwendung 
TS application

siehe Transportsystem-Anwendung.

Typisierter Puffer (XATMI) 
typed buffer

Puffer für den Austausch von typisierten und strukturierten Daten zwischen Kommunikationspartnern. Durch diese typisierten Puffer ist die Struktur der ausgetauschten Daten den Partnern implizit bekannt.

UPIC

Trägersystem für UTM-Clients. UPIC steht für Universal Programming Interface for Communication. Die Kommunikation mit der UTM-Anwendung erfolgt über das UPIC-Protokoll. 

UPIC-Client

Bezeichnung für UTM-Clients mit Trägersystem UPIC und JConnect-Clients. 

UPIC-Protokoll 
Upic protocol

Protokoll für die Client-Server-Kommunikation mit UTM-Anwendungen. Das UPIC-Protokoll wird von UPIC-Clients und von JConnect-Clients verwendet.

UPIC Analyzer

Komponente zur Analyse der mit UPIC Capture mitgeschnittenen UPIC-Kommunikation. Dieser Schritt dient dazu, den Mitschnitt für das Abspielen mit UPIC Replay aufzubereiten.

UPIC Capture

Mitschneiden der Kommunikation zwischen UPIC-Clients und UTM-Anwendungen, um sie zu einem späteren Zeitpunkt abspielen zu können 
(UPIC Replay).

UPIC Replay

Komponente zum Abspielen der mit UPIC Capture mitgeschnittenen und mit UPIC Analyzer aufbereiteten UPIC-Kommunikation.

USER-Queue 
USER queue

Message Queue, die openUTM jeder Benutzerkennung zur Verfügung stellt. Eine USER-Queue zählt zu den Service-gesteuerten Queues und ist immer der jeweiligen Benutzerkennung zugeordnet. Der Zugriff von fremden UTM-Benutzern auf die eigene USER-Queue kann eingeschränkt werden.

User-spezifischer Langzeitspeicher/ULS 
user-specific long-term storage

Sekundärspeicher, der einer Benutzerkennung, einer Session oder einer Association zugeordnet ist und über das Anwendungsende hinaus erhalten bleibt.

USLOG-Datei 
USLOG file

siehe Benutzer-Protokolldatei.

UTM-Anwendung 
UTM application

Eine UTM-Anwendung stellt Services zur Verfügung, die Aufträge von Clients oder anderen Anwendungen bearbeiten. openUTM übernimmt dabei u.a. die Transaktionssicherung und das Management der Kommunikations- und Systemressourcen. Technisch gesehen ist eine UTM-Anwendung eine Prozessgruppe, die zur Laufzeit eine logische Server-Einheit bildet.

UTM-Client 
UTM client

siehe Client. 

UTM-Cluster-Anwendung 
UTM cluster application

UTM-Anwendung, die für den Einsatz in einem Cluster generiert ist und die man logisch als eine Anwendung betrachten kann. 
Physikalisch gesehen besteht eine UTM-Cluster-Anwendung aus mehreren, identisch generierten UTM-Anwendungen, die auf den einzelnen Knoten laufen.

UTM-Cluster-Dateien 
UTM cluster files

Oberbegriff für alle Dateien, die für den Ablauf einer UTM-Cluster-Anwendung auf Unix-, Linux- und Windows-Systemen benötigt werden. Dazu gehören folgende Dateien:

              • Cluster-Konfigurationsdatei

              • Cluster-User-Datei

              • Dateien des Cluster-Pagepool

              • Cluster-GSSB-Datei

              • Cluster-ULS-Datei

              • Dateien des Cluster-Administrations-Journals*

              • Cluster-Lock-Datei*

              • Lock-Datei zur Start-Serialisierung*

Die mit * gekennzeichneten Dateien werden beim Start der ersten Knoten-Anwendung angelegt, alle anderen Dateien werden bei der Generierung mit KDCDEF erzeugt.

UTM-D

siehe openUTM-D.

UTM-Datenstation 
UTM terminal

Begriff ersetzt durch LTERM-Partner.

UTM-F

UTM-Anwendungen können als UTM-F-Anwendungen (UTM-Fast) generiert werden. Bei UTM-F wird zugunsten der Performance auf Platteneingaben/-ausgaben verzichtet, mit denen bei UTM-S die Sicherung von Benutzer- und Transaktionsdaten durchgeführt wird. Gesichert werden lediglich Änderungen der Verwaltungsdaten.
In UTM-Cluster-Anwendungen, die als UTM-F-Anwendung generiert sind (APPLIMODE=FAST), werden Cluster-weit gültige Anwenderdaten auch gesichert. Dabei werden GSSB- und ULS-Daten genauso behandelt wie in UTM-Cluster-Anwendungen, die mit UTM-S generiert sind. Vorgangs-Daten von Benutzern mit RESTART=YES werden jedoch nur beim Abmelden des Benutzers anstatt bei jedem Transaktionsende geschrieben.

UTM-Generierung 
UTM generation

Statische Konfiguration einer UTM-Anwendung mit dem UTM-Tool KDCDEF und Erzeugen des Anwendungsprogramms.

UTM-gesteuerte Queues 
UTM controlled queue

Message Queues, bei denen der Abruf und die Weiterverarbeitung der Nachrichten vollständig durch openUTM gesteuert werden. Siehe auch Asynchron-Auftrag, Hintergrund-Auftrag und Asynchron-Nachricht.

UTM-S

Bei UTM-S-Anwendungen sichert openUTM neben den Verwaltungsdaten auch alle Benutzerdaten über ein Anwendungsende und einen Systemausfall hinaus. Außerdem garantiert UTM-S bei allen Störungen die Sicherheit und Konsistenz der Anwendungsdaten. Im Standardfall werden UTM-Anwendungen als UTM-S-Anwendungen (UTM-Secure) generiert.

UTM-SAT-Administration (BS2000-Systeme) 
UTM SAT administration

Durch die UTM-SAT-Administration wird gesteuert, welche sicherheitsrelevanten UTM-Ereignisse, die im Betrieb der UTM-Anwendung auftreten, von SAT protokolliert werden sollen. Für die UTM-SAT-Administration wird eine besondere Berechtigung benötigt.

UTM-Seite 
UTM page

Ist eine Speichereinheit, die entweder 2K, 4K oder 8K umfasst. In stand-alone UTM-Anwendungen kann die Größe einer UTM-Seite bei der Generierung der UTM-Anwendung auf 2K, 4K oder 8K gesetzt werden. In einer UTM-Cluster-Anwendung ist die Größe einer UTM-Seite immer 4K oder 8K. Pagepool und Wiederanlauf-Bereich der KDCFILE sowie UTM-Cluster-Dateien werden in Einheiten der Größe einer UTM-Seite unterteilt.

UTM Socket Protokoll (USP) 
UTM socket protocol

Proprietäres Protokoll von openUTM oberhalb von TCP/IP zur Umsetzung der über die Socket-Schnittstelle empfangenen Bytestreams in Nachrichten.

UTM-System-Prozess 
UTM system process

UTM-Prozess, der zusätzlich zu den per Startparameter angegebenen Prozessen gestartet wird und nur ausgewählte Aufträge bearbeitet. UTM-System-Prozesse dienen dazu, eine UTM-Anwendung auch bei sehr hoher Last reaktionsfähig zu halten.

UTM-Tool 
UTM tool

Programm, das zusammen mit openUTM zur Verfügung gestellt und für bestimmte UTM-spezifische Aufgaben benötigt wird (z.B. zum Konfigurieren). 

utmpfad (Unix-, Linux- und Windows-Systeme)
utmpath

Das Dateiverzeichnis unter dem die Komponenten von openUTM installiert sind, wird in diesem Handbuch als utmpfad bezeichnet. 
Um einen korrekten Ablauf von openUTM zu garantieren, muss die Umgebungsvariable UTMPATH auf den Wert von utmpfad gesetzt werden. Auf Unix- und Linux-Systemen müssen Sie UTMPATH vor dem Starten einer UTM-Anwendung setzen. Auf Windows-Systemen wird UTMPATH passend zu der zuletzt installierten UTM-Version gesetzt.

Verarbeitungsschritt 
processing step

Ein Verarbeitungsschritt beginnt mit dem Empfangen einer Dialog-Nachricht, die von einem Client oder einer anderen Server-Anwendung an die UTM-Anwendung gesendet wird. Der Verarbeitungsschritt endet entweder mit dem Senden einer Antwort und beendet damit auch den Dialog-Schritt oder er endet mit dem Senden einer Dialog-Nachricht an einen Dritten.

Verbindungs-Benutzerkennung 
connection user ID

Benutzerkennung, unter der eine TS-Anwendung oder ein UPIC-Client direkt nach dem Verbindungsaufbau bei der UTM-Anwendung angemeldet wird. Abhängig von der Generierung des Clients (= LTERM-Partner) gilt:

              • Die Verbindungs-Benutzerkennung ist gleich dem USER der LTERM-Anweisung (explizite Verbindungs-Benutzerkennung). Eine explizite Verbindungs-Benutzerkennung muss mit einer USER-Anweisung generiert sein und kann nicht als "echte" Benutzerkennung verwendet werden.

              • Die Verbindungs-Benutzerkennung ist gleich dem LTERM-Partner (implizite Verbindungs-Benutzerkennung), wenn bei der LTERM-Anweisung kein USER angegeben wurde oder wenn ein LTERM-Pool generiert wurde.

In einer UTM-Cluster-Anwendung ist der Vorgang einer Verbindungs-Benutzerkennung (RESTART=YES bei LTERM oder USER) an die Verbindung gebunden und damit Knoten-lokal.
Eine Verbindungs-Benutzerkennung, die mit RESTART=YES generiert ist, kann in jeder Knoten-Anwendung einen eigenen Vorgang haben.

Verbindungsbündel 
connection bundle

siehe LTERM-Bündel.

Verschlüsselungsstufe 
encryption level

Die Verschlüsselungsstufe legt fest, ob und inwieweit ein Client Nachrichten und Passwort verschlüsseln muss.

Verteilte Transaktion 
distributed transaction

Transaktion, die sich über mehr als eine Anwendung erstreckt und in mehreren (Teil-)Transaktionen in verteilten Systemen ausgeführt wird.

Verteilte Transaktionsverarbeitung 
Distributed Transaction Processing

Verteilte Verarbeitung mit verteilten Transaktionen.

Verteilte Verarbeitung 
distributed processing

Bearbeitung von Dialog-Aufträgen durch mehrere Anwendungen oder Übermittlung von Hintergrundaufträgen an eine andere Anwendung. Für die verteilte Verarbeitung werden die höheren Kommunikationsprotokolle LU6.1 und OSI TP verwendet. Über openUTM-LU62 ist verteilte Verarbeitung auch mit LU6.2 Partnern möglich. Man unterscheidet verteilte Verarbeitung mit verteilten Transaktionen (Anwendungs-übergreifende Transaktionssicherung) und verteilte Verarbeitung ohne verteilte Transaktionen (nur lokale Transaktionssicherung). Die verteilte Verarbeitung wird auch Server-Server-Kommunikation genannt.

Vorgang (KDCS)
service

Ein Vorgang dient zur Bearbeitung eines Auftrags in einer UTM-Anwendung. Er setzt sich aus einer oder mehreren Transaktionen zusammen. Die erste Transaktion wird über den Vorgangs-TAC aufgerufen. Es gibt Dialog-Vorgänge und Asynchron-Vorgänge. openUTM stellt den Teilprogrammen eines Vorgangs gemeinsame Datenbereiche zur Verfügung. Anstelle des Begriffs Vorgang wird häufig auch der allgemeinere Begriff Service gebraucht.

Vorgangs-Kellerung (KDCS) 
service stacking

Ein Terminal-Benutzer kann einen laufenden Dialog-Vorgang unterbrechen und einen neuen Dialog-Vorgang einschieben. Nach Beendigung des eingeschobenen Vorgangs wird der unterbrochene Vorgang fortgesetzt.

Vorgangs-Kettung (KDCS) 
service chaining

Bei Vorgangs-Kettung wird nach Beendigung eines Dialog-Vorgangs ohne Angabe einer Dialog-Nachricht ein Folgevorgang gestartet.

Vorgangs-TAC (KDCS) 
service TAC

Transaktionscode, mit dem ein Vorgang gestartet wird.

Vorgangs-Wiederanlauf (KDCS) 
service restart

Wird ein Vorgang unterbrochen, z.B. infolge Abmeldens des Terminal-Benutzers oder Beendigung der UTM-Anwendung, führt openUTM einen Vorgangs-Wiederanlauf durch. Ein Asynchron-Vorgang wird neu gestartet oder beim zuletzt erreichten Sicherungspunkt fortgesetzt, ein Dialog-Vorgang wird beim zuletzt erreichten Sicherungspunkt fortgesetzt. Für den Terminal-Benutzer wird der Vorgangs-Wiederanlauf eines Dialog-Vorgangs als Bildschirm-Wiederanlauf sichtbar, sofern am letzten Sicherungspunkt eine Dialog-Nachricht an den Terminal-Benutzer gesendet wurde. 

Warmstart 
warm start

Start einer UTM-S-Anwendung nach einer vorhergehenden abnormalen Beendigung. Dabei wird die Anwendungsinformation auf den zuletzt erreichten konsistenten Zustand gesetzt. Unterbrochene Dialog-Vorgänge werden dabei auf den zuletzt erreichten Sicherungspunkt zurückgesetzt, so dass die Verarbeitung an dieser Stelle wieder konsistent aufgenommen werden kann (Vorgangs-Wiederanlauf). Unterbrochene Asynchron-Vorgänge werden zurückgesetzt und neu gestartet oder beim zuletzt erreichten Sicherungspunkt fortgesetzt. 
Bei UTM-F-Anwendungen werden beim Start nach einer vorhergehenden abnormalen Beendigung lediglich die dynamisch geänderten Konfigurationsdaten auf den zuletzt erreichten konsistenten Zustand gesetzt.
In UTM-Cluster-Anwendungen werden die globalen Sperren auf GSSB und ULS, die bei der abnormalen Beendigung von dieser Knoten-Anwendung gehalten wurden, aufgehoben. Außerdem werden Benutzer, die zum Zeitpunkt der abnormalen Beendigung an dieser Knoten-Anwendung angemeldet waren, abgemeldet.

Web Service 
web service

Anwendung, die auf einem Web-Server läuft und über eine standardisierte und programmatische Schnittstelle (öffentlich) verfügbar ist. Die Web Services-Technologie ermöglicht es, UTM-Teilprogramme für moderne Web-Client-Anwendungen verfügbar zu machen, unabhängig davon, in welcher Programmiersprache sie entwickelt wurden.

WebAdmin
WebAdmin

Web-basiertes Tool zur Administration von openUTM-Anwendungen über Web-Browser. WebAdmin enthält neben dem kompletten Funktionsumfang der Programmschnittstelle zur Administration noch zusätzliche Funktionen.

Wiederanlauf
restart

siehe Bildschirm-Wiederanlauf,
siehe Vorgangs-Wiederanlauf.

WinAdmin
WinAdmin

Java-basiertes Tool zur Administration von openUTM-Anwendungen über eine grafische Oberfläche. WinAdmin enthält neben dem kompletten Funktionsumfang der Programmschnittstelle zur Administration noch zusätzliche Funktionen.

Workload Capture & Replay 
workload capture & replay

Programmfamilie zur Simulation von Lastsituationen, bestehend aus den Haupt-Komponenten UPIC Capture, UPIC Analyzer und Upic Replay und auf Unix-, Linux- und Windows-Systemen dem Dienstprogramm kdcsort. Mit Workload Capture & Replay lassen sich UPIC-Sessions mit UTM-Anwendungen aufzeichnen, analysieren und mit veränderten Lastparametern wieder abspielen.

Workprozess (Unix-, Linux- und Windows-Systeme) 
work process

Prozess, in dem die Services der UTM-Anwendung ablaufen.

WS4UTM

WS4UTM (WebServices for openUTM) ermöglicht es Ihnen, auf komfortable Weise einen Service einer UTM-Anwendung als Web Service zur Verfügung zu stellen.

XATMI

XATMI (X/Open Application Transaction Manager Interface) ist eine von X/Open standardisierte Programmschnittstelle für die Programm-Programm-Kommunikation in offenen Netzen. 
Das in openUTM implementierte XATMI genügt der XATMI CAE Specification von X/Open. Die Schnittstelle steht in COBOL und C zur Verfügung. XATMI in openUTM kann über die Protokolle OSI TP, LU6.1 und UPIC kommunizieren.

XHCS (BS2000-Systeme)

XHCS (Extended Host Code Support) ist ein BS2000-Softwareprodukt für die Unterstützung internationaler Zeichensätze.

XML

XML (eXtensible Markup Language) ist eine vom W3C (WWW-Konsortium) genormte Metasprache, in der Austauschformate für Daten und zugehörige Informationen definiert werden können.

Zeitgesteuerter Auftrag 
time-driven job

Auftrag, der von openUTM bis zu einem definierten Zeitpunkt in einer Message Queue zwischengespeichert und dann an den Empfänger weitergeleitet wird. Empfänger kann sein: ein Asynchron-Vorgang der selben Anwendung, eine TAC-Queue, eine Partner-Anwendung, ein Terminal oder ein Drucker. Zeitgesteuerte Aufträge können nur von KDCS-Teilprogrammen erteilt werden.

Zugangskontrolle 
system access control

Prüfung durch openUTM, ob eine bestimmte Benutzerkennung berechtigt ist, mit der UTM-Anwendung zu arbeiten. Die Berechtigungsprüfung entfällt, wenn die UTM-Anwendung ohne Benutzerkennungen generiert wurde.

Zugriffskontrolle 
data access control

Prüfung durch openUTM, ob der Kommunikationspartner berechtigt ist, auf ein bestimmtes Objekt der Anwendung zuzugreifen. Die Zugriffsrechte werden als Bestandteil der Konfiguration festgelegt.

Zugriffspunkt 
access point

siehe Dienstzugriffspunkt.