Das "VOLLE PROGRAMM" ...

[Lichtblitz]

Hallo Leute,
ich habe zur Zeit das "VOLLE PROGRAMM" mit Feldern aller möglichen (und
unmöglichen?) Variationen zu verwalten.
Vielleicht könnt Ihr mir dabei etwas unter die Arme greifen. Das Füllen
geht ja noch einigermaßen, aber beim Lesen gibt es ständig
unangenehme Überraschungen. Man beachte vor allem die Felder vorgangsnr und
gebdat

Es handelt sich dabei um eine Datei, die (verkürzt) folgendermaßen auf der
AS/400 erstellt wurde:

CREATE TABLE BIBL/Datei (
vorgangsnr INTEGER NOT NULL DEFAULT 0,
prio SMALLINT NOT NULL DEFAULT 0,
abfstart TIMESTAMP NOT NULL DEFAULT CURRENT TIMESTAMP,
gebdat DATE NOT NULL,
matchcode VARCHAR(254) NOT NULL DEFAULT '0',
);


Dabei sollen die Datümer im ISO-Format JJJJ-MM-TT gefüllt werden.
Die mit COPY DDS-ALL-FORMATS ins COBOL-Programm (SQLCBL) hereingeholten
Felder sehen dann so aus:

PROCESS OPTIONS DATETIME APOST VARCHAR.
...
06 VORGANGSNR PIC S9(9) COMP-4.
06 PRIO PIC S9(4) COMP-4.
06 ABFSTART PIC X(26).
(Zeitmarkenfeld)
06 GEBDAT PIC X(10).
(Datumsfeld)
06 MATCHCODE.
(Feld variabler Länge)
49 MATCHCODE-LENGTH PIC S9(4) COMP-4.
49 MATCHCODE-DATA PIC X(254).

Das Feld GEBDAT sieht bei mir im DSPF so aus:

A SOGEBDAT L B 20 13DATFMT(*ISO)


Das Füllen der Datei mit ...

SQL EXEC SQL
SQL INSERT
SQL INTO datei (
SQL*********** vorgangsnr,
SQL*********** prio ,
SQL abfstart ,
SQL gebdat ,
SQL matchcode ,
SQL )
SQL VALUES (
SQL*********** 0 ,
SQL*********** 0 ,
SQL CURRENT TIMESTAMP,
SQL CURRENT DATE ,
SQL :IBK3863B6-O.SOMATCHC
SQL )

...funktioniert mal einigermaßen.
[Die Felder vorgangsnr und prio habe ich default gelassen, weil sie ja
erstmal durch "DEFAULT 0"
und später von einem PC-Programm gefüllt wird; merkwürdig ist mir
allerdings, daß es ja eigentlich
"NOT NULL" heißt !?]

Beim Ansehen mit STRSQL sieht der Satz so aus:


....+....1....+....2....+....3....+....4....+....5 ....+....6....+....7....+....8....+....9....+...10 ....
VORGANGSNR PRIO ABFSTART GEBDAT MATCHCODE
0 1 2005-07-18-14.21.50.000000 2005-07-18 0003 8300039766 5411895809 5411895824
******** Datenende ********
(Wobei ich die SQL-Sitzungsattribute für das DAtum allerdings so geändert habe:
*NC, *UR, *RS
Datumsformat . . . . . . . . . *ISO *JOB, *USA, *ISO, *EUR,
*JIS
*MDY, *DMY, *YMD, *JUL
Daher erscheint es wohl nur hier auch richtig. mit
Datumsformat . . . . . . . . . *DMY
sieht es wieder so aus:
..+....6..
GEBDAT
18.07.05 )


Wenn ich die Feldinhalte im Debugger anschaue, sehen sie so aus:

Programm . . . . . . . . . . . . . . . : IBK3863
Rekursionsebene . . . . . . . . . . . . : 1
Startposition . . . . . . . . . . . . . : 1
Format . . . . . . . . . . . . . . . . : *HEX
Länge . . . . . . . . . . . . . . . . . : *DCL

Variable . . . . . . . . . . . . . . . : 06 dateiname.VORGANGSNR
Art . . . . . . . . . . . . . . . . . : BINÄR MIT VORZEICHEN
Länge . . . . . . . . . . . . . . . . : 4
* . . . + . . . . 1 . . . . + .
00000000

Programm . . . . . . . . . . . . . . . : IBK3863
Rekursionsebene . . . . . . . . . . . . : 1
Startposition . . . . . . . . . . . . . : 1
Format . . . . . . . . . . . . . . . . : *HEX
Länge . . . . . . . . . . . . . . . . . : *DCL

