Time-Feld in einer PF-Datei

[puddschini]

Hallo,
für Euch wohl eine einfache Übung:
mittels Cobol möchte ich ein Time-feld in einem PF belegen, bekomme beim Write aber einen Status 90 mit Hinweis auf dieses time-feld, das als Typ TIME, als Art T mit der Länge 3 und der int. Länge 3 definiert ist. Übertragen von low-value oder einem Feld "12:13:13" führen zu diesem Fehler. Wie muß die Quell-Definition aussehen (habe vorher mittels "Accept time" ein 8-stelliges Feld belegt)?
Danke im voraus.

[Fuerchau]

Am Besten du definierst vor IDENTFICATION DIVISION
process DATETIME

oder gibst dieses beim CRT-Befehl mit an.
Das Feld muss vom Typ X(8) sein (COPY DDx berücksichtigt das dann) und eine korrekte Uhrzeit im Format HH:MM:SS enthalten.

[puddschini]

WDSC schreibt folgende Zeile in meinen quell-Code:

LNC0031E PGM-ID nicht gefunden oder ungültig

processDATETIME
IDENTIFICATIONDIVISION.

Ansonsten keine Änderung im Pgm, meine Defi sieht aus wie Deine genannte.

[Fuerchau]

Zu WDSC kann ich nichts sagen, ob der "Process"-anweisungen unterstützt.
Wichtig ist beim Compile, dass die "Auswahlmögl. für die Umsetzung" CVTOPT auf *DATETIME steht.

Bist du sicher, dass zwischen Process und Datetime ein Leerzeichen ist ?
Ebenso bei "IDENTIFICATION DIVISION."

[puddschini]

Der browser hat die blanks beim Kopieren wohl gelöscht.
Aber ich habe anderes gesehen. WDSC schreibt ja lange Fehlermeldungen heraus:
Betrifft open-Befehle
OPEN EXTEND KTOSTML0
Öffnen von Teildatei KTOSTML0 in SEQONLY(*NO) geändert.
Ursache . . . . : Teildatei KTOSTML0 in Datei KTOSTML0 in Bibliothek TCD505MD wurde mit Parameter SEQONLY(*YES) im Programm oder Befehl OVRDBF (Mit Datenbankdatei überschreiben) geöffnet. Wegen Bedingung 8 der folgenden Bedingungen wurde der Parameter jedoch in SEQONLY(*NO) geändert: 8 - Datei enthält referenzielle Integritätsbedingungen, Auslöser oder ist eine verteilte Datei. SEQONLY(*YES) wurde in SEQONLY(*NO) geändert, damit Auslöserprogramme aufgerufen oder referenzielle Integritätsbedingungen satzweise durchgesetzt werden können oder weil SEQONLY(*YES) beim Öffnen der verteilten Datei nicht zulässig ist.

OPEN EXTEND KONPF
Öffnen von Teildatei KONPF in SEQONLY(*NO) geändert.
Ursache . . . . : Teildatei KONPF in Datei KONPF in Bibliothek TCD505KV wurde mit Parameter SEQONLY(*YES) im Programm oder Befehl OVRDBF (Mit Datenbankdatei überschreiben) geöffnet. Wegen Bedingung 1 der folgenden Bedingungen wurde der Parameter jedoch in SEQONLY(*NO) geändert: 1 - Programm öffnete eine logische Teildatei KONPF nur für Ausgabe, und SEQONLY(*YES) wurde mit der Standardanzahl von Sätzen angegeben. SEQONLY(*YES) wurde in SEQONLY(*NO) geändert, damit das Programm bei der Ausgabe die Dupliziertaste, Konvertierungsbelegung, Tastenbelegung und SELECT- und/oder OMIT-Fehler verarbeiten kann.

Für mich sieht das so aus, als wenn WDSC ein time-Feld mit Inhalt "00:00:00" (als Low-Value eines RPG-Pgms geschrieben) anmeckert.

Das time-Problem:
Datenzuordnungsfehler in Teildatei KTOSTML0.
Ursache . . . . : Bei Feld KTTIME im Satz mit Nummer 0 und Format KTOSTMPF in Teildatei KTOSTML0 mit Nummer 1 der Datei KTOSTML0 in Bibliothek TCD505MD ist wegen Fehlercode 17 ein Datenzuordnungsfehler aufgetreten. Fehlercodes und ihre Bedeutung: 17 - Format der Daten in einem Datums-, Zeit- oder Zeitmarkenfeld ist ungültig. 18 - ...

