PDA

View Full Version : Letzter Tag eines Monats ermitteln



Seiten : 1 [2]

Alexander
31-05-04, 10:31
Und endlich eine CL-Programm:

PGM
DCL VAR(&DATUM) TYPE(*CHAR) LEN(7)
DCL VAR(&TAG) TYPE(*DEC) LEN(2 0) VALUE(31)

DCL VAR(&DATUM1) TYPE(*CHAR) LEN(7)
DCL VAR(&cent1) TYPE(*char) LEN(1)
DCL VAR(&JAHR1) TYPE(*char) LEN(2)
DCL VAR(&MONAT1) TYPE(*char) LEN(2)
DCL VAR(&TAG1) TYPE(*CHAR) LEN(2) VALUE('31')

RTVSYSVAL SYSVAL(QCENTURY) RTNVAR&CENT1)
RTVSYSVAL SYSVAL(QYEAR) RTNVAR(&JAHR1)
RTVSYSVAL SYSVAL(QMONTH) RTNVAR(&MONAT1)

LOOP: CHGVAR VAR(&DATUM1) VALUE(&CENT1 *TCAT &JAHR1 *TCAT +
&MONAT1 *TCAT &TAG1)

CVTDAT DATE(&DATUM1) TOVAR(&DATUM) FROMFMT(*CYMD) +
TOFMT(*CYMD) TOSEP(*NONE)

MONMSG MSGID(CPF0555) EXEC(DO)
CHGVAR VAR(&tag) VALUE(&tag - 1)
CHGVAR VAR(&tag1) VALUE(&tag)
GOTO CMDLBL(LOOP)
ENDDO

ENDPGM

Jetzt das Feld &DATUM hat, was Sie wollen.
Und ganz einfach.

Thimi
01-06-04, 07:31
Hi FREEK,
Quote on:

Monat WHEQ 2
Jahr DIV 4 ZwischenResultat
MVR Rest
Rest IFEQ 0
Z-ADD 29 LetzterTag
* Schaltjahr im Februar 29 Tage!!
ELSE
Z-ADD 28 LetzterTag
ENDIF
ENDSL
Quote off

Die Regelung mit dem Säkularjahr wird dabei nicht berücksichtigt.
Das Jahr 2100 ist kein Schaltjahr (werden wir zwar nicht mehr erleben!)
Schaltjahr im Säkularjahr ist: Die Jahreszahl ist durch 400 teilbar. Die Jahre 1700, 1800 und 1900 stellten also so genannte Gemeinjahre zu 365 Tagen dar. Die Jahre 1600 und 2000 waren dagegen Schaltjahre zu 366 Tagen.
Gruss aus HH
Thierry

jobra
01-06-04, 08:32
Moint miteinander,

und nochmals Danke für die neuesten Lösungsvorschläge. Das CL mit dem CVTDAT von Alexander ist genau das was ich brauche. Einfach genial, genial einfach, manchmal dauert es eben etwas bis man drauf kommt :) . In Kombination mit dem zuvor beschriebenen DTAARA in dem ich den abzurechnenden Monat hinterlege, kann ich nun den zugehörigen Monatsletzten ermitteln.

Vielen Dank an Euch alle für Eure Unterstützuung, echt Klasse !

Jobra

Alexander
01-06-04, 08:39
Ich bin froh, dass mein CL dir passt.

FrEEk
01-06-04, 09:32
Hi FREEK,
Quote on:

Monat WHEQ 2
Jahr DIV 4 ZwischenResultat
MVR Rest
Rest IFEQ 0
Z-ADD 29 LetzterTag
* Schaltjahr im Februar 29 Tage!!
ELSE
Z-ADD 28 LetzterTag
ENDIF
ENDSL
Quote off

Die Regelung mit dem Säkularjahr wird dabei nicht berücksichtigt.
Das Jahr 2100 ist kein Schaltjahr (werden wir zwar nicht mehr erleben!)
Schaltjahr im Säkularjahr ist: Die Jahreszahl ist durch 400 teilbar. Die Jahre 1700, 1800 und 1900 stellten also so genannte Gemeinjahre zu 365 Tagen dar. Die Jahre 1600 und 2000 waren dagegen Schaltjahre zu 366 Tagen.
Gruss aus HH
Thierry


