Unglaublich aber Wahr

[cbe]

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]

@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]

@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

[BenderD]

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

@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]

@cbe.....

merci fürs daumen drücken )).. ich geb die hoffnung nicht auf ))

[BenderD]

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

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

[BenderD]

... Programmierer haben eine Waffel, ein Command kann wegen fehlender nix an selbiger haben...

OVRDBF können allerdings von der Jobhistorie beeinflusst sein!!!
Wenn ein OVRDBF bestehen bleibt (wg. abnormal exit z.B.), dann zieht ein nachfolgender OVRDBF gleichen Namens ohne SECURE(*YES) nicht mehr!!!
Wenn eine Datei offen bleibt ist ein nachfolgender OVRDBF ohne Effekt (da gabs in der Tat mal in der Kombination mit SQL Zugriffen Betriebssystem Probleme).

D*B

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

[Liebhoff]

Also ich bin der Meinung ich hatte genau den selben Murks auch schon mal. Das Problem war damals aber gar nicht der OVR sondern das RPG dort wurde der CHAIN in die Datei gemacht. Die Datei war UPDATE eröffnet wurde aber tatsächlich nur für einen INPUT mit CHAIN genutzt. Ich hatte das selbe Phänomen, mit Debug gings ohne nicht. Habe damals dann erst in einer Dummy Routine (welche nie aufgerufen wurde) einen WRITE und einen UPDATE auf die Datei eingebaut. Das hat dann gefunzt. Da ich natürlich aber sauber arbeiten wollte, habe ich dann am Ende auf eine nur INPUT eröffnete Datei umgestellt. Der Update erfolgte über eine andere logische Datei. Wahrscheinlich eröffnet der Debug Modus die Datei anders, verstanden habe ich es eigentlich nie richtig, nur es lief dann wie gesagt. Auch an dieser Stelle galt eben mal wieder RPG - Raten Probieren Glauben.

Wollte nur mal diesen anderen Aspekt einwerfen, vielleicht hilft es ja.

Thomas

[Robi]

Ich hatte mal was ähnliches ...
daher sag ich mal :
Für mich liest sich das als ob die Datei, warum auch immer, beim OVR schon offen ist.
Wie sind eure ACTGRP Parameter ?
alles *caller oder alles QILE
Gruß
Robi

[woodstock99]

so sorry das es ein wenig gedauert hat aber urlaub/krank usw......

um aber dieses thema abzuschließen wollte ich nur schreiben das ich das programm nochmal komplett neu codiert (in free rpg) habe und jetzt funzt es..

warum es aber jetzt funzt das weiß der himmel......