Starten der Anwendung und Eingabe von Test-Kommandos

Folgende Arbeitsschritte müssen Sie durchführen, wenn Sie eine Anwendung im Dialog zum Testen starten:

1. Sie öffnen eine $DIALOG-Session und starten in der Dialogtask Ihre UTM-Anwendung. Dabei gehen Sie vor wie im Produktivbetrieb, starten aber die Anwendung nicht, sondern laden sie nur mit LOAD-EXECUTABLE-PROGRAM. Das zugehörige Fenster wird im folgenden Taskfenster genannt. Mit LOAD-EXECUTABLE-PROGRAM werden alle fest eingebundenen Programme geladen. Wenn Sie z.B. ein Teilprogramm für einen Start-Exit testen wollen, können Sie nun Testkommados dafür eingeben.

2. Starten Sie das Programm mit %RESUME. openUTM liest die Startparameter ein und lädt alle Programme, die in Lademodulen enthalten sind, welche mit LOAD-MODE=STARTUP generiert sind. Dazu gehören auch shareable Teile (LOAD-MODE=(POOL/POOL,STARTUP).
   Damit Sie die Startparameter nicht händlisch eingeben müssen, führen Sie die Schritte 1 und 2 am besten über einer Prozedur aus.

3. Drücken Sie die Taste K2, damit das Programm unterbrochen wird und Sie Test-Kommandos eingeben können.
   Die K2-Taste wirkt dabei jedoch erst, wenn sich die UTM-Task im nicht-privilegierten Funktionszustand des BS2000 (TU) befindet. Das ist eventuell erst dann der Fall, nachdem Sie Schritt 4 durchgeführt haben.

4. Schließen Sie sich über einen UTM-Client an Ihre UTM-Anwendung an und melden Sie sich ggf. über eine Benutzerkennung bei der UTM-Anwendung an. Anschließend starten Sie ein Teilprogramm oder machen Ihre erste Benutzereingabe.

5. Jetzt müssen Sie im Taskfenster bestätigen, dass Sie Kommandos eingeben wollen (CMD0170 DO YOU WANT TO INSERT COMMANDS? REPLY (Y=YES; N=NO)?).
   Wenn Sie symbolisch testen wollen und die LSD-Informationen nicht statisch eingebunden sind, müssen Sie mit %SYMLIB symlib1, symlib2 ... die Bibliotheken zuweisen, in denen sich die LSD-Informationen befinden.
   Falls in Ihren Programmen Variablennamen mit Groß-/Kleinschreibung verwendet werden (C/C++-Teilprogramme) und Sie sich auf diese Namen beziehen wollen, müssen Sie mit dem Kommando %AID LOW die Voreinstellung von AID ändern.

   Nun können Sie Ihre Test-Kommandos eingeben, z. B. Haltepunkte setzen, siehe auch AID-Benutzerhandbücher.

   Mit RESUME-PROGRAM setzen Sie das UTM-Anwendungsprogramm fort.

   Beachten Sie bitte, dass mit LOAD-MODE=ONCALL generierte Lademodule erst dann geladen werden, nachdem sie einmal in einer Task aufgerufen wurden. Erst danach können Sie für diese Programme Testkommandos eingeben.

6. Der UTM-Client erhält nach der Bearbeitung des Dialogschrittes die Antwort auf die Eingabe; genauso wie im Produktivbetrieb.

Wenn Sie eine weitere Dialogtask starten wollen, müssen Sie die Schritte 1 und 2 wiederholen, anschließend wieder etwas vom UTM-Client aus eingeben und dann die in Schritt 4 durchgeführten Aktionen wiederholen. Falls Sie bei den Startparametern „TASKS=1“ angegeben haben, müssen Sie zunächst administrativ die Anzahl der Tasks erhöhen, da ansonsten der Startfehler 31 auftritt. Beachten Sie bitte, dass beim Testen im Dialog die zweite Task ein UTM-System-Prozess ist und deshalb ggf. drei Tasks gestartet werden müssen. Für das Testen im Dialog empfiehlt es sich deshalb, die Anwendung ohne UTM-System-Prozesse zu generieren (MAX SYSTEM-TASKS=0).

Bitte beachten Sie, dass Sie keine Batch-Tasks nachstarten können.

Sie können jederzeit weitere UTM-Clients an Ihre UTM-Anwendung anschließen, unabhängig davon, mit wie vielen Tasks die Anwendung läuft.

Hinweise

Beim Starten einer Anwendung im Dialog ergeben sich die folgenden Besonderheiten:

• Der KDCS-Aufruf PEND ER beendet das Programm nicht, das Programm wird somit auch nicht nachgeladen. Der Event-Exit SHUT wird nicht aufgerufen. Wollen Sie mit einem neu geladenen Programm weitertesten, so müssen Sie selbst das Programm beenden und neu starten. Wenn Sie mit einer Task arbeiten, so führt die Programmbeendigung gleichzeitig zum Anwendungsende.

• UTM-Dialog-Tasks werden durch das BS2000-System nicht gegenüber anderen Teilnehmer-Tasks priorisiert. Die Tasks laufen nicht als TP-Tasks, sondern als normale Dialog-Tasks. Der Cache-Speicher wird nicht resident eingerichtet (siehe openUTM-Handbuch „Anwendungen generieren“).

• Der Austausch des Anwendungsprogramms per Administration ist nicht möglich. Einzelne LLM’s können jedoch ausgetauscht werden (siehe „Austausch von Programmteilen" (Vorbereitungen für das Testen im Dialog)).

• Der Startparameter TASKS= legt lediglich die Obergrenze der Anzahl der Tasks fest, bewirkt aber keinen Start der Folgetasks. Jede gestartete Task belegt eine Teilnehmer-Task im BS2000-System.

• Das Kommando KDCAPPL TASKS=n bewirkt ebenfalls keinen Start der Folgetasks, sondern führt nur dazu, dass Sie manuell weitere Tasks für die Anwendung starten können. Siehe hierzu auch openUTM-Handbuch „Anwendungen generieren“.

• Einen UTM-Dump sollten Sie vor dem nächsten Start der Anwendung auswerten oder sichern (umkatalogisieren), weil die Dump-Datei sonst überschrieben werden kann.