Vorbereitungen für das Testen im Dialog

Im Dialog gestartete Anwendungen sind ausschließlich zum Testen vorgesehen. Unterschiede zu mit ENTER-JOB oder ENTER-PROCEDURE gestarteten Anwendungen bestehen darin, dass Tasks nicht automatisch nachgestartet werden und dass die UTM-STXIT-Behandlung ausgeschaltet werden kann.

Symbolisch testen

Wenn Sie symbolisch testen wollen, müssen Sie die Programme so übersetzen, dass der Compiler eine „List for Symbolic Debugging“ (LSD) erstellt (in COBOL zum Beispiel durch die Angabe COMOPT SYMTEST=ALL).

Sie sollten die LSD-Information nicht fest einbinden, da Sie diese Informationen im Bedarfsfall aus Ihrer Modulbibliothek nachladen können. Die ausgetesteten Programme können Sie dann direkt in den Produktivbetrieb übernehmen.

Austausch von Programmteilen

Die Angabe LOAD-MODE={ STARTUP | ONCALL} in der LOAD-MODULE-Anweisung kann vorteilhaft sein für das Testen Ihrer Teilprogramme und Event Exits. Nach einer Programmänderung und Neuübersetzung kann das Binden der Anwendung entfallen. Sie müssen nur das LLM neu binden, welches das geänderte Teilprogramm enthält. Wenn das LLM nur aus diesem Teilprogramm besteht, entfällt auch dieser Schritt. Sie aktivieren das geänderte Teilprogramm, indem Sie entweder die Anwendung neu starten oder bei laufender Anwendung das LLM austauschen (Kommando KDCPROG LOAD-MODULE= ..., VERS=...) oder über die Schnittstelle zur Programmadministration (opcode=KC_MO-DIFY_OBJECT) oder mit WinAdmin/WebAdmin.

Ist das geänderte Teilprogramm einem Lademodul zugeordnet, das mit LOAD-MODE=ONCALL generiert ist, dann muss das geänderte Teilprogramm eine andere Version haben als das bisher geladene Teilprogramm.

Parallelbetrieb für Versionsumstieg

Wenn Sie den Parallelbetrieb nutzen, können Sie den Aufwand bei einem Umstieg auf eine neue openUTM-Version wie folgt minimieren:

• Installieren Sie die neue openUTM-Version zusätzlich zu Ihrer aktuellen Version.

• Binden Sie Ihr Anwendungsprogramm (mit einem anderen Namen) mit der neuen Version, siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“.

• Testen Sie parallel zum Produktionsbetrieb.

Anzahl der Tasks beim Testen

Im Normalfall reicht es zum Testen aus, die Anwendung mit nur einer Task zu starten. Bestimmte Funktionalitäten einer UTM-Anwendung, wie z.B. Programme die PWGT-Aufrufe nutzen, lassen sich jedoch nur testen, wenn die Anwendung mit mehr als einer Task gestartet wird.

Wollen Sie eine Anwendung im Dialog mit mehreren Tasks starten, so beachten Sie bitte folgende Hinweise:

• Es ist nicht möglich, Tasks im Dialog und im Batch-Betrieb gemischt zu starten.

• Folgetasks können Sie nicht per Administrationskommando starten, sondern nur „von Hand“ an einem Terminal bzw. in einem eigenen Fenster.

• die AID-Kommandos müssen für jede Task wiederholt werden, da eine Benutzeranforderung von einer nicht vorherbestimmbaren Task der Anwendung bearbeitet wird. Um den Aufwand der wiederholten Eingabe von Kommandos beim Test im Mehrtaskbetrieb zu vermeiden, können die erforderlichen AID-Kommandos schon in die Startprozedur eingefügt werden.

• Wenn Sie eine OSI TP-Anwendung in mehreren Dialog-Tasks testen und beenden, sollte die Anwendung in denselben Dialog-Tasks nicht noch einmal gestartet werden, da dies zu Startfehlern bzw. zu abnormalem Anwendungsende führen kann.

Eine Dialog-Task arbeitet nur so lange für die Anwendung, wie das Programm geladen bleibt. Nach einer Programmbeendigung können Sie mit der Task im BS2000-Teilnehmerbetrieb beliebig weiterarbeiten. Wenn Sie nur mit einer Task arbeiten, so führt jede Programmbeendigung zum Ende der Anwendung.