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 KDCFILE, Benutzerprotokoll-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. Teilprogramme, Transaktionscodes, Clients, LU6.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-Prozesse, Druckerprozesse, 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 Queues, Sekundä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.1, OSI 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 Arbeitsbereich, Kommunikationsbereich.
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.