Natural-Objekte mit dem Natural-Nukleus verlinken

#### Search Results

Search

# Natural-Objekte mit dem Natural-Nukleus verlinken

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:

- Vorteile

- Dienstprogramm ULDOBJ

- ULDOBJ zur Generierung eines Objektmoduls benutzen

- Zusätzliche Überlegungen zur Verlinkung von Subroutinen

- Betriebssystemabhängigkeit der Objektmodulgenerierung

- Beispiel für die Verlinkung eines Natural-Objekts mit dem Natural-Nukleus

## Vorteile

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.

## Dienstprogramm ULDOBJ

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.

## ULDOBJ zur Generierung eines Objektmoduls benutzen

Um das ULDOBJ-Dienstprogramm aufzurufen:

1. 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____

2. 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).

## Zusätzliche Überlegungen zur Verlinkung von Subroutinen

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.

## Betriebssystemabhängigkeit der Objektmodulgenerierung

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.

## Beispiel für die Verlinkung eines Natural-Objekts mit dem Natural-Nukleus

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:

1. Identifizieren Sie die katalogisierten Objekte, die verlinkt werden sollen.

       Object         Library
       -------------- --------------
       LOGPROG        SYSLIB
       EDITPROG       SYSLIB

2. 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
       /*

3. 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)
       /*

4. 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.

5. Ü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.

### On this page

- Vorteile
- Dienstprogramm ULDOBJ
- ULDOBJ zur Generierung eines Objektmoduls benutzen
- Zusätzliche Überlegungen zur Verlinkung von Subroutinen
- Betriebssystemabhängigkeit der Objektmodulgenerierung
- Beispiel für die Verlinkung eines Natural-Objekts mit dem Natural-Nukleus