In diesem Abschnitt sind einige Besonderheiten aufgelistet, die Sie beim Binden und Starten von UTM-Anwendungen berücksichtigen müssen, die in den oberen Adressraum einer XS-Anlage geladen werden und im 31-Bit-Modus ablaufen sollen. Dabei werden Kenntnisse der XS-Programmierung und zum XS-Einsatz vorausgesetzt.
openUTM unterstützt nur Anwendungen, die:
entweder vollständig XS-fähig sind und im 31-Bit-Modus ablaufen oder
nicht XS-fähig ganz im unteren Adressraum (d.h. unterhalb 16 MByte) geladen sind und im 24-Bit-Modus ablaufen
Eine UTM-Anwendung kann also nur dann im oberen Adressraum (>16MByte) geladen werden und im 31-Bit-Modus ablaufen, wenn alle Bestandteile des UTM-Anwendungsprogramms XS-fähig sind.
ACHTUNG!
UTM-Anwendungen im „mixed mode“ (d.h. mit Umschaltung zwischen 24- und 31-Bit-Adressmodus) werden von openUTM nicht unterstützt. Das bedeutet, dass openUTM nicht für den ordnungsgemäßen Ablauf einer UTM-Anwendung garantiert, wenn z.B. ein Teilprogramm, das im 31-Bit-Modus abläuft, selbstständig Module im 24-Bit-Modus nachlädt und beim Übergang jeweils den Adressmodus umschaltet.
Übersetzen und Binden
Beim Übersetzen und Binden einer XS-fähigen UTM-Anwendung sind folgende Regeln zu berücksichtigen:
Alle Teilprogramme müssen mit den Attributen AMODE=ANY (Adressierungsmodus) und RMODE = ANY (Residenzmodus) übersetzt werden.
Beim Binden der UTM-Anwendung überprüft der Binder die Attribute AMODE und RMODE für alle Teilprogramme und legt für das erzeugte Bindemodul der UTM-Anwendung einen Pseudo-RMODE fest. Dabei orientiert er sich an der „schwächsten“ Komponente, d.h. das Modul erhält nur dann das Attribut RMODE=ANY, wenn alle Komponenten das Attribut RMODE=ANY haben. Wurde eine Komponente mit RMODE=24 übersetzt, dann wird dem Modul RMODE=24 zugeordnet.
Das Attribut AMODE wird durch den Programmabschnitt (CSECT) bestimmt, der die Einsprungstelle des Bindemoduls enthält.
Nähere Informationen finden Sie im BS2000-Handbuch „Bindelader-Starter“.
Besonderheiten beim Start einer UTM-Anwendung
Ob die UTM-Anwendung in den oberen oder unteren Adressraum geladen wird, ist abhängig vom UTM-Anwendungsprogramm selbst und vom Wert des Parameters PROGRAM-MODE, den Sie beim Aufruf des START-EXECUTABLE-PROGRAM-Kommandos angeben.
Bei PROGRAM-MODE=24 wird die Anwendung in den unteren Adressraum geladen und der 24-Bit-Modus wird eingestellt.
Bei PROGRAM-MODE=ANY:
Ob die Anwendung in den oberen oder unteren Adressraum geladen wird und welcher Adressierungsmodus eingestellt wird, ist abhängig von den Attributen AMODE und RMODE des Lademoduls (siehe Abschnitt „XS-Unterstützung von UTM-Anwendungen").Wenn das Binder-Lader-System (BLS) beim Starten der UTM-Anwendung feststellt, dass alle Bestandteile der UTM-Anwendung, die beim Start der Anwendung geladen werden, XS-fähig sind, dann wird die UTM-Anwendung in den oberen Adressraum geladen.
Soll openUTM in der Startphase einer in den oberen Adressraum geladenen Anwendung ein nicht XS-fähiges Modul nachladen, dann bricht openUTM den Startvorgang mit einer entsprechenden Fehlermeldung ab.
Zu beachten ist auch, dass von einem Anwendungsprogramm, das im oberen Adressraum läuft, im laufenden Betrieb kein 24-Bit-Modul (ONCALL) nachgeladen werden darf.
Um sicherzustellen, dass eine nicht-XS-fähige UTM-Anwendung in den unteren Adressraum geladen wird und im 24-Bit-Modus abläuft, müssen Sie beim Binden der UTM-Anwendung eine MODIFY-SYMBOL-ATTRIBUTES-Anweisung mit AMODE=24 einfügen.
Speicherbelegung von UTM-Anwendungen
Die Anwendungs-spezifischen Tabellen und Datenbereiche (KAA, KTA, Slots und UTM-Cache) legt openUTM im Klasse 5 Speicher im oberen Adressraum an. UTM-Anwendungen, die im unteren Adressraum laufen, wird dadurch kein Adressraum weggenommen. Der UTM-Cache kann per Generierung MAX CACHE auch in einen oder mehrere Datenräume gelegt werden.
Tools KDCDEF, KDCDUMP und KDCUPD
Die UTM-Tools KDCDEF, KDCDUMP und KDCUPD laufen nur im oberen Adressraum (> 16MByte) ab.