PDA

View Full Version : Datum in V5R3



lieser
02-02-05, 11:47
Hallo Forum,

ich rechne mit Datum und Eurer Hilfe.
Folgendes passiert:
an irgendeiner Stelle fällt eine Datumsroutine auf die Nase.
Beim erneuten Aufruf des Programms im Debugger kommt
gleich zu Anfang ein Abbruch RNQ0100,
und zwar merkwürdigerweise hier
// -----------------------------------------------------------
D CEEUTCO PR ExtProc('CEEUTCO')
D hours 10I 0
D minutes 10I 0
D seconds 8F
//
D hours_utc s 10I 0
D mins_utc s 10I 0
D secs_utc s 8F
D utcoffset s 10I 0
D UnixUrknall s z inz(z'1970-01-01-00.00.00.0
...
callp(e) CEEUTCO(hours_utc: mins_utc: secs_utc);
if %error;
utcoffset = 0;
else;
utcoffset = secs_utc;
endif;

Kann es sein dass i5/OS mir meine Verfehlungen bis zum Ende aller Tage vorwirft?

Gruss
WL

Fuerchau
02-02-05, 12:12
Da scheint irgendwer einen RCLACTGRP unterwegs zu machen, da kann es schon mal zu Pointerverlusten kommen.

Was treibst du da eigentlich so besonderes, was mit den Standard RPG-Befehlen TIME, ADDDUR / SUBDUR bzw. den entsprechenden %-Funktionen nicht auch geht ?

Ach ja übrigens: der UTC-Offset steht im Systemwert QUTCOFFSET und wird bei der TIME-Funktion nicht berücksichtigt, da die AS immer nur mit Localtime arbeitet.

lieser
02-02-05, 12:31
ich mache diese Verrenkungen, um die zuletzt geänderte Datei
in einem IFS-Verzeichnis zu bestimmen, aus der dann Updates
gemacht werden

Gruss
WL

Fuerchau
02-02-05, 12:43
Dann verwende doch lieber die C-Routinen wie localtime()
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c415607107.htm#HDRLOCALT

B.Hauser
02-02-05, 12:49
Hallo Forum,

ich rechne mit Datum und Eurer Hilfe.
Folgendes passiert:
an irgendeiner Stelle fällt eine Datumsroutine auf die Nase.
Beim erneuten Aufruf des Programms im Debugger kommt
gleich zu Anfang ein Abbruch RNQ0100,
und zwar merkwürdigerweise hier
// -----------------------------------------------------------
D CEEUTCO PR ExtProc('CEEUTCO')
D hours 10I 0
D minutes 10I 0
D seconds 8F
//
D hours_utc s 10I 0
D mins_utc s 10I 0
D secs_utc s 8F
D utcoffset s 10I 0
D UnixUrknall s z inz(z'1970-01-01-00.00.00.0
...
callp(e) CEEUTCO(hours_utc: mins_utc: secs_utc);
if %error;
utcoffset = 0;
else;
utcoffset = secs_utc;
endif;

Kann es sein dass i5/OS mir meine Verfehlungen bis zum Ende aller Tage vorwirft?

Gruss
WL

Hallo,

laut API-Beschreibung ist der 4.Parameter Omissible und nicht optional, d.h. er muss übergeben werden.
*OMIT ist als Übergabe-Wert zulässig.

RNQ0100 bedeutet:
Länge oder Anfangs-Position liegt ausserhalb des gültigen Bereichs für die Zeichenfolge Operation.
Der Abbruch erfolgt bei der Aktivierung, da die Parameter nicht übereinstimmen.

Der Prototyp und Aufruf müssten wie folgt abgeändert werden:


D CEEUTCO PR extproc('CEEUTCO')
D ParOffHours 10I 0
D ParOffMinutes 10I 0
D ParOffSeconds 8F
D ParFeedBack 12A options(*Omit)

D OffHours S 10I 0
D OffMinutes S 10I 0
D OffSeconds S 8F
*---------------------------------------------------
/Free
CeeUTCO(OffHours: OffMinutes: OffSeconds: *OMIT);
*InLR = *On;
/End-Free


Dieses Beispiel läuft unter V5R2M0 ohne Probleme

Birgitta

lieser
02-02-05, 16:39
Das war's

vielen Dank !!!!

Gruss
WL