Das Anwendungsprogramm wird durch das Kommando START-EXECUTABLE-PROGRAM gestartet. Dabei gilt Folgendes:
Falls shareable Teile der Anwendung oder der von der Anwendung benötigten Laufzeitsysteme in den Systemspeicher geladen werden sollen, so muss dies noch vor dem Start des Anwendungsprogramms durch den Administrator veranlasst werden.
Das START-EXECUTABLE-PROGRAM-Kommando bewirkt, dass der statisch gebundene Teil des Anwendungsprogramms in den Arbeitsspeicher geladen wird. Alle Lademodule des Anwendungsprogramms, die mit LOAD-MODE=STARTUP oder LOAD-MODE=(POOL,...) generiert wurden, werden beim Start der Anwendung als eigenständige Einheiten nachgeladen.
Können einzelne Lademodule nicht geladen werden, so wird i.a. der Start der Anwendung fortgesetzt. Soll im Betrieb der Anwendung ein Programm angesprungen werden, das nicht geladen werden konnte, so führt dies zum Aufruf des Event-Services BADTACS oder zu einem PEND ER. Wenn die Event-Services MSGTAC, SIGNON oder die Event-Exits START, SHUT, INPUT und FORMAT oder das Administrations-Teilprogramm oder AREAs nicht geladen werden können, wird der Start der Anwendung mit einer Fehlermeldung abgebrochen.
Beim Starten einer zusätzlichen Task für die Anwendung sowie nach einem PEND ER prüft openUTM anhand der Generierungsinformationen, ob das in dieser Task geladene Anwendungsprogramm mit dem in den zuvor gestarteten Tasks übereinstimmt. Bei fehlender Übereinstimmung bricht openUTM den Start der Folge-Task mit einer Fehlermeldung ab.
Startkommandos für das Anwendungsprogramm
Das Anwendungsprogramm wird gestartet mit:
/START-EXECUTABLE-PROGRAM FROM-FILE=*LIB-ELEM - / ( LIB=llm-plamlib - / , ELEM=start-llm - / )
Das Anwendungsprogramm start-llm muss als Element vom Typ L in einer Programmbibliothek llm-plamlib bereitgestellt werden.
Wenn Sie ein Lademodul mit ALTERNATE-LIBRARIES=YES generiert haben, dann müssen Sie vor dem Start des Anwendungsprogramms der Bibliothek des betreffenden Laufzeitsystems einen Linknamen (BLSLIBnn mit 00<=nn<=99) zuweisen.
Sie können sich mit dem BS2000-Kommando
/MODIFY-DBL-DEFAULT PRIORITY=*FORCED, SCOPE=*ALL(PROGRAM-MAP=...)
eine DBL-Liste über die dynamischen Ladevorgänge während des Betriebs der Anwendung ausgeben lassen. Da dies aber den Startvorgang bzw. den Programmaustausch verzögert, sollten Sie von dieser Möglichkeit nur im Test- oder Fehlerfall Gebrauch machen.
Wenn Teile des Anwendungsprogramms zu einem späteren Zeitpunkt nachgeladen werden sollen, müssen Sie beim Starten die folgenden Operanden angeben:
/ ,DBL-PARAMETERS = *PARAMETERS( - / ,LOADING = *PARAMETERS( - / PROGRAM-MODE = *ANY - / ,LOAD-INFORMATION = *REFERENCES) - / ,RESOLUTION = *PARAMETERS( - / ALTERNATE-LIBRARIES = *BLSLIB## - / ,AUTOLINK = *ALTERNATE-LIBRARIES ) - / ,ERROR-PROCESSING=*PARAMETERS( - / UNRESOLVED-EXTRNS=*DELAY - / ,ERROR-EXIT = *NONE))
Die folgende Liste zeigt die Möglichkeiten, wie Sie die Autolink-Funktion beeinflussen können:
Wenn Sie die Autolink-Funktion während des Starts nicht benötigen und Sie im Start-LLM unbefriedigte Externverweise haben, sollten Sie die Funktion mit AUTOLINK=*NO unterdrücken.
Mit AUTOLINK=*YES,ALTERNATE-LIBRARIES=*NO wird die Bibliothek aus dem Ladeaufruf durchsucht.
Mit AUTOLINK=*ALTERNATE-LIBRARIES,ALTERNATE-LIBRARIES=*TASKLIB/*BLSLIB## werden Tasklib und/oder die BLS-Libs durchsucht.
Mit AUTOLINK=*YES,ALTERNATE-LIBRARIES=*TASKLIB/*BLSLIB## werden die Bibliothek aus dem Ladeaufruf sowie Tasklib und/oder BLS-Libs durchsucht.
Wenn das Start-LLM beim Start keine offenen Externverweise auf den Shared Code besitzt, sollte das Suchen des DBL im Shared Code mit dem Startoperanden SHARE-SCOPE=*NONE unterbunden werden.
Beim Start der Anwendung lädt openUTM zunächst alle Lademodule, die shareable in Common Memory Pools (LOAD-MODE=POOL) gehalten werden sollen. Dabei werden zuerst die Common Memory Pools geladen, die mit SCOPE=GLOBAL generiert wurden und danach diejenigen mit SCOPE=GROUP, jeweils in der bei der Generierung angegebenen Reihenfolge. Anschließend lädt openUTM alle Lademodule, die mit LOAD-MODE=STARTUP generiert wurden, ebenfalls in der Reihenfolge, in der Sie die LOAD-MODULE-Anweisungen bei der UTM-Generierung angegeben haben.
Lademodule, die mit LOAD-MODE=ONCALL generiert wurden, werden erst beim Aufruf eines Teilprogramms dieses Lademoduls geladen.
Verschiedene UTM-Anwendungen sollten möglichst unter unterschiedlichen BS2000-Benutzerkennungen gestartet werden, um Fehler zu vermeiden, die wegen gleicher Modulnamen in shareable Teilen auftreten können. Module, die von mehreren Anwendungen benutzt werden, sollten daher in anwendungsglobale Common Memory Pools oder in nichtprivilegierte Subsysteme geladen werden.
Mit openUTM wird auch eine Beispiel-Startprozedur ausgeliefert, siehe Abschnitt „Beispielprozeduren".
Starten einer Anwendung mit TLS-Verbindungen
Ist für eine UTM-Anwendung ein BCAMAPPL mit T-PROT=(SOCKET,...,SECURE) generiert, dann erfolgt die Kommunikation über diesen Transportsystemzugangspunkt über Transport Layer Security (TLS). Dazu wird von openUTM beim Start einer so generierten Anwendung eine zusätzliche Task gestartet, in der ein Reverse Proxy zum Ablauf kommt, über den in Form eines TLS Termination Proxy alle TLS-Verbindungen abgewickelt werden. Die Task mit dem Reverse Proxy wird mit dem Jobnamen "SSLPROXY" gestartet. Beim Beenden der Anwendung wird auch der Reverse Proxy beendet.
Der Reverse Proxy schreibt eine SYSOUT-Datei mit folgendem Muster: <APPLNAME>.<JOBNAME>.<TSN>.YYYY-MM-DD-HH:MM:SS . Diese Datei wird um Mitternacht umgeschaltet.
Der Reverse Proxy kommuniziert mit HTTPS-Clients über TLS-Verbindungen und mit der UTM-Anwendung über eine Rechner-lokale Socket-Verbindung. Der Reverse Proxy muss dazu auf dem gleichen Rechner ablaufen wie die UTM-Anwendung.
Als Voraussetzung für den Start eines Reverse Proxy für eine UTM-Anwendung muss eine Jobvariable mit dem Basisnamen der KDCFILE katalogisiert sein. Dazu wird das Produkt JV ("Jobvariable") benötigt. Diese Jobvariable dient zum geordneten Beenden des Proxy Prozesses.
openUTM startet die Task mit dem Reverse Proxy über eine ENTER-Prozedur, die mit dem Namen START-SSL-PROXY in der Bibliothek SYSLIB.UTM.070.SSL abgelegt ist. Bei Bedarf kann diese Prozedurdatei an die Bedürfnisse des Anwenders angepasst werden.
In diesem Falle sollte die Prozedur aus der Bibliothek geholt und entsprechend angepasst werden.
Beim Starten der Anwendung wird der Startparameter „START-SSL-PROC“ mit dem Namen dieser Prozedur und evtl. gewünschten Ablauf-Parametern angegeben. Die benötigten Prozedur-Parameter wie filebasename, Listenerports etc. werden von openUTM versorgt.
Ist kein Startparameter angegeben so wird die Prozedur aus der o.g. Bibliothek gestartet.
Die Task mit dem Reverse Proxy liest SSL-Konfigurationsparameter von der SAM-Datei
<filebase>.SSL.CONF
Eine solche Datei mit Namen FILEBASE.SSL.CONF wird von openUTM als Beispiel mit ausgeliefert. Auch diese befindet sich in der Bibliothek SYSLIB.UTM.070.SSL. Sie muss vom Anwender für seine Anwendung umbenannt und in die Kennung kopiert werden, in der die UTM-Anwendung gestartet wird. Vor dem Start der Anwendung muss der Anwender die Einträge in dieser Datei an seine Umgebung und Bedürfnisse anpassen.
Folgende Parameter können in dieser Datei konfiguriert werden.
CACertificateFile
In der Option CACertificateFile wird eine Datei angegeben, die die für die Authentifizierung des Reverse Proxy erforderlichen CA-Zertifikate im PEM-Format enthält.
CipherSuite
Mit der Option CipherSuite wird eine Verschlüsselungsverfahren-Vorzugsliste spezifiziert.
Falls diese Option nicht angegeben wird, dann wird eine voreingestellte Vorzugsliste verwendet.
DSACertificateFile
In der Option DSACertificateFile wird eine Datei angegeben, die das DSA-basierte X.509-Server-Zertifikat im PEM-Format enthält.
Diese Datei kann auch den privaten DSAServer-Schlüssel enthalten. In der Regel werden aber Zertifikat und Schlüssel in getrennten Dateien abgelegt. In diesem Fall wird die Schlüsseldatei mithilfe der Option DSAKey-File spezifiziert.
DSAKeyFile
In der Option DSAKeyFile wird eine Datei angegeben, die den privaten DSA-Server-Schlüssel im PEM-Format enthält.
Wenn sowohl X.509-Server-Zertifikat als auch privater Server-Schlüssel innerhalb derselben Datei enthalten sind, dann braucht die Option DSAKeyFile nicht angegeben werden.
RSACertificateFile
In der Option RSACertificateFile wird eine Datei angegeben, die das RSA-basierte X.509-Server-Zertifikat im PEM-Format enthält.
Diese Datei kann auch den privaten RSA-Server-Schlüssel enthalten. In der Regel werden aber Zertifikat und Schlüssel in getrennten Dateien abgelegt. In diesem Fall wird die Schlüsseldatei mithilfe der Option RSAKeyFile spezifiziert.
RSAKeyFile
In der Option RSAKeyFile wird eine Datei angegeben, die den privaten RSA-Server-Schlüssel im PEM-Format enthält.
Wenn sowohl X.509-Server-Zertifikat als auch privater Server-Schlüssel innerhalb derselben Datei enthalten sind, dann braucht die Option RSAKeyFile nicht angegeben werden.
ECDSACertificateFile
In der Option ECDSACertificateFile wird eine Datei angegeben, die das ECDSA-basierte X.509-Server-Zertifikat im PEM-Format enthält.
ECDSAKeyFile
In der Option ECDSAKeyFile wird eine Datei angegeben, die den privaten ECDSA-Server-Schlüssel im PEM-Format enthält.
Weitere Einzelheiten zur Syntax und Bedeutung der Optionen, sowie zum Erzeugen der Zertifikat- und Schlüsseldateien sind im Handbuch "interNet Services Benutzer V3.4B" im Kapitel "SSL",
sowie im Handbuch "interNet Services Administrator V3.4B" im Kapitel "TELNET Konfiguration" beschrieben.