View Full Version : Os400 Fehler ?
Hi *all
ich mags ja eigentlich gar nicht fragen, aber
wir suchen seit Tagen einen Fehler der sich so darstellt:
Ein Pgm sucht mit Setll und Read einen Datensatz.
gibt es ihn, wird er upgedatet, fehlt er wird er neu geschrieben. Das passiert je nach Aufruf 1 bis 800 mal und ist 1 Lauf
(klingt ganz einfach oder ?)
Ab und zu, d.h. 2 mal in 6430 Läufen schreibt das Programm die Sätze doppelt, d.h. der settl und read findet (anscheinend) den Satz nicht.
Einzige gemeinsamkeit in den beiden Fällen ist: der Lauf hatte über 450 Datensätze.
Wiederhole ich den Lauf ist alle richtig, d.h. ich habe keinen ansatzpunkt !
Kann es sein das durch einen Fehler in OS400 soetwas auftreten kann ? Hatte jemand schon das Probem ?
Danke
Robi
Ich kann mir nur vorstellen, dass zwischen SETLL/READ und WRITE soviel Zeit vergeht, dass ein anderer Job diesen Satz schreiben konnte.
Wenn du einen UNIQUE-Key anlegst passiert das nicht mehr, da der WRITE dann abgelehnt wird.
Die Datei wird nur von genau diesem Pgm geschrieben, es gibt auch nur eine Pgm das die Datei später liest, lesen und schreiben laufen definitiv nie zusammenl
Was ich vergessen habe, : Es werden auch 'normale writ's in die datei gemacht, nicht nur Upd/write
(So etwas ähnliches wie Satzarten abhängig)
unique key geht hier nicht
noch idee'n
(ich hatte vor Jahren mal das Problem, das ich mit FRCRATIO = 1 arbeiten mußte, allerdings waren damals 2 programme = 2 jobs beteiligt)
Robi
Das hat mit FRCRATIO nur bedingt was zu tun.
Wird eine Datei im U-Modus betrieben, erfolgt keine Blockung der Daten.
Im O-Modus wird vom RPG automatisch geblockt, so dass eben nicht jeder Write sofort verfügbar war.
Mittels FRCRATIO wird dann die Blockung für O-Dateien zur Laufzeit abgeschaltet (Im Joblog steht, dass SEQONLY(*YES) nicht verwendet werden kann).
Die Performance wird dann allerdings eingeschränkt, da damit auch Systempufferung ausgeschaltet wird.
Im U-Modus konnte ich bisher auf alle geschriebenen Sätze sofort auch lesend zugreifen.
Eine Variante gibts da ggf. noch:
Die Datei wird im Programm 2x verwendet
a) als U-Datei über eine Key-LF
b) als O-Datei
genau dann kann das Problem auftreten.
Allerdings kann ich ja auch eine U-Datei schreiben (A=Append).
Vielen dank,
aber das ist alles bekannt.
Wir haben mittlerweile mit 3 programmieren das pgm beurteilt.
Es hat keinen fehler !
Daher die Vermutung das sich IBM ab und an 'verschluckt'.
Ich finde jedoch keine Fehlerbeschreibung in den PTF's
Ich wollt ja nur wissen, ob das jemand auch schon einmal hatte. Es gibt in diesem Fall auch andere Läufe mit mehr als 450 Sätzen die fehlerfrei sind, allerdings ist diese große Zahl in dem beschriebenen Vorgang eher selten.
Robi
hgdieterle
03-11-06, 14:27
Hallo,
wie fragst du ab, ob der SETLL funktioniert hat?
Mit Bezugszahl oder mit %equal ?
Ganz wichtig nach %equal ist ()
Falls man nur %equal und nicht mit %equal()
kann es Probleme geben.
klassisch mit bz in ho und ni
Pgm ist in ordnung, da gibt's nix
Wiederhollauf hat ( bisher) den fehler nicht gebracht
Robi
Vielleicht schlägt der SETLL (http://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c0925083713.htm#HDRZZSETLL) in seltenen Fällen fehl? Mit welchem Indikator wird das im Programm abgefragt? Wird das vielleicht einfach ignoriert? Wie wird der READ durchgeführt? Vielleicht würde ja auch der SETLL mit zusätzlichem Indikator an den Stellen 75-76 (EQ) genügen und ihr bräuchtet den READ dann nicht.
Ja, warscheinlich schlägt der setll fehl
read wird nur gemacht bei nicht HO und nicht NI
Read fehler oder
HO an oder
NI an : fülle satz (u.a. aus den KLIST Werten), write satz
beim spätern Durchlesen hab ich dann 2 Sätze mit gleichem key
Den read brauch ich, da ich die Feldwerte des Satzes brauche zum addieren
Robi
Wenn Du eine genaue Analyse machen willst, dann journalisiere die Datei. Am besten vor jedem Lauf einen neuen Journalreceiver erstellen, dann läßt sich das besser auswerten. Anschliessend im Fehlerfall das ganze Journal in eine Datei ausgeben, dann läßt sich exakt der Zustand der Datei vor- und nach dem Fehlerfall rekonstruieren. So finde ich mittlerweile die meisten Fehler wesentlich schneller als mit der herkömmlichen Suche. Journalisierung ist ne tolle Sache.