*date ; %date()

[cimbala]

Moin zusammen,

wir haben bei uns im Hause einen RPG- Entwickler der sich nicht an WDSC und free- RPG gewöhnen will - aber das nur zur Vorgeschichte.
Wir haben nun seit einigen Tagen einen Nachtlauf der, der immer um 00:00 abschmiert, wenn die Programme im nicht free- Format laufen. Fehlermeldung ist "Datums- oder Zeitmarkenwert ungültig" Der Abbruch tritt auf beim "Eval *date tagesdatum" .
Benutzt man nun "tagesdatum = %date()" läuft alles durch.

Hatte jmd. von euch schonmal so ein Problem?

[cimbala]

hab nen Thread gefunden, der meine Frage beantwortet... Trotzdem danke und sorry

[Fuerchau]

Eigentlich bezeichnet *date das Jobdatum und sollte nicht verändert werden !
Ggf. ist *date unter Schreibschutz und wird ignoriert wenn der selbe Wert zugewiesen werden soll, ansonsten gibts eben die Fehlermeldung.

Man kann auch im Nichtfree mit "eval tagesdatum = %date()" arbeiten.

[B.Hauser]

Nicht nur, dass *DATE das Job-Datum ist, *Date liefert auch einen numerischen Wert zurück und zwar im Datumsformat des Jobs (wahrscheinlich *DMY).

Wird jetzt *DATE über einen MOVE (ohne Angabe des Faktor1) in ein Datumsfeld ausgegeben, geht die Konvertierung davon aus, dass das *Date-Datum im Format ISO ist. (Deshalb auch die Fehlermeldung "Datums- oder Zeitmarkenwert ungültig".) Würde im Faktor 1 das Job-Format z.B. *DMY stehen, würde das Programm auch nicht abbrechen.

Das Äquivalent, um das System-Datum zu ermitteln im klassischen Format ist der OpCode TIME. Die Ausgabe kann auch direkt in ein Datums-Feld erfolgen.

wir haben bei uns im Hause einen RPG- Entwickler der sich nicht an WDSC und free- RPG gewöhnen will - aber das nur zur Vorgeschichte.

... Du bist übrigens nicht der einzige, der mit solchen Mitarbeitern zu kämpfen hat.
Ich habe gerade ein nagelneues Programm gesehen, in dem noch nicht einmal ein einziger EVAL (von Free-Format ganz zu schweigen) verwendet wurde. Ja noch nicht einmal Z-ADD wird eingesetzt, da alle Felder unabhängig vom Datentyp nur mit MOVE oder MOVELs hin- und her geschoben werden.
Um die aktuelle Zeit alphanumerisch im Format JJMMTT auszugeben, werden sage und schreibe 1xTIME und 6xMOVE verwendet.
Um ein Binär-Feld in ein Integer-Feld umzuladen werden 2 MOVEs und 1 Hilfsfeld benötigt!
Wenn ich genügend Zeit hätte, würde ich das Ding so wie es ist in die Tonne treten und neu schreiben.

Birgitta

[Fuerchau]

Aber wer hat schon die Zeit.
Es reicht doch schon sich mit diesem Unsinn herumzuschlagen (und ggf. auch noch Fehler zu suchen).

[Pikachu]

... Du bist übrigens nicht der einzige, der mit solchen Mitarbeitern zu kämpfen hat.
Ich habe gerade ein nagelneues Programm gesehen, in dem noch nicht einmal ein einziger EVAL (von Free-Format ganz zu schweigen) verwendet wurde. ...

Ein RPG-Programm ohne nur einen einzigen EVAL-Befehl? Und sogar noch ohne free-Format? Ist sowas denn heutzutage überhaupt noch erlaubt?

[malzusrex]

für das Museum schon
Oder um Leute, die noch nicht so lange dabei sind, zu verwirren

Gruß Ronald

[B.Hauser]

Ein RPG-Programm ohne nur einen einzigen EVAL-Befehl? Und sogar noch ohne free-Format? Ist sowas denn heutzutage überhaupt noch erlaubt?

Theoretisch nicht!
und praktisch eigentlich auch nicht!
Aber solange es Programmierer gibt, die sich seit 30 Jahren keinen Zentimeter weiter bewegt haben (und auch nicht mussten) und
solange es Projektleiter gibt die sagen: "Mir egal wie der Source Code aussieht, Hauptsach' des Ding tut was es tun soll" (wenn es das denn mal auch täte!)
...

Birgitta

[Pikachu]

Dann liegt das aber auch mit an IBM! Die müßten einfach einmal alle alten Befehle (für die man auch EVALs nehmen kann) aus RPG herauswerfen und das fixed-Format verbieten.

[RobertMack]

Dann liegt das aber auch mit an IBM! Die müßten einfach einmal alle alten Befehle (für die man auch EVALs nehmen kann) aus RPG herauswerfen und das fixed-Format verbieten.

... dann gäbe es unsere geliebte AS/400 wohl nicht mehr. Ein wesentlicher Teil des immer noch anhaltenden Erfolgs ist die Tatsache, dass selbst älteste Software (Investition!) immer noch läuft!

Grüße,
Robert

[Pikachu]

Warum eigentlich überhaupt immer noch RPG und COBOL? Gibt's denn da inzwischen nix "moderneres"?

[Fuerchau]

Ja klar:
C++
.NET
Java
PHP
Delphi
u.v.m.

Mach mal eine Anfrage bei der IBM ab wann z.B. .NET oder Delphi auf der AS/400 verfügbar wird.

Java geht ja schon.
Schreibe da aber mal ein kommerzielle Anwendung, die keine Rechenprobleme mit Nachkomma's hat (Double-Werte).

Nicht umsonst gibts da manchmal so Programmierhinweise, dass

if (MyField == 0.3)

nie zum positiven Erfolg führen wird.

Ich kenne auch keine Programmiersprache (ausser RPG), die Dezimalzahlen mit Packed(31,n), und nun neu mit ILERPG Packed(63,n) unterstützt.

Maximal gibts da den Typ Currency mit 28 Stellen, wobei dieser nur max. 4 Nachkomma haben kann.

Double hat nur 17stellige Genauhigkeit, wobei es eben in den NK's (2^1/n) immer zu problemen kommt.