Da hast Du natürlich recht, aber es gibt sehr wenige Leute, die 400 Jahre lange leben :D

Dann müsste man noch durch 400 Teilen und wenns aufgeht trotzdem nur 28 in den letzten Tag schreiben.. oder war das anders rum?

juniorprog
25-01-05, 18:12
hallo @alle,
ich finde die moeglichkeiten wie %date... sehr interessant. da die bei uns nicht zum einsatz kommen hab ich die frage ob jemand einen link zu der uebersicht der einzelnen %XXX optionen nennen kann, wenn moeglich in deutsch ;-)
vielen dank

juniorprog




Hallo Jobra,

mit CL ist das nicht so ganz einfach!
Aber kannst Du nicht eine kleine RPG-Funktion oder -Programm schreiben, das den Monatsletzen ermittelt?
Was willst Du? Das Datum oder den Tag?

Hier ist ein Beispiel, wie aus einem numerischen Datum (JJJJMMTT) der Monatsletzte im gleichen Format ermittelt wird.


D DateNum S 8P 0 inz(20040525)
D DateNxtMon S D
D MonthEnd S D
D MonthEndNum S 8P 0
************************************************** ***
C Monitor
C Eval DateNxtMon = %Date(DateNum) + %Months(1)
C Eval DateNew = DateNxtMon
C - %Days(%SubDt(DateNxtMon:*D))
C Move DateNew MonthEndNum
C MonthEndNum dsply
C on-Error
C 'Ungült.Dat.' dsply
C EndMon
C eval *InLR = *on

Joe
26-01-05, 13:14
Hallo Alexander.

Bei CVTDAT sollte man vorher die Bedienerhilfe anschauen.
Der Datumsbereich geht max. bis 1928 zurück, das kann bei
sehr alten RPG-Programmierern schon mal zu Problemen führen. z. B. prüfen von Geburtstagen.

Gruss Joe

kuempi von stein
26-01-05, 15:32
Hallo Alexander.

Bei CVTDAT sollte man vorher die Bedienerhilfe anschauen.
Der Datumsbereich geht max. bis 1928 zurück, das kann bei
sehr alten RPG-Programmierern schon mal zu Problemen führen. z. B. prüfen von Geburtstagen.

Gruss Joe
und nicht zu vergessen die obergrenze 9.mai 2071 !
stichwort versicherungsverträge usw...

:-))

aber jeder der mal ne stunde auf der kiste gearbeitet hat weiss das ja eh...

in diesem sinne...

kuempi

Unregistriert
26-01-05, 23:52
Hallo Herr Kuempi von Stein

die Antwort habe ich schon registriert aber nicht so richtig verstanden.
Ich arbeite sehr wohl mit Geburtsdaten die sehr weit in das letzte
Jahrtausend (Millenium (für die jüngeren unter uns)) zurückgreifen und
da habe ich mit CVTDAT relativ grosse Probleme.

Ich lasse mich gerne diesbezüglich belehren!

gruss Joe

kuempi von stein
27-01-05, 08:48
Hallo Herr Kuempi von Stein

die Antwort habe ich schon registriert aber nicht so richtig verstanden.
Ich arbeite sehr wohl mit Geburtsdaten die sehr weit in das letzte
Jahrtausend (Millenium (für die jüngeren unter uns)) zurückgreifen und
da habe ich mit CVTDAT relativ grosse Probleme.

Ich lasse mich gerne diesbezüglich belehren!

gruss Joe
ja nö,

ich will ja niemanden belehren...
hatte nur wie joe aus der bedienerhilfe des befehls zitiert sozusagen...
äh.. ist jo == unregistriert ?
kann man hier auch posten ohne registrierung? wusste ich gar nicht...
na anyway...

noch ein schwank zum abschied:
mein erster kontakt mit der ibm-welt seinerzeit war zu zeiten der /36...
ich bin damals extra in die bibliothek gerannt weil für ein programm zur wochenberechnung nicht ganz klar war, wann es 52 bzw. 53 wochen im jahr gibt usw.

da musste ich dann feststellen, dass es extra DIN-Regeln gibt für das ganze kalendarium...

heute, 20 jahre später gibt es zwar systembedingt bessere möglichkeiten der datumsberechnung, aber wie das beispiel CVTDAT zeigt, muss man immer noch aufpassen...

so long

k.