COBOL-Teilprogramm als Unterprogramm

UTM-Teilprogramme und Event-Exits sind Unterprogramme der UTM Main Routine.Daraus ergeben sich folgende Konsequenzen:

• Der Programmname definiert die Einsprungadresse.

• In der LINKAGE SECTION muss mindestens eine Datenstruktur definiert werden.

• Das Teilprogramm wird dynamisch mit dem PEND-Aufruf beendet; eine Ausnahme bilden die Event-Exits, die mit der Anweisung EXIT PROGRAM verlassen werden. Die Anweisung "STOP RUN" ist verboten (Ausnahme: Event-Exits START und SHUT).

Um kompatibel zu sein und mit fehlerfreien Datenstrukturen zu arbeiten, stehen Ihnen eine Reihe von COPY-Elementen zur Verfügung. Die Verwendung dieser COPY-Elemente wird in Abschnitt „Datenstrukturen für COBOL-Teilprogramme" beschrieben.

PROGRAM-ID als Einsprungname

Im PROGRAM-ID-Paragraphen legen Sie den Einsprungnamen des Teilprogramms fest. Dieser Name ist frei wählbar. Er muss innerhalb eines Anwendungsprogramms eindeutig sein. Es dürfen keine Namenskonflikte zwischen dem Programmnamen und den Laufzeitsystemen, den Datenbanksystemen, dem Formatierungssystem, Kommunikationskomponenten und openUTM entstehen.

Bei der Namenswahl sollten Sie deshalb folgende Punkte beachten:

• Für BS2000-Systeme:

  • Alle Namen, die mit KDC, KC oder I beginnen, sind reserviert.

• Für Unix-, Linux- und Windows-Systeme:

  • Alle Namen, die mit KDC, KC , x oder ITS beginnen, sind reserviert.

  • Namen, die mit t_ beginnen, sind für CMX bzw. PCMX reserviert.

  • Namen, die mit a_, o_ oder s_ beginnen, sind für OSS reserviert.

• Der Name muss den COBOL-Konventionen entsprechen.

Den Programmnamen (Einsprungnamen) müssen Sie auch bei der Generierung der UTM-Anwendung angeben, und zwar jeweils in der KDCDEF-Anwendung PROGRAM (siehe openUTM-Handbuch „Anwendungen generieren“).

Beachten Sie die Hinweise im Handbuch des COBOL-Compilers, die sich auf die Behandlung von Programmnamen in der IDENTIFICATION DIVISION und im CALL-Aufruf beziehen.

WORKING-STORAGE SECTION

Die WORKING-STORAGE SECTION verwenden Sie vorwiegend für konstante Daten.

Um die Kompatibilität der Teilprogramme zu erreichen und ihre Lesbarkeit zu erhöhen, stehen Ihnen Konstanten mit fest vereinbarten KDCS-Namen als COPY-Elemente zur Verfügung.

Es ist sinnvoll, nur Felder mit festen Werten in die WORKING-STORAGE SECTION zu legen. Wenn Sie Ihre Bereiche mit variablen Daten ebenfalls in die WORKING-STORAGE SECTION legen möchten, können Sie hier auch den KDCS-Parameterbereich und den Nachrichtenbereich definieren. Da es aber wegen Speicherplatzeinsparung sinnvoll ist, sie im SPAB unterzubringen, werden diese Bereiche im folgenden Abschnitt beschrieben.

LINKAGE SECTION

Die LINKAGE SECTION verwenden Sie für die Parameterübergabe und als Arbeitsbereich.

Jedes Teilprogramm muss in der LINKAGE SECTION eine Datenstruktur mit Stufennummer 01 enthalten, die den KDCS-Kommunikationsbereich beschreibt.

Eine weitere Datenstruktur mit der Stufennummer 01 kann folgen. Sie beschreibt den Standard Primären Arbeitsbereich (SPAB). Im SPAB können Sie den KDCS-Parameterbereich und die Nachrichtenbereiche unterbringen.

Die Datenstrukturen von KB und KDCS-Parameterbereich sind als COPY-Elemente vorhanden (KCKBC bzw. KCPAC).

Die Nachrichtenbereiche müssen Sie selbst definieren. Für Aufrufe, die Informationen von openUTM anfordern (z.B. INFO, INIT PU) stehen jedoch spezifische Datenstrukturen in COPY-Elementen zur Verfügung. Falls Sie mit einem Formatierungssystem arbeiten, können Sie für die Strukturierung des Nachrichtenbereichs automatisch generierte Adressierungshilfen verwenden (siehe Handbuch des Formatierungssystems).

Beispiel

LINKAGE SECTION.
    COPY KCKBC.                       1)
    05   KB-BELIEBIG      PIC X(22).  2)
    05   KB-STARTORT      PIC X(2).   2)
    05   KB-ZIELORT       PIC X(2).   2)
    05   KB-FLGTAG        PIC X(5).   2)
    05   KB-FLGNR1        PIC X(5).   2)
    05   KB-FLGNR2        PIC X(5).   2)
    COPY KCPAC.                       3)
    03   NB.                          4)
    COPY IFORMA3.                     4)

