Unglaublich aber Wahr

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

[andreaspr@aon.at]

hallo *all,
das problem kenne ich!
mit dem debugger bin ich auch schon auf genau solche probleme gestoßen.

habe ein pgm erweitert, und bei mir gings nicht und bei einem kollegen gings. (gleicher user, gleiche libl usw.)
ich war auch total verwirrt, da ich sowas noch nie erlebt habe. habe aber auch selten mit debugger gearbeitet.

jedoch wird in unserer firma oft der debugger eingesetzt und daher ist dieses problem nicht unbekannt.
ich weis zwar nicht wie dieses problem zu lösen ist (wenn überhaupt). was ich aber weis ist, dass der debugger kein perfektes tool ist! zumindest auch bei den nicht-free programmen.

lg andreas

[woodstock99]

@andreaspr@aon.at..

also der debugger ist ja ganz ok und ich hatte auch noch nie probleme damit...

naja der komfort ich gegensatz z.b. zum visual studio debugger hält sich aber echt in grenzen ))...

aber mei so ist sie halt unsere black box )

[Fuerchau]

Also dem Debugger die Schuld zuzuschieben ist ja schon schlimm. Wäre ja furchtbar, wenn dem so wäre.

Der einzige Grund, warum im Debugger manchmal etwas anders läuft ist nicht der Code selber sondern die abhängige Zeit. M.a.W., im Debugger läuft man etwas langsamer um eben zu testen und im Testszenario hat man (meist) auch eine definierte Umgebung.
Code ist Code und läuft nun mal immer gleich ab, egal ob mit oder ohne Debugger.

Ich habe diesbezüglich noch nie auf keinem System ein Problem gehabt.

[woodstock99]

hab ich doch gar nicht (((..

hab doch geschrieben ich hatte noch nie damit probleme und wie du schon schreibst ich bin ja auch davon überzeugt das die dinger egal welcher zu 1000% laufen und richtig sind....

[BenderD]

... das Problem sitzt meistens vor (in Worten: vor) dem Bildschirm!

D*B

Also dem Debugger die Schuld zuzuschieben ist ja schon schlimm. Wäre ja furchtbar, wenn dem so wäre.

Der einzige Grund, warum im Debugger manchmal etwas anders läuft ist nicht der Code selber sondern die abhängige Zeit. M.a.W., im Debugger läuft man etwas langsamer um eben zu testen und im Testszenario hat man (meist) auch eine definierte Umgebung.
Code ist Code und läuft nun mal immer gleich ab, egal ob mit oder ohne Debugger.

Ich habe diesbezüglich noch nie auf keinem System ein Problem gehabt.

[woodstock99]

... das Problem sitzt meistens vor (in Worten: vor) dem Bildschirm!

D*B

hmmmm was willst du mit
(in worten :vor) andeuten ???