View Full Version : Unglaublich aber Wahr
woodstock99
29-10-09, 07:33
@cbe
1. STRSRVJOB ErsteSitzung
2. STRDBG PROGRAMM
3. Aufruf in ersterSitzung
1. STRSRVJOB ErsteSitzung mit attributen der zweiten
3 .. aufruf in zweiter sitzung oder??
... das ist soweit alles perfekt, aber wenn ich das alles richtig verstanden habe, hat es ja beim debug immer gefunzt und ist dann irgendwann (wenn keiner geguckt hat) schief gegangen. Der Punkt ist also: die Konstellation zu finden, wo es nicht ging! Dafür gibt es zwei Ansatzpunkte:
a) Journalisierung der betreffenden Datei (oder besser aller)
b) verbessertes Errorhandling im Programm
Am Besten beides!!!
zu b: minimal bei dem verdächtigten chain bei nicht gefunden alle Informationen protokollieren (z.B. per QMHSNDPM eine CPF9898 an das Joblog schicken mit Inhalt der Keywerte als Hexadecimalwerte, sowie die Informationen aus der einzubauenden INFDS
D*B
moin moin,
@cbe...
also ich habe nur ein cl programm das 21 solcher ovrdbfs enthält wobei die anzahl ja für die tonne ist.. diese cl called mein programm...
zum testen der offenen pfade usw habe ich bis jetzt halt immer z.b wenn ich ein programm debuge die methode
shift + esc drücken , dann 3 eingeben . dann f10 und zusatzzahl die 14 :).... dann sehe ich ja auch die offenen pfade usw.. und die passen :((((......
aber zu jugend forscht zwecken teste ich deine variante gleich mal aus :)
Hallo Woodstock,
Debuggen eines anderen Jobs ist nicht so schwierig und oft hilfreich:
nimm an Du hast 2 Sitzungen:
SESSIONA - hier willst Du Dein Programm P aufrufen
SESSIONB - hier willst Du debuggen
In SESSIONB aufrufen:
STRSRVJOB SESSIONA
(wenn mehrere gefunden werden, den aktiven mit 1 auswählen)
STRDBG P und Haltepunkt setzen
(bzw. STRISDB je nachdem)
Anschl. in SESSION A das problematische Programm aufrufen (dort ohne Debug)
Wenn P den Haltepunkt erreicht, geht in SESSIONB der Debugger an.
Um den Job genauer anzuschauen könntest du in SESSIONC aufrufen:
WRKJOB SESSIONA und z.B. die offene Datei prüfen.
Das funktioniert so ähnlich übrigens auch mit Batch-Jobs
Gruß, Christian
woodstock99
29-10-09, 16:30
@cbe ...
danke nochmal für deine genauere ausführung aber das hatte ich schon gechecked .... :).. mein post sollte eigentlich nur ein hinweis sein das punkt drei in einer zweite sitzung gemacht wird....
aber ..... uPPPPSSSS sorry das sind frage zeichen.. bin auch schon blöd.... sorry dast deswegen soviel tippseln hast müssen
@bender danke für den tipp
aber ich bin heute nicht dazugekommen.....
aber heute ist es wieder gelaufen...
ich hab keine ahnung warum..
der chain müsste immer klappen weil..
ich verwende das feld länderkennzeichen aus dem kundenstammsatz und mache dann einen chain auf die länderdatei selber und lese einen wert aus....
falsche werte können im länderkennzeichen nicht drin stehen weil ersten wird bei der erfassung gegen tabelle geprüft und zweitens habe ich schon die länderkennzeichen im kundenstamm kontrolliert ob die vom wert her passen und die passen alle...
@cbe ...
danke nochmal für deine genauere ausführung aber das hatte ich schon gechecked .... :).. mein post sollte eigentlich nur ein hinweis sein das punkt drei in einer zweite sitzung gemacht wird....
aber ..... uPPPPSSSS sorry das sind frage zeichen.. bin auch schon blöd.... sorry dast deswegen soviel tippseln hast müssen
kein Problem.
Dass man mit solchen Problemen immer soviel unnütze Zeit verbraten muss, was?
Dass es heute funktioniert ist unfair, wie soll man so den Fehler nachstellen? Ich drück Dir also die Daumen, dass es bald wieder auftritt;)
Gruß, Christian
... woraus zweierlei folgen könnte
- stimmt nur, wenn ein kundenstammsatz gefunden wurde und das entsprechende Key Feld nicht überschrieben wurde
- der chain klappt tatsächlich und der Fehler entsteht woanders
D*B
der chain müsste immer klappen weil..
ich verwende das feld länderkennzeichen aus dem kundenstammsatz und mache dann einen chain auf die länderdatei selber und lese einen wert aus....
falsche werte können im länderkennzeichen nicht drin stehen weil ersten wird bei der erfassung gegen tabelle geprüft und zweitens habe ich schon die länderkennzeichen im kundenstamm kontrolliert ob die vom wert her passen und die passen alle...
woodstock99
30-10-09, 06:46
@bender
jupp
aber die routine wird nur duch laufen wenn ein kundenstammsatz da ist ( alles andere wär ja ein grober patzer der programmierung :) ) und das länderkennzeichen wird nicht überschrieben..
ja variante 2( der chain klappt tatsächlich und der Fehler entsteht woanders) da geb ich dir recht muß auch sein....... nur wo und WARUM ist ja eigentlich die schlüsselfrage...
..
ich lese zuerst rechnungen komplett durch danach danach gutschriften und erzeuge in der buchhaltung offene posten
diese beiden abläufe verwenden die selben routinen im pgm ....
der fehler tritt aber nur ( manchmal je nach tageslaune ) bei den gutschriften auf obwohl es haar genau der gleiche ablauf ist wie bei den rechnungen..
also kopfsatz lesen,
dann positionen verarbeiten,
dann KUNDE lesen anhand des wertes aus dem kopfsatz (Fehlerprüfung usw alles vorhanden, aber kunde muß ja da sein)
so und dann geht die sache mit dem länderkennzeichen los ... :((...
wenn dann sind aber immer alle sätze der gutschriften falsch die ich übernehme.....
sprich es wird niergends das länderkennzeichen verarbeitet aber wie gesagt auch wiederrum nur TAGESFORM weiße....
hab jetzt das programm 345634836 mal gedebugged :)) und es hat immer gefunzt weil die werte einfach da sein müssen ......
woodstock99
30-10-09, 06:51
@cbe.....
merci fürs daumen drücken :))).. ich geb die hoffnung nicht auf :)))
... wobei wir wieder beim OVRDBF als Hauptkandidat sind; da muss es irgendwo einen Unterschied im Callstack geben, oder in der Ablaufhistorie des Programms...
D*B
, der schon weiß warum sich seine Nackenhaare beim OVRDBF und den LIBL Spielereien kräuseln...
wenn dann sind aber immer alle sätze der gutschriften falsch die ich übernehme.....
......
woodstock99
30-10-09, 09:11
@ bender
ja das hab ich mir auch schon gedacht aber des kann doch nicht sein oder ...
- also ablauf zu 100 % identisch aber sowas von :))...
- ovrdbf des muß doch funzen oder hat der befehl ab und zu einen an der waffel ??
ich glaub schön langsam an alles :)..
in jedem cl ist es immer der gleiche ablauf bei uns
OVRDBF FILE(xxx) TOFILE(xxx/xxx) +
OVRSCOPE(*JOB) OPNSCOPE(*JOB)
CALL PGM (xxx/xxx)
DLTOVR FILE(*ALL) LVL*JOB)
also alle überscheibungen werden nach beenden des jobs gelöscht....