Variable . . . . . . . . . . . . . . . : 06 dateiname.PRIO
Art . . . . . . . . . . . . . . . . . : BINÄR MIT VORZEICHEN
Länge . . . . . . . . . . . . . . . . : 2
* . . . + . . . . 1 . . . . + .
0001

(Bei CURRENT DATE [Wie ich das Feld richtig fülle, ist noch eine andere
Frage].
Eigentlich soll es ja JJJJ-MM-TT aussehen. Muss ich irgendwo noch *ISO
angeben?)
Programm . . . . . . . . . . . . . . . : IBK3863
Rekursionsebene . . . . . . . . . . . . : 1
Startposition . . . . . . . . . . . . . : 1
Format . . . . . . . . . . . . . . . . : *HEX
Länge . . . . . . . . . . . . . . . . . : *DCL

Variable . . . . . . . . . . . . . . . : 06 dateiname.GEBDAT
Art . . . . . . . . . . . . . . . . . : ZEICHEN
Länge . . . . . . . . . . . . . . . . : 10
* . . . + . . . . 1 . . . . + . *...+....1....+.
F1F84BF0F74BF0F54040 '18.07.05 '

Bei CURRENT TIMESTAMP:

Programm . . . . . . . . . . . . . . . : IBK3863
Rekursionsebene . . . . . . . . . . . . : 1
Startposition . . . . . . . . . . . . . : 1
Format . . . . . . . . . . . . . . . . : *HEX
Länge . . . . . . . . . . . . . . . . . : *DCL

Variable . . . . . . . . . . . . . . . : 06 dateiname.ABFSTART
Art . . . . . . . . . . . . . . . . . : ZEICHEN
Länge . . . . . . . . . . . . . . . . : 26
* . . . + . . . . 1 . . . . + . *...+....1....+.
F2F0F0F560F0F760F1F860F1F44BF2F1 '2005-07-18-14.21'
4BF5F04BF0F0F0F0F0F0 '.50.000000'


Man beachte bei diesem (COMP-4)-Feld die ersten zwei Stellen, welche die
zwei zusätzliche Byte
wegen VARLEN sind. Wie kann mann die im Programm richtig lesen ohne die
zwei Anfangsbyte?
Programm . . . . . . . . . . . . . . . : IBK3863
Rekursionsebene . . . . . . . . . . . . : 1
Startposition . . . . . . . . . . . . . : 1
Format . . . . . . . . . . . . . . . . : *HEX
Länge . . . . . . . . . . . . . . . . . : *DCL

Variable . . . . . . . . . . . . . . . : 06 dateiname.MATCHCODE
Art . . . . . . . . . . . . . . . . . : ZEICHEN
Länge . . . . . . . . . . . . . . . . : 256
* . . . + . . . . 1 . . . . + . *...+....1....+.
0025F0F0F0F340F8F3F0F0F0F3F9F7F6 '0003 830003976'
F640F5F4F1F1F8F9F5F8F0F940F5F4F1 '6 5411895809 541'
F1F8F9F5F8F2F4404040404040404040 '1895824 '


Der langen Rede kurzer Sinn:
Wie fülle ich die Felder richtig und wie definiere ich sie im Programm,
sodaß ich die gefüllten Felder auch wieder lesen kann???


Bei
SQL EXEC SQL
SQL FETCH FROM C2
SQL INTO :dateiname
SQL END-EXEC
kommen folgende Fehlermeldungen:

