Os400 Fehler ?

[Robi]

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

[Fuerchau]

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.

[Robi]

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

[Fuerchau]

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).

[Robi]

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]

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.

[Robi]

klassisch mit bz in ho und ni
Pgm ist in ordnung, da gibt's nix
Wiederhollauf hat ( bisher) den fehler nicht gebracht
Robi

[Pikachu]

Vielleicht schlägt der SETLL 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.

[Robi]

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

[pwrdwnsys]

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.

[kuempi von stein]

Hello,

ohne Listing ist das schwer zu sagen.
Setze doch mal für Testzwecke auch die dritte Bezugszahl an.

The resulting indicators reflect the status of the operation. 

If an indicator is specified in positions 54 and 55, 
it is set on when the search argument is greater than the highest key or relative record number in the file. 

If an indicator is specified in positions 56 and 57, 
it is set on when an error occurs during running of the operation.

If an indicator is specified in positions 58 and 59, 
it is set on when a record is present whose key or relative record number is equal to the search argument. 

Du schreibst ja, Du frags HO und LO ab. Und nicht EQ.

Da gibt es noch viel wo man steuern könnte...

kuempi

Edit: sehe gerade, Pikachu hat das schon vorgeschlagen.