Hallo!

Eine nette Dokumentation!
Du schreibst dort:

"Nachteil dieses Prinzips ist: Sollte eine Festplatte kaputt gehen, sind alle Daten im System inkonsistent, da keine
weitere Verwaltung existiert, die Buch führt, welche Daten auf welchen Platten liegen. Es hilft nur ein Booten vom
letzten Sicherungsband und die Restaurierung der kompletten (und hoffentlich funktionsfähigen) Sicherung. Aber wer
lässt schon ein solches System im Produktivbetrieb ohne Festplattenredundanz laufen?"

Aber es gibt doch mittlerweile auch längst RAID-Systeme auf der AS/400. Dies sollte doch erwähnt werden, sonst bekommen AS/400-Newbies ja einen ganz falschen Eindruck von der Kiste.

Und noch eine Sache:

"Nächste Frage: Warum definiere ich das Anlage-Datum als 8stellige Dezimalzahl? Nun, es hat etwas mit Faulheit zu
tun. Wenn man das Datum so verwendet, kann man recht einfach damit arbeiten und Rechnen. Angenommen, das
Feld BUCHDAT ist gleich 20020520 (20. Mai 2002). Somit kann man schnell einen Monat draufrechnen, in dem
man sagt EVAL BUCHDAT=BUCHDAT+100. Oder das Datum um ein Jahr verringern, in dem man den Wert
10000 abzieht... Aber keine Sorge, die Ausgabe auf dem Bildschirm kann man auch schön formatieren.
Natürlich kann man so zwei Daten schnell vergleichen, oder eine Liste danach sortieren."

Der Newbie wird hier meiner Meinung nach in eine falsche Richtung geführt. Ich bedaure sehr, daß in meinen Anwendungen, aus historischen Gründen, die Datumsfelder noch dezimal sind, statt echte Datumsfelder. Bei dezimalen Datumsfeldern muß man insbesondere darauf achten und prüfen ob der User auch immer das Datum korrekt eingibt. Heutzutage hat ILE-RPG doch soviele Datumsfunktionen (z.B. ADDDUR), daß man richtige Datumsfelder in der DDS verwenden sollte, oder?

Gruß

Matthias

[Dieser Beitrag wurde von Gerlitz am 01. August 2002 editiert.]