Externe Dateien in Cobol

[puddschini]

Hallo,
In einem Cobol-Pgm verwende ich Strukturen, die mittels eines RPG-Programmes und embedded-SQL generiert wurden.
Dies beschreibt eine phys. Datei mit zwei logischen Sichten. In jeder dieser Beschreibungen gibt es z.B. ein Feld KTSTAT, das einmal KTSTAT OF KTOSTML1 und einmal als KTSTAT OF KTOSTML2 angesprochen wird. Dieses Feld ist jeweils Schlüsselfeld neben zwei bzw. drei anderen.
Der compiler mault beide Fälle an, aber zuerst ein Auszug aus dem Coding:


INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT KTOSTM1 ASSIGN TO DATABASE-KTOSTML1-ALWNULL
ORGANIZATION IS INDEXED
ACCESS IS DYNAMIC
RECORD KEY IS KTSTAT OF KTOSTML1
FILE STATUS IS KTO-STAT1.

SELECT KTOSTM2 ASSIGN TO DATABASE-KTOSTML2-ALWNULL
ORGANIZATION IS INDEXED
ACCESS IS DYNAMIC
RECORD KEY IS KTSTAT OF KTOSTML2
FILE STATUS IS KTO-STAT2.


DATA DIVISION.
FILE SECTION.
FD KTOSTM1.
01 KTO-SATZ1.
COPY DDS-ALL-FORMATS OF KTOSTML1.

FD KTOSTM2.
01 KTO-SATZ2.
COPY DDS-ALL-FORMATS OF KTOSTML2.



WORKING-STORAGE SECTION.
01 KTOSTML1-NKM.
COPY DDS-ALL-FORMATS OF KTOSTML1 WITH NULL-KEY-MAP.

01 KTOSTML1-NM.
COPY DDS-ALL-FORMATS OF KTOSTML1 WITH NULL-MAP.

01 KTOSTML2-NKM.
COPY DDS-ALL-FORMATS OF KTOSTML2 WITH NULL-KEY-MAP.

01 KTOSTML2-NM.
COPY DDS-ALL-FORMATS OF KTOSTML2 WITH NULL-MAP.



PROCEDURE DIVISION.
START KTOSTM2
KEY NOT < KTSTAT IN KTOSTML2
NULL-KEY-MAP IS KTOSTML2-NKM
INVALID KEY SET KTOS2 TO TRUE
END-START.

IF KTOS2
PERFORM U800-FEHLER-IN-KONPF
END-IF.

READ KTOSTM2 NEXT RECORD
NULL-KEY-MAP IS KTOSTML2-NKM
NULL-MAP IS KTOSTML2-NM
AT END SET KTOR2 TO TRUE
END-READ.

Nachricht . . . : 'KTSTAT OF KTOSTML2' nicht als Name definiert.
Anweisung oder Klausel ignoriert.

Desweiteren:
Nachricht . . . : KEY RECORD fehlt für Datei 'KTOSTM1'.
Nachricht . . . : KEY RECORD fehlt für Datei 'KTOSTM2'.

Ganz unverständlich für mich diese Meldungen:
Nachricht . . . : Die Länge des Bezeichners 'BNKSTML1-NKM' in Phrase
NULL-KEY-MAP in Byte ist nicht gleich 0. Phrase akzeptiert.

Oder diese meldung:
Nachricht . . . : Datenname 'KTSTAT OF KTO-SATZ1' als Schlüsselname
in Anweisung START für Datei 'KTOSTM1' ungültig. Anweisung ignoriert.

Vielleicht gibt es ja eine einfache Lösung zu dem Problem. Danke im voraus.

[Fuerchau]

Zur Bennennung:

Name of Struktur-Name !

KTOSTML2 ist der externe Name und nicht dein Struktur-Name.

Beim Zugriff auf extern beschriebene Dateien ist "externally-described key" erforderlich, sowohl in der Select-Klausel als auch in der Start-Anweisung.

Die Schlüsselfelder sind vor dem Zugriff im FD-Puffer zu füllen.

Begründung:
COBOL unterstützt bei Index-Zugriffen nur zusammenhängende Schlüsselfelder im Satzpuffer.
Da DDS-Dateien aber mehrere Schlüsselfelder über den Puffer verteilt haben können, ist die Sonderform "externally-described key" erforderlich.

[puddschini]

Hallo und guten Morgen,
der Hinweis war super.
Beim Open erhalte ich den file-status 95, (unvollständige Informationen). Was muß ich hier noch tun?
Inzwischen habe ich "with duplicates" eingebaut. Der Status beim Öffnen ist jetzt ok, aber beim Start erhalt ich 23 und beim folgelesen 46. Meine Idee ist, zu einem bestimmenten Mandanten eine höchste lfdNr zu ermitteln. Ich plante, den größten Wert in lfdNr zu vergeben und dann mit Prior einen Satz zurückzulesen. Das klappt wohl nicht so recht.
Mein Coding sieht nun so aus:

FILE-CONTROL.
SELECT KTOSTM1 ASSIGN TO DATABASE-KTOSTML1-ALWNULL
ORGANIZATION IS INDEXED
ACCESS IS DYNAMIC
RECORD KEY IS EXTERNALLY-DESCRIBED-KEY
WITH DUPLICATES
FILE STATUS IS KTO-STAT1.

DATA DIVISION.
FILE SECTION.
FD KTOSTM1.
01 KTO-SATZ1.
COPY DDS-ALL-FORMATS OF KTOSTML1.