Oder generell gefragt: wie müssen die Statements aussehen, wenn ein PF mehrere logische sichten (durch Indizes) hat und eine Sicht (zum Anhängen von Sätzen) und eine Sicht (zum gezielten Lesen mit Schlüssel) geöffnet wird?
Hmmm ...
Leider bin ich einsamer Cobol-Wolf hier nur von RPG-lern umgeben ...

[Pikachu]

Probier's mal mit Punkten als Trennzeichen (z.B. "12.34.56") und wandle das Programm mit CRTCBLPGM CVTOPT(*DATETIME). Wie ist denn das Zeitfeld in der physischen Datei definiert (DSPFFD)?

[Fuerchau]

Die SEQONLY-Meldungen kann man ignorieren, da dies nur als Hinweis gedacht ist.
Dateien, die für OUTPUT geöffent werden, werden von COBOL (und auch RPG) intern geblockt.
Auf Grund der genannten Bedingungen ist aber eine Blockung nicht möglich sondern satzweises Schreiben erforderlich.

Eine PF/LF mit Schlüssel sollte nie per EXTEND geöffnet werden, sondern ganz normal mit I-O.
EXTEND ist nur für tatsächlich sequentielle Dateien erforderlich !
Hinzufügen von Sätzen geht dann mit WRITE ... INVALID ...

Das Problem des Zeitfeldes hängt nicht an einer PF oder LF.

Wichtig ist einzig und allein, dass der Compiler bereits ein Zeitfeld erkennen muss (DATETIME!), da sonst die I-O's nicht korrekt verarbeitet werden.
Die Zeit "00:00:00" gilt zwar bei RPG als *LOVAL, ist aber eine gültige Zeit.

Du musst also im WDSC irgendwo dafür sorgen, dass als Compiler-Option DATETIME akzeptiert wird.

Ggf. mag ja nur der Editor diese "Process"-Anweisung nicht (SEU tut das).
Laut COBOL-Handbuch akzeptiert der Compiler auf jeden Fall diese Anweisung.

Beispiel für meinen Trigger:
process apost nostdtrunc norange datetime
varchar timestamp cvttodate
IDENTIFICATION DIVISION.
Program-Id. FUETRGAPC.
************************************************** ***
* Allgemeiner Trigger für APC-Dateien
************************************************** ***
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.

SOURCE-COMPUTER. IBM-AS400.
OBJECT-COMPUTER. IBM-AS400.

[Pikachu]

Also "00:00:00" geht hier unter V5R4 nicht, aber "00.00.00" wird ohne Probleme angenommen.

[Fuerchau]

Das hängt dann wieder vom Timeformat ab.
COBOL ist da bei der Syntax mal wieder etwas komplizierter als RPG:

Im SPECIAL-NAMES gibts Definitionen für
format of date is '.....'
format of time is '.....'

als auch auf Stufenebene

05 mydate format date '....'
05 mytime format time '....'

Die Defaults sind in beiden Fällen *ISO:

Datum: YYYY-MM-DD
Zeit: HH.MM.SS

Für die Formate sind (ähnlich RPG) beliebige Kombinationen möglich.
Man kann dadurch eben für die interne Darstellung ISO und für die externe Darstellung PRTF/DSPF usw. Euro anwenden:

05 MYEURTIME FORMAT TIME '%H:%M:%S'.

Und siehe da, es klappt auch mit dem ":".

Näheres hierzu im COBOL-Programmierhandbuch.

[puddschini]

Kollege Pikachu,
auch Dir wieder herzlichen Dank, nur zur Info: v5r3 ist hier beim Kunden im Einsatz.

Kollege Fuerchau,
time-Problem gelöst, die Fehlermeldungen sind auch weg, jetzt muß nur noch der Write-Befehl funktionieren, dann hätte ich es.
Herzlichen Dank erneut an Dich.

Ja, die AS400-Welt ist doch anders als der liebe gute Host.

puddschini

[Fuerchau]

Nun ja, bei der AS/400 steckt die DB2/400 dahinter, und da wird gegen Datentype geprüft.
Auf einem Host gibts meistens VSAM, eher selten die DB2.