Weitere Nachrichteninformationen Seite
1
5769SS1 V4R4M0 990521 WKAK3001 18.07.05
08:48:53
Nachrichten-ID . . . . : SQL0303 Bewertung . . . . . . : 30
Sendedatum . . . . . . : 18.07.05 Sendezeit . . . . . . :
08:46:42
Nachrichtenart . . . . : Diagnose
Von Programm . . . . . . . . . : QSQROUTE
Von Bibliothek . . . . . . . : QSYS
Von Modul . . . . . . . . . : QSQFETCH
Von Prozedur . . . . . . . . : CK_DEBUG
Von Anweisung . . . . . . . : 14418
An Programm . . . . . . . . . : QSQROUTE
An Bibliothek . . . . . . . : QSYS
An Modul . . . . . . . . . . : QSQFETCH
An Prozedur . . . . . . . . : CK_DEBUG
An Anweisung . . . . . . . . : 14418
ID des codierten Zeichensatzes : 65535
Nachricht . . . : Host-Variable VORGANGSNR nicht verträglich.
Ursache . . . . : Eine Anweisung FETCH, SELECT oder CALL kann nicht
ausgeführt werden, da die Datenart von Host-Variable VORGANGSNR nicht
mit
der Datenart des zugehörigen Listeneintrags verträglich ist.
-- Wird ein Datumswert ausgewählt, muß eine Host-Zeichenvariable für
ein
Julianisches Datum mindestens 6 Byte, für ein Datum im Format MDY, YMD,
DMY
mindestens 8 Byte und für alle anderen Formate mindestens 10 Byte
umfassen.
-- Wird ein Zeitwert ausgewählt, muß eine Host-Zeichenvariable für
eine
Uhrzeit im Format USA mindestens 8 Byte und für alle anderen Formate
mindestens 5 Byte umfassen.
-- Wird ein Zeitmarkenwert ausgewählt, muß eine Host-Zeichenvariable
mindestens 19 Byte umfassen.
-- Hat die Host-Variable ein C NUL-Abschlußzeichen und wurde das
Programm
mit der Auswahl *CNULRQD umgewandelt, ist für das NUL-Abschlußzeichen
für
Datums-/Zeitwerte ein zusätzliches Byte erforderlich.
Die relative Position der Host-Variablen in der Klausel INTO, im
SQL-Deskriptorbereich (SQLDA) oder der Anweisung CALL ist 1. Ist der
Name
der Host-Variablen *N, wurde in einer Anweisung FETCH ein SQLDA
angegeben.
Fehlerbeseitigung: Sicherstellen, daß die Datenarten mit allen
entsprechenden
Listeneinträgen der Anweisung SELECT oder CALL verträglich sind.
Sicherstellen, daß die Host-Variablen für Datums-, Zeit- oder
Zeitmarkenwerte korrekt definiert sind.
* * * * * E N D E D E R L I S T E * * * * *

Weitere Nachrichteninformationen Seite
1
5769SS1 V4R4M0 990521 WKAK3001 18.07.05
13:59:57
Nachrichten-ID . . . . : CPF5035 Bewertung . . . . . . : 10
Sendedatum . . . . . . : 18.07.05 Sendezeit . . . . . . :
13:59:22
Nachrichtenart . . . . : Diagnose
Von Programm . . . . . . . . . : QDBSIGEX
Von Bibliothek . . . . . . . : QSYS
Instruktion . . . . . . . . : 0A90
An Programm . . . . . . . . . : QSQROUTE
An Bibliothek . . . . . . . : QSYS
An Modul . . . . . . . . . . : QSQFETCH
An Prozedur . . . . . . . . : F_GETBLK
An Anweisung . . . . . . . . : 11399
ID des codierten Zeichensatzes : 65535
Nachricht . . . : Datenabbildungsfehler in Teildatei dateiname.
Ursache . . . . : Im Feld GEBDAT im Satz mit Nummer 1 und Format
dateiname in
Teildatei dateiname mit Nummer 1 der Datei dateiname in Bibliothek
DVA0789 trat
wegen Fehlercode 16 ein Datenabbildungsfehler auf. Fehlercodes:
16 -- Datumswert ist kleiner als der kleinste zulässige Wert.


Vielen Dank im Voraus für jeden Hinweis. Ich bin hier mit meinem Latein am
Ende, da ich kein PC-Experte bin. Ich weiß ja, daß die EBCDIC- und die ASCII-Welten grundverschieden sind. Aber irgendwie müssen sie jetzt zusammenkommen.

Klaus

[Fuerchau]

Auf Grund von "NOT NULL DEFAULT ..." wird eben der Standardwert angenommen, da NULL ja verboten ist.

Das Datumsformat muss in COBOL per SQL-Option gesetzt werden:
/exec sql
set option datfmt=*iso, timfmt=*iso
/end-exec
sonst wird das aktuelle Job-Format verwendet.

In der Process-Anweisung wird noch "nostdtrunc" benötigt, da sonst comp-4 nicht in vollem Umfang genutzt werden können. COBOL führt diese sonst intern als COMP-3 so dass es zu Datenabbildungsfehlern kommt.

VARLEN-Felder sind so definiert, so dass beim Insert/Update die Länge im xxx-lenght angegeben werden muss (per inspect die Länge ermitteln) und das Gruppenfeld als Variable zu verwenden ist.
Alternativ kann auch beim Insert/Update das Feld per TRIM(:MYCHAR) verwendet werden, wobei allerdings führende Leerzeichen verloren gehen.