Anmelden

View Full Version : CRTPF mit LVLCHK *NO



kuempi von stein
19-03-08, 14:40
Achtung: lange Geschichte, dabei gehts mir nur um eine kleine Frage erst mal...

Hello,

habe hier ne Datei, die rumzickt.
Ein DSPFD bringt nen MCH1210 mit Begründung "Empfängerwert zu klein, um Ergebnis zu halten".
DSPPFM und SQL brauchten mehrere Minuten um zum Zuge zu kommen.
Dann soll die Datei angeblich Millionen von Sätzen haben, obwohl nur rund 11.000 records drin sind.

Habe als erste Massnahme das Ding hin und her kopiert mit CLRPFM zwischendurch.
Nun kann man zumindest wieder zügig die Daten einsehen, obwohl der erste record bei 95000 nochwas liegen soll.
Sehr verwunderlich, da ich gelöschte records nicht erlaubt habe und die Datei auch gar nicht so konzipiert ist.

Die sonst so gut funktionierenden internen (selbstgeschriebenen Tools) versagen hier auch, weil merkwürdigerweise das Hauptprogramm welches mit der Datei arbeiten sollte laut Quellsource das gar nicht macht.
Hier kommt also anscheinend ein weiterer Fehler hinzu, das jemand an den Sourcen rumgepfuscht hat.

Da das ein 24/7 Produktivsystem ist, kann ich auch keine grossen Dinge starten RCLRSC oder sowas.

Dachte mir in meinem jungendlichen Wahn folgendes (und nun kommen wir endlich zu meiner Frage gleich):

Lösche ich doch die Datei und die drei logischen die dranhängen, erstelle die PF neu mit LVLCHK *NO und hänge die logischen wieder ran und kopiere die Daten aus ner kopierten Datei wieder zurück.

Damit sollte dann das 95000+ Problem und eventuell damit arbeitende Programme zurande kommen, ohne dass hier was einbricht?

Also die Frage weil ich sowas (LVLCHK *NO) ewig nicht mehr rumgepfuscht habe:

Kann ich die PF mit LVLCHK *NO erstellen und die wieviel auch immer Programme kommmen klar damit oder haut mir das System dann um die Ohren?

kuempi

Fuerchau
19-03-08, 14:47
LVLCHK *NO ist dann unkritisch, wenn der Pufferaufbau auch weiterhin identisch bleibt.
Alle Programme kommen damit zurecht.

Die Frage ist wohl eher, warum denn da so viele "kaputte" Daten drin sind.

Ein DSPFD mit MCH1210 deutet eher auf ein kaputtes Objekt hin.

Ggf. nicht per CPYF sondern mit SQL "insert ... select" kopieren.

Pikachu
19-03-08, 14:50
Welches Problem hast du vor, mit einem LVLCHK(*NO) zu umgehen oder zu beheben?

Hast du schon einen RGZPFM probiert, um die gelöschten Datensätze aus der Datei zu werfen?

kuempi von stein
19-03-08, 14:58
@Pikachu


Hast du schon einen RGZPFM probiert, um die gelöschten Datensätze aus der Datei zu werfen?

Nein bis jetzt noch nicht. Habe wie gesagt nen CPYF gemacht in ne eigene Bibliothek dann nen CLRPFM und dann zurückkopiert.
Wobei wie geschrieben gelöschte Sätze nicht mitkopiert wurden und auch gar nicht in der Datei sein dürften.



Welches Problem hast du vor, mit einem LVLCH(*NO) zu umgehen oder zu beheben?


Ich will die 95000+ in Ordnung bringen und hoffe, dass ein DSPFD dann wieder funktioniert.

@Fuerchau


Ein DSPFD mit MCH1210 deutet eher auf ein kaputtes Objekt hin.

Ja das die File nen Schaden ist ist mir klar, deshalb will ich die ja löschen und neu erstellen so das funktioniert hoffentlich.


Ggf. nicht per CPYF sondern mit SQL "insert ... select" kopieren.

Was ist da anders als beim CPYF? Sollte das Ergebniss nicht das gleiche sein?

kuempi

Pikachu
19-03-08, 15:06
Warum sollen keine gelöschten Datensätze in der Datei sein dürfen?

Die Datei muß nicht defekt sein! Es ist vermutlich nur so, daß beim DSPFD ein numerischer Wert ermittelt wird, der zu groß für die Anzeige ist, und dies wurde von IBM wohl noch nicht berücksichtigt.

kuempi von stein
19-03-08, 15:12
Warum sollen keine gelöschten Datensätze in der Datei sein dürfen?

Die Datei muß nicht defekt sein! Es ist vermutlich nur so, daß beim DSPFD ein numerischer Wert ermittelt wird, der zu groß für die Anzeige ist, und dies wurde von IBM wohl noch nicht berücksichtigt.

Nein nein doch doch
*seufz*
Also die Datei ist so konzipiert (inklusive der Programme die damit arbeiten),
dass da keine Sätze gelöscht werden.
Ist ähm.. so ne Art Protokolldatei.
Und wenn ich die hin und her kopiere müsste nach meinem bisherigen Wissen die relative rrn bei 1 anfangen.
Die 95000+ und der MCH bei DSPFD zeigen ja klar, dass was kaputt ist.
Und zu gross ist nicht, weil offiziell ja nur 11000 records ca. sind.

k.

Pikachu
19-03-08, 15:24
Ob gelöschte Sätze mitkopiert werden, hängt vom Parameter COMPRESS des Befehls CPYF ab. Vielleicht wurde dieser bei euch auf *NO geändert?


Lösche ich doch die Datei und die drei logischen die dranhängen, erstelle die PF neu mit LVLCHK *NO und hänge die logischen wieder ran und kopiere die Daten aus ner kopierten Datei wieder zurück.
Wenn die neu erstellen Dateien mit LVLCHK(*YES) die selben Formatebenen besitzen wie die alten (sollte sein, wenn sich keine Formate und Felder geändert haben, siehe mit DSPFFD), dann kommen die vorhandenen Programme auch mit ihnen klar und müssen nicht neu gewandelt werden.