WORKING-STORAGE SECTION.
* external key
01 K1-KEY.
05 K1-KTSTAT PIC X VALUE SPACE.
05 K1-KTMAND PIC 9(4) COMP-3 VALUE ZEROES.
05 K1-KTKVER PIC 9(8) COMP-3 VALUE ZEROES.


PROCEDURE DIVISION USING TAB-KVER.
OPEN I-O KTOSTM1.

* Index-Felder belegen
MOVE SPACE TO K1-KTSTAT KTO-STAT1
MOVE T-MAND(I-T) TO K1-KTMAND
MOVE 99999999 TO K1-KTKVER

START KTOSTM1
KEY NOT < K1-KEY
NULL-KEY-MAP IS KTOSTML1-NKM
INVALID KEY SET KTOS1 TO TRUE
END-START.


READ KTOSTM1 PRIOR RECORD
NULL-KEY-MAP IS KTOSTML1-NKM
NULL-MAP IS KTOSTML1-NM
AT END SET KTOR1 TO TRUE
END-READ.

[Fuerchau]

Schau dir genau den Key an.
Vor dem Mandant gibts noch den Status.

Bist du sicher, dass nach dem Prior noch der richtige Mandant und Status im Puffer steht ?

[puddschini]

Deine Antwort macht mich unsicher. Aber ich habe kein Bsp gefunden, in dem zw. Start und read prior(next) der Key neu belegt wird. Nebenbei, der Start bringt immer noch einen Status 23. Ansonsten habe ich keine Lösung.
Nach einem Test vor wenigen Minuten sehe ich die Keys beide gleich gefüllt, den in der FD-Stufe und den in der WorkStor. Nun bin ich ratlos.

[Pikachu]

Sieh' mal in der Umwandlungsliste nach. Vermutlich wurde da der Fehler LNC0635 (Angegebene Schlüssel entsprechen nicht den extern beschriebenen Schlüsseln der Datei ...) ausgegeben.

Du mußt die Schlüsselfelder mit Vorzeichen definieren (PIC S9(nnn)), damit sie den Feldern der Datei entsprechen. Außerdem müssen beim START anscheinend die Felder einzeln angegeben werden (jeweils durch Komma getrennt), oder du gibst EXTERNALLY-DESCRIBED-KEY als Schlüssel an.

[puddschini]

Danke für den Tip, kann ich aber erst wieder am Dienstag testen, wollte aber nur schnell noch reagieren. Frohe Feiertage.
Habe gestern Abend noch über Deinen Vorschlag nachgedacht. Das Vorzeichen hat keine Auswirkungen, und die Felder müssen auch nicht einzeln angegeben werden. Mit SQL und einem select max(lfdnr) from x/y where mand = 5 (z.B.) erhalte ich die höchste lfdNr dieses Mandanten. Wenn ich nun diesen Wert anstatt 8x eine 9 eingebe, findet der START die richtige Position und liefert genau den Satz zurück, der read prior geht dann auch ganz brav einen Satz zurück. Das geht wunderschön. Es geht nur nicht, wenn man das Feld mit 9en belegt (um den höchsten Wert darzustellen), um den letzten Satz zu lesen. Das liefert den Status 23 (Satz nicht gefunden) beim START und der read prior liefert den filestatus 46 (read beyond end-of-file). Mir fehlt in Cobol der Befehl (oder eine Möglichkeit) wie in RPG oder der funktioniert wie die max-Funktion bei SQL. Lese ich mit LAST, so erhalte ich den allerletzten Satz in der Datei, der aber zu keinem der Mandanten passen müßte.

[wwg]

Hallo,

fülle einfach die Schlüsselfelder direkt im FD-Satz und mache den Start mit:

start ktostm1
key is not < externally-described-key
invalid continue
end-start.


Das vielleicht unerwartete "continue" deswegen, weil auch beim Start-Versuch hinter dem allerhöchsten Key-Wert der Pointer für das "read prior" richtig gesetzt ist.

[puddschini]

Hallo,
danke für den Tipp, gelesen und durchgeführt, Ergebnis bleibt Status 23 beim START und 46 beim READ. Ich denke, ich gebe es auf und schreibe mir ein Upro mit SQL.
Danke Euch allen.

[Pikachu]

Sieh' mal in die aktuelle Umwandlungsliste (WRKSPLF). Stehen da irgendwelche Warnungen drin?

[Fuerchau]

Da der Start den Datei-Zeiger nicht setzen kann, ist der READ PRIOR eben auch nicht erfolgreich.

Bei Mandanten hast du ja 2 Varianten:

1. Der Start ist erfolgreich weil noch ein Mandant folgt, dann klappt auch READ PRIOR.
2. Ist der Start nicht erfolgreich, weil du hinter dem letzten Mandanten (also EOF) stehst, dann ist READ LAST der richtige Weg.

In beiden Fällen musst du natürlich noch prüfen, ob du noch im richtigen Mandanten bist.

start myfile key is not < externally-described key
invalid
read myfile last
at end continue
end-read
not invalid
read myfile prior
at end continue
end-read
end-start

[puddschini]

Kollege,
das war nun doch ein Volltreffer, es funktioniert wie gewünscht.
Lesen bildet, ich habe die Fehlermeldungen wohl nicht beachtet, habe dann nach Deinem Hinweis die Felder angepaßt, obwohl sie von der Struktur her nicht übereinstimmen (StufenNr) und habe im Start statt der einzelnen Felder "external-described-key" angegeben. Habe sowohl die ext. Felder als auch die in der FD-Stufe gefüllt und nach dem READ abgeglichen. Danach lief es reibungslos.
Danke Dir ganz herzlich für ein verspätetes dickes Osterei.
puddschini