¹⁾ KDCS-Kommunikationsbereich.
²⁾ Anwender-spezifische Deklaration des KB-Programmbereichs
³⁾ SPAB mit KDCS-Parameterbereich.
⁴⁾ Nachrichtenbereich. Die COPY-Anweisung holt die Eingabe-Adressierungshilfe für das Format "FORMA3".

Erweiterung der LINKAGE SECTION

Zusätzlich zum Kommunikationsbereich und dem SPAB können Sie noch weitere Bereiche in die LINKAGE SECTION legen, die dann als gemeinsame Datenbereiche innerhalb einer UTM-Anwendung verwendet werden können.

Solche Bereiche vereinbaren Sie mit der KDCDEF-Anweisung AREA. Näheres hierzu finden Sie im openUTM-Handbuch „Anwendungen generieren“.

In COBOL-Teilprogrammen können Sie AREA-Bereiche wie folgt einsetzen:

• In der LINKAGE SECTION definieren Sie diesen Bereich mit der Stufennummer 01.

• In der PROCEDURE DIVISION geben Sie diesen Bereich bei USING mit an.

Dabei spielt auch die Reihenfolge eine Rolle, in der diese Bereiche mit der AREA-Anweisung definiert wurden. Wird der an n-ter Stelle definierte Bereich benötigt, so müssen Sie sowohl in der LINKAGE SECTION als auch in der PROCEDURE DIVISION bei USING alle Bereiche bis zu diesem angeben.

Diese Funktion gehört nicht zur DIN-Norm 66 265.

Beispiel 1

Die Bereiche BEREICH1, BEREICH2 und BEREICH3 sind in dieser Reihenfolge mit der AREA-Anweisung definiert worden. In einem Teilprogramm wird BEREICH3 benötigt. Alle Bereiche sind in der Länge 2000 definiert.

      .
      .
LINKAGE SECTION.
    COPY KCKBC.
      .
      .
    COPY KCPAC.
      .
      .
      .
01 BEREICH1  PIC X(2000).
01 BEREICH2  PIC X(2000).
01 BEREICH3  PIC X(2000).
      .
      .
PROCEDURE DIVISION USING KCKBC, KCSPAB, BEREICH1, BEREICH2, BEREICH3.
      .

Beispiel 2: Teilprogramm in COBOL (auf Unix-, Linux- und Windows-Systemen)

Im Folgenden werden zwei Areas generiert, in einer C-Source definiert (siehe "Weitere Datenbereiche (AREAs)") und an ein Teilprogramm übergeben. Definiert werden:

• die Area area für den direkten Zugriff, d.h. der Datenbereich wird direkt an das Teilprogramm übergeben, und

• die Area areaind für den indirekten Zugriff.

  IDENTIFICATION DIVISION. 
  PROGRAM-ID. COBAREA. 
  ENVIRONMENT DIVISION. 
  DATA DIVISION. 
  WORKING-STORAGE SECTION. 
  LINKAGE SECTION. 
      COPY KCKBC. 
      05 PROG PIC X. 
      COPY KCPAC. 
      03 NB PIC X(4000). 
  01 AREA1 PIC X(20).
  01 AREA2 PIC X(30). 
  PROCEDURE DIVISION USING KCKBC KCSPAB AREA1 AREA2. 
      MOVE AREA1 TO BUFFER. 
      MOVE AREA2 TO BUFFER1. 
      PERFORM INIT-OP. 
  . 
  . 
  . 
  

Alternative zu AREAs

Falls Teilprogramme, die AREAs verwenden, aus einer Anwendung in eine andere Anwendung übernommen werden sollen, kann die Verwendung von AREAs auf Grund ggf. unterschiedlicher Parameterleisten zu Problemen führen. Deshalb ist es empfehlenswert, an Stelle von AREAs, Datenerklärungen mit der EXTERNAL-Klausel zu verwenden. In diesem Fall entfällt die AREA-Deklaration in KDCDEF sowie die AREA-Datenerklärung in der LINKAGE SECTION und in der PROCEDURE DEVISION; stattdessen wird eine Datenerklärung mit EXTERNAL-Klausel in der WORKING-STORAGE SECTION benötigt.

Beispiel

Statt:

LINKAGE SECTION.
   .
   .
01 AREA1. 
    02 DATA-ID  PIC X(8). 
    02 DATA-EX  PIC X(4000).

besser:

WORKING-STORAGE SECTION.
01 COMMON1 IS  EXTERNAL.
    02 DATA-ID  PIC X(8).
    02 DATA-EX  PIC X(4000).

In diesem Beispiel ist der COMMON-Bereich COMMON1 so definiert, dass er shareable geladen werden kann. Er kann auf folgende Weise definiert werden:

Für BS2000-Systeme z.B. in Assembler

COMMON1  CSECT PUBLIC 
COMMON1  RMODE ANY
COMMON1  AMODE ANY
* 
DATA_ID  DC C'DATA-ID1'
DATA_EX  DS CL4000 
         END

Soll der COMMON-Bereich prozesslokal geladen werden, dann kann auf das Attribut PUBLIC verzichtet werden.

Für Unix-, Linux- und Windows-Systeme in C

struct COMMON1 {
char DATA_ID [8] = "DATA-ID1";
char DATA_EX [4000];
}