Als Anwender müssen Sie eine Eingabe-Datei erstellen, genannt Local Configuration Definition File. Diese Eingabe-Datei muss aus einzelnen Zeilen aufgebaut werden, für die folgende Syntax gilt:
Eine Zeile beginnt mit einer SVCU- oder BUFFER-Anweisung und spezifiziert genau einen Service oder einen Subtyp (= typisierten Puffer).
Zwei Operanden werden durch ein Komma getrennt.
Eine Anweisungs-Zeile wird durch ein Semikolon (';') abgeschlossen.
Nimmt eine Anweisung mehr als eine Zeile ein, dann muss jeweils am Zeilenende das Fortsetzungszeichen '\' (Gegenschrägstrich) stehen.
Eine Kommentarzeile beginnt mit dem '#'-Zeichen.
Leerzeilen können eingefügt werden, z.B. zur besseren Lesbarkeit.
Aus der Datei, die die Local Configuration Definition enthält, erstellen Sie mit Hilfe des Tools xatmigen die eigentliche Local Configuration File (siehe: das Tool xatmigen).
Im Folgenden werden die SVCU- und die BUFFER-Anweisung beschrieben.
SVCU-Anweisung: Aufrufbaren Service definieren
Eine SVCU-Anweisung beschreibt für den Client die Eigenschaften, die notwendig sind, um einen Service in der Partner-Anwendung aufrufen zu können.
Die SVCU-Anweisung kann bei Verwendung des Trägersystems UPIC entfallen, wenn in der upicfile ein Default-Server eingetragen ist, für den gilt
transaction-code = remote-service-name = internal-service-name.
Default-Server
Zur Vereinfachung der Client-Server-Konfiguration bietet Ihnen openUTM-Client die Möglichkeit, mit der Angabe DEST=.DEFAULT in der SVCU-Anweisung der Local Configuration File einen Default-Server zu vereinbaren.
Falls bei den Aufrufen tpcall(), tpacall() oder tpconnect() ein Service svcname2 verwendet wird, der keinen SVCU-Eintrag in der Local Configuration File besitzt, wird automatisch folgender Eintrag verwendet:
SVCU svcname2, RSN=svcname2, TAC=SCVname2, DEST=.DEFAULT, MODE=RR
UPIC erwartet dann in der upicfile einen passenden Default-Server-Eintrag, z.B.:
LN.DEFAULT localname SD.DEFAULT servername ND.DEFAULT servername
Zusätzlich besteht die Möglichkeit, einen Service svcname2@BRANCH9 komplett mit DEST=BRANCH9 aufzurufen, ohne einen Eintrag in der Local Configuration File anzulegen. In diesem Fall wird folgender Eintrag angenommen:
SVCU svcname2, RSN=svcname2, TAC=SCVname2, DEST=BRANCH9, MODE=RR
Der Partner, in diesem Fall BRANCH9, muss dem Trägersystem UPIC bekannt sein. Falls in der Local Configuration File aber ein Eintrag für den Service svcname2@BRANCH9 vorhanden ist, hat dieser Vorrang gegenüber der Default-Server-Annahme.
Operator | Operanden | Erläuterung |
|
| maximal 16 Byte |
| Standard: internal-service-name | |
| Standard: internal-service-name | |
| Partner-Anwendung | |
| RR=Request/Response, default CV=Conversation | |
| Standard: kein Subtyp |
internal-service-name
maximal 16 Byte langer Name, unter dem ein (ferner) Service im Programm angesprochen wird. Dieser Name muss innerhalb der Anwendung eindeutig sein, d.h. er darf in der LCF nur einmal vorkommen.
Pflichtoperand!
RSN=remote-service-name
maximal 16 Byte langer Name eines Services in der fernen Anwendung. Dieser Name wird an die ferne Anwendung übertragen; er darf in der LCF mehrfach vorkommen.
Wird dieser Operand weggelassen, dann setzt xatmigen für RSN den Wert internal-service-name ein.
TAC=transaction-code
maximal 8 Byte langer Transaktionscode, unter dem der Service in der fernen Anwendung generiert sein muss.
Wird dieser Operand weggelassen, dann setzt das Tool xatmigen für TAC den Wert internal-service-name ein und kürzt diesen ggf. auf die ersten 8 Byte.
Mit dem Transaktionscode KDCRECVR kann man einen Recovery-Service definieren, der die letzte Ausgabenachricht von openUTM erneut an den Client schickt.
DEST= destination-name / .DEFAULT
destination-name
Maximal 8 Byte lange Identifikation der Partner-Anwendung.
Dieser Name muss in der upicfile als Symbolic Destination Name angegeben werden, siehe Abschnitt „UPIC konfigurieren“.
.DEFAULT
Es wird ein Default-Server verwendet.
Pflichtoperand!
MODE=RR / CV
Bestimmt, welches Kommunikationsmodell für den Service verwendet wird:
RR CV | Request-Response Modell, Standardwert Conversational Modell |
BUFFERS=(subtype-1,...,subtype-n)
Liste von Subtyp-Namen, die an den Service geschickt werden dürfen (der Typ X_OCTET ist immer erlaubt). Jeder Name darf maximal 16 Byte lang sein, wobei alle Zeichen des ASN.1-Typs PrintableString erlaubt sind.
Für jeden hier aufgeführten Subtyp muss eine eigene BUFFER-Anweisung angegeben werden, mit der die Eigenschaften des Subtyps definiert werden (siehe BUFFER-Anweisung).
Der Operand BUFFERS= ist stellungs-sensitiv und muss (falls angegeben) immer der letzte Operand der Anweisung sein.
Wird BUFFERS= weggelassen, dann sollten an den Service nur Puffer vom Typ "X_OCTET" gesendet werden (eine Typüberprüfung findet nicht statt).
BUFFER-Anweisung
Eine BUFFER-Anweisung definiert einen typisierten Puffer. Gleichnamige Puffer müssen client- und serverseitig gleich definiert sein.
Mehrfachdefinitionen werden nicht überprüft. Der erste Puffer-Eintrag ist gültig, alle anderen werden ignoriert.
Puffer des Typs "X_OCTET" haben keine besonderen Eigenschaften und benötigen deshalb keine Definition. Typisierte Puffer werden mit folgenden Parametern definiert:
Operator | Operanden | Erläuterung |
|
| maximal 16 Byte |
| Standard: subtype-name | |
| Standard: xatmigen setzt TYPE |
subtype-name
Maximal 16 Byte langer Name des Puffers, der auch bei der SVCU-Anweisung im Operanden BUFFERS= angegeben werden muss. Der Name muss in der Anwendung eindeutig sein.
REC=referenced-record-name
Name der Datenstruktur für den Puffer, z.B. ist dies bei C-Strukturen der Name des "typedef" bzw. der "struct-Name".
Wird der Operand weggelassen, dann setzt xatmigen REC=subtype-name ein.
TYPE=
Typ des Puffers, näheres siehe Abschnitt „Typisierte Puffer“.
Wird der Operand weggelassen, dann setzt xatmigen den Typ auf X_C_TYPE oder X_COMMON, je nachdem, welche elementaren Datentypen verwendet wurden.
xatmigen erzeugt beim Generierungslauf zusätzlich zwei Operanden mit folgender Bedeutung:
LEN=länge
Länge des Datenpuffers.
SYNTAX=code
Syntaxbeschreibung der Datenstruktur in der Code-Darstellung, wie sie in der Tabelle auf "Typisierte Puffer" aufgeführt ist.