Der Natural-Nukleus ist eine Sammlung von Dienstprogrammen wie Speicherverwaltung, String-Handling, Betriebssystemschnittstellen, Compiler und Laufzeitumgebung, die den Kern von Natural bilden. Er ist unabhängig von Betriebssystem und TP-System.
Der Natural-Nukleus besteht aus dem umgebungsunabhängigen und dem umgebungsabhängigen Nukleus. Der umgebungsunabhängige Nukleus kann von mehreren Großrechner-Betriebs- und TP-Systemen verwendet werden. Der umgebungsabhängige Nukleus enthält Komponenten, die von den Betriebs- und TP-Systemen abhängen. Weitere Informationen finden Sie unter Natural Nucleus Components in der Installation for z/OS-Dokumentation.
Dieses Kapitel beschreibt die Vorteile der Verlinkung von Natural-Objekten mit dem Natural-Nukleus und gibt Informationen über die Vorgehensweise. Folgenden Themen werden behandelt:
Die Verlinkung von Natural-Objekten mit dem Natural-Nukleus bietet folgende Vorteile:
Bessere Performance
Die Objekte werden aus dem Nukleus und nicht aus dem Natural
Buffer Pool ausgeführt. Das spart Platz im Buffer Pool und führt auch zu
weniger Datenbankaufrufen. (Wenn katalogisierte Natural-Objekte nicht mit dem
Natural-Nukleus verknüpft sind, werden sie in einer Datenbankdatei gespeichert,
z.B. in Adabas, und der eigentliche Code muss aus dieser Datei in den Buffer
Pool geladen werden, bevor er ausgeführt werden kann).
Konsistenz
Da ein Objekt, das mit dem Natural-Nukleus verlinkt ist, immer
vom Nukleus ausgeführt wird, hat es keine Auswirkungen, wenn das katalogisierte
Objekt, von dem es abgeleitet wurde, in der Natural-Systemdatei gelöscht oder
geändert wird. Somit bleibt der Status des Objekts während jeder
TP-Monitor-Sitzung unverändert. Eine neue Version eines Objekts, das mit dem
Nukleus verlinkt ist, erhalten Sie, indem Sie es mit dem Dienstprogramm ULDOBJ
(siehe unten) entladen, die neue Version erneut mit dem Natural-Nukleus
verlinken und das Natural-Modul aktualisieren. (Aktualisieren bedeutet, dass
eine neue Kopie eines Moduls in die TP-Monitor-Region geladen wird).
Globale Fehlerbehandlung
Wenn ein katalogisiertes Objekt ein anderes Programm zur
Fehlerbehandlung aufruft (z. B. über die Natural-Systemvariable
*ERROR-TA)
und das Fehlerbehandlungsprogramm nicht in den Buffer Pool geladen werden kann,
kann der ursprüngliche Fehler möglicherweise nicht erkannt werden und jeder
nachfolgende Fehler kann den ersten Fehler maskieren und zu Verwirrung führen.
Um diese Situation zu vermeiden, können Sie ein vom Benutzer geschriebenes
globales Fehlerbehandlungsprogramm mit dem Nukleus verknüpfen.
Mit dem Dienstprogramm ULDOBJ können Sie katalogisierte Natural-Objekte mit dem Natural-Nukleus verlinken. Mit dem Dienstprogramm ULDOBJ erzeugen Sie ein Objektmodul aus einem katalogisierten Natural-Objekt und schreiben es in eine Natural-Arbeitsdatei. Der generierte Objektbaustein wird dann vom Linkage Editor verarbeitet und mit dem Natural-Nukleus verlinkt.
Wenn ein umgebungsunabhängiger Natural-Nukleus verwendet wird, muss das generierte Objektmodul mit dem umgebungsunabhängigen Teil des Nukleus verknüpft werden.
Um das ULDOBJ-Dienstprogramm aufzurufen:
Melden Sie sich in der Library SYSMISC an und
geben Sie das Kommando ULDOBJ ein.
10:08:14 ***** NATURAL OBJECT MAINTENANCE ***** 2023-05-31
User: XYZ - NATURAL ULDOBJ UTILITY - Library: SYSMISC
Opsys .. z/OS
Specify parameters below ....
Object ...... ________ (Enter '.' to exit)
Library ..... SYSMISC_
OP System ... z/OS____
|
Geben Sie die folgenden Parameter an und bestätigen Sie sie:
Object |
Der Name des katalogisierten Objekts, das
verarbeitet werden soll. Das Objekt kann ein Programm, ein Subprogramm, eine
Subroutine, eine Helproutine oder eine Map (Maske) sein.
Sie können einen Punkt (.) eingeben, um die Utility-Ausführung zu beenden (siehe unten). |
Library |
Der Name der Library, die das katalogisierte Objekt enthält. |
OP System |
Der Name des Betriebssystems, für das der Objektbaustein generiert werden soll. Der Name des Betriebssystems muss z/OS sein. |
Für jedes verarbeitete Objekt zeigt das Dienstprogramm ULDOBJ einen Report an, der die folgenden Informationen enthält:
den Objekttyp (Programm, Subprogramm, Subroutine, Helproutine, Map, Adapter); siehe Objekte zum Erstellen und Pflegen von Natural-Anwendungen im Leitfaden zur Programmierung,
den Namen des bearbeiteten katalogisierten Objekts,
den Programmiermodus (S = Structured Mode, R = Reporting Mode),
den Namen der Library, die das katalogisierte Objekt enthält,
den Namen des Betriebssystems, für das das Objekt erzeugt wurde,
die Größe des katalogisierten Objekts und des optimierten Codes (falls zutreffend),
die Natural-Version des katalogisierten Objekts (siehe Version im Glossar),
Statistiken über die letzte Katalogisierung des Objekts, einschließlich Benutzer- und Terminalkennungen (IDs).
ULDOBJ fordert die Eingabe eines weiteren Objekts und einer weiteren Library an, nachdem die Daten der ersten Eingabe verarbeitet wurden. Das Betriebssystem wird nicht abgefragt, da es nicht sinnvoll ist, für dieselbe Natural-Arbeitsdatei Objektmodule für mehr als ein Betriebssystem zu generieren.
Um das Dienstprogramm ULDOBJ zu beenden:
Nachdem das letzte katalogisierte Objekt bearbeitet wurde,
geben Sie im ersten Eingabefeld (Object) einen Punkt (.) ein und
drücken Sie ENTER.
Das generierte Objektmodul entspricht dem Format des angegebenen Betriebssystems. Er hat ein verschiebbares Format (Relocation) mit nicht ausführbarem Code und besteht aus:
einem externen Symbolverzeichnis (ESD),
einem Relocation Dictionary (RLD),
Text mit den Anweisungen und Daten, die dem Programm entsprechen,
einem END-Statement
(End-of-Module-Indikator für das Lademodul).
Das generierte Objektmodul wird in eine Natural-Arbeitsdatei geschrieben, die als Eingabe für einen Linkage Editor verwendet wird.
Das generierte Objektmodul muss vom Linkage Editor
verarbeitet werden, bevor der Code als Load-Modul ausführbar ist
(siehe
Beispiel
weiter unten). Jedes Load-Modul ist gültig, sobald es mit dem Natural-Nukleus
verlinkt und durch eine NTSTAT-Eintragsdefinition im
Natural-Konfigurationsmodul NATCONFG definiert ist (siehe
Natural-Konfigurationstabellen).
Nachdem ein katalogisiertes Objekt vom Dienstprogramm ULDOBJ entladen und mit dem Natural-Nukleus verlinkt wurde, kann das katalogisierte Objekt aus der Natural-Systemdatei gelöscht werden.
Dies gilt jedoch nicht für ein Objekt des Typs Subroutine. Eine Subroutine hat zwei Namen:
den in den Statements PERFORM und
DEFINE SUBROUTINE
angegebenen Namen und
den Namen des Objekts, das das Statement DEFINE
SUBROUTINE enthält.
Natural verknüpft intern diese beiden Namen, was jedoch nur möglich ist, wenn das katalogisierte Objekt noch in der Natural-Systemdatei vorhanden ist. Würde das katalogisierte Objekt gelöscht, ginge diese Zuordnung verloren und die mit dem Nukleus verlinkte Subroutine wäre nicht ausführbar.
Eine NAME-Steueranweisung wird als letzte Karte des
Objektmoduls generiert. Sie spezifiziert die Ersetzungsfunktion. Zum
Beispiel:
NAME TEST (R)
TEST ist der Name des katalogisierten Objekts.
Wenn zum Beispiel die Objekte LOGPROG und
EDITPROG in der Library SYSLIB mit dem
Natural-Nukleus verknüpft werden sollen, könnten folgende Schritte durchgeführt
werden:
Identifizieren Sie die katalogisierten Objekte, die verlinkt werden sollen.
Object Library -------------- -------------- LOGPROG SYSLIB EDITPROG SYSLIB
Erstellen Sie den Batch Natural Job Stream. In einer z/OS-Umgebung sollten Sie die folgenden Karten verwenden:
//CMWKF01 DD DSN=ULD.NAT.PGMS,UNIT=SYSDA,DISP=(,KEEP), // SPACE=(CYL,(3,1),,RLSE),VOL=SER=VVVVVV, // DCB=(RECFM=FB,BLKSIZE=800,LRECL=80) //CMSYNIN DD * LOGON SYSMISC ULDOBJ LOGPROG,SYSLIB,OS EDITPROG,SYSLIB . FIN /*
Erstellen Sie den Jobfluss für den Linkage Editor.
//JOBCARD JOB (ACCTING),CLASS=A,MSGCLASS=X //* //* GENERATE OS LOAD MODULE FROM ULDOBJ UTILITY //* //LINK1 EXEC PGM=IEWL,PARM='LIST,LET,XREF,NCAL,RENT,REUS' //SYSLMOD DD DSN=NATURAL.USER.LOAD,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(1024,(200,20)) //SYSPRINT DD SYSOUT=X //SYSLIN DD DSN=NAT.ULD.PGMS,DISP=OLD,UNIT=SYSDA,VOL=SER=VVVVVV /*
In diesem Schritt werden die Lademodule LOGPROG und
EDITPROG in den Dataset NATURAL.USER.LOAD
gestellt.
Mit einem zusätzlichen Link-Edit-Job können diese Module als ein einziges Lademodul miteinander verknüpft werden, bevor sie in Schritt 5 mit dem Nukleus verknüpft werden.
//JOBCARD JOB (ACCTING),CLASS=A,MSGCLASS=X //* //* OPTIONAL JOB TO LINK CATALOGED OBJECTS TOGETHER //* //LINK2 EXEC PGM=IEWL,PARM='LIST,LET,XREF,NCAL,RENT,REUS' //SYSLMOD DD DSN=NATURAL.USER.LOAD,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(1024,(200,20)) //SYSPRINT DD SYSOUT=X //SYSLIN DD * INCLUDE SYSLMOD(LOGPROG) LOGON NATURAL PGM INCLUDE SYSLMOD(EDITPROG) EDITOR NATURAL PGM NAME XXXXXX(R) /*
Definieren Sie die statisch verlinkten Natural-Programme im
Quellcode-Modul NATCONFG in der Tabelle NSTATIC für
verlinkte Natural-Programme:
NTSTAT INPL,TYPE=W NTSTAT INPLLIB,TYPE=W NTSTAT AERROR,TYPE=W NTSTAT LOGPROG <==== Ihre Einträge NTSTAT EDITPROG <====
TYPE=W bedeutet, dass eine "schwache"
externe Referenz auf das angegebene Programm anstelle einer normalen Referenz
erzeugt wird.
Überprüfen Sie den Jobfluss des Linkage Editor für den Natural-Nukleus und fügen Sie Folgendes hinzu:
//* //* INCLUDE DDNAME AND DSN OF DATASET WHERE OBJECTS RESIDE //* //SYSLMOD DD DSN=NATURAL.USER.LOAD,DISP=SHR //NATLIB DD DSN=NATURAL.USER.LOAD,DISP=SHR//* //SYSLIN DD* ... ... INCLUDE MODULES FOR NUCLEUS ... INCLUDE NATLIB(nat-parm-module) NATURAL PARAMETER MODULE INCLUDE SYSLMOD(LOGPROG) LOGON NATURAL PGM INCLUDE SYSLMOD(EDITPROG) EDITOR NATURAL PGM ... ... INCLUDE ENTRY AND NAME CARDS ... /*
nat-parm-module steht
für den Namen des Natural-Parametermoduls.
Wenn die katalogisierten Objekte miteinander verlinkt wurden (wie in Schritt 3 optional geschehen), fügen Sie dieses Lademodul anstelle der einzelnen Lademodule in den Link des Nukleus ein.
