Unglaublich aber Wahr

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

[andreaspr@aon.at]

und ich hatte auch noch nie probleme damit...

also nach diesem thread glaub ich dir DAS zumindest nicht 100%ig

im rational for i gibts zwar auch einen debugger aber stimmt schon, der von microsoft ist einfach besser.

[woodstock99]

@andreaspr@aon.at..


hmmmm nö dann hab ich es falsch rübergebracht ((( ..... sorry


ich gehe da vollkommen mit der meinung von fuerchau

"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"

konform...... mich hat halt nur die besagte Konstellation total irritiert..... dem debugger trau ich zumindest bis jetzt zu 100%...

[andreaspr@aon.at]

ich hatte eigentlich auch noch nie probleme mit dem debugger ... früher halt.
das problem war immer (glaub ich), dass beim erstellen des programms (mit dem veränderten code) und im debug-modus, beim ausführen noch der "alte" code ausgeführt wurde.
und das obwohl ich das pgm neu erstellt habe und auch mit wrkobj *allusr/mypgm nur ein mal im system vorhanden war und auch bei der letzten ausführungszeit das aktuelle datum drinnen stand.
also alles wies darauf hin, dass das neue pgm gestartet wurde, jedoch wurde nach dem ergebnissen zu urteilen, das alte pgm ausgeführt.
führte ich das ganze ohne debugger aus, gings ganz normal. (sogar auch ohne das pgm neu erstellen zu müssen).

ich kann nur sagen, dass wir in der firma (die viel mit dem debugger arbeiten) nicht die einzigen sind die das problem kennen. hatte auch mal mit einem kunden von uns darüber gesprochen, und auch er kannte das problem.

fact ist nur: dieses problem gabs bis jetzt NUR mit dem debugger. aber das auch nur eher selten. (ca. 3, 4 mal im jahr).

@Fuerchau: ich dachte früher als schüler immer die AS/400 ist unfehlbar, musste aber mit der zeit erkennen, dass auch sie manchmal ihre bugs hatte, ist ja doch nur von menschen erschaffen

lg andreas

[woodstock99]

das problem mit dem alten code kenne ich nur wenn ich meinen alten debug vorgang nicht beendet und nicht nochmal neu aufgesetzt habe .......
auch wenn ich mal das pgm abgebrochen usw habe...

das die as400 auch mal ihre macken hat und eine neuanmeldung auch mal wahre wunder bewirkt da bin ich jetzt vollkommen auf deiner seite ))....

[Fuerchau]

Gegen die Bugs habe ich ja auch nichts.
Wichtig in dem Zusammenhang ist einfach, dass nach dem Neuerstellen eines Programmes die aktuellen ACTGRP's geschlossen werden müssen da sonst tatsächlich die vorherige Version noch aktiv ist.
Ein RCLRSC beim OPM und RCLACTGRP bei ILE reicht meistens. Allerdings sollte man RCLACTGRP von der höchsten Aufrufebene durchführen, da es sonst zu Folgeproblemen führt bzw. führen kann (z.B. MCH-Fehler).

Insbesonders beim SQLRPGLE habe ich mir es angewöhnt mich doch ab- und wieder anzumelden um tatsächlich alle Reste zu entfernen da auch ein RCLACTGRP ggf. nicht alle SQL-Resourcen zurückforderte.

Wie ich schon sagte, ein Testszenario sollte eine saubere Umgebung haben .

[woodstock99]

....

fazit.....
wir sind uns ja doch irgendwie zum schluß immer alle einig

..


schon mal ein frohes fest an alle...
und an guten rutsch
damit wir uns im nächsten jahr hier alle gesund und munter wieder treffen .....

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

[andreaspr@aon.at]

RCLRSC und RCLACTGRP ist ein guter tipp. werde ich das nächste mal ausprobieren.

damit schließe ich mich woodstock99 an ... ende gut, alles gut

[K_Tippi]

Hi,
kann es sein, dass der gesuchte Satz erst kurz vorher von einem Anderen PGM geschrieben wurde. Dann setze mal die Datei auf zwingend screiben "1" FRCDTA glaube ich. Ich hatte so ein Problem mal selbst. Der Satz stand noch im Speicher war aber noch nicht auf Platte und konnte von einem folgenden PGM nocht nicht glesen werde. Dieser Fehler existiert seit V1R3 :-(
Im DBG-Modus hats bei mir auch immer geklappt aber im BAtch nur wenn die Auslastung so hoch war, dass die AS den Cache gleich leeren musste.

Klaus