Unglaublich aber Wahr

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

:D ....

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

:D ..


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

[Fuerchau]

Dies ist kein Fehler sondern ein Feature!

Wenn eine Datei für Output geöffnet wird (F-Spezifikation) wird von RPG/LE immer geblockt (das steht auch im Spool).
Somit weiß die DB noch gar nichts von diesem Satz und kann dies anderen nicht mitteilen.

Umgehung:
Datei mit U für Update öffnen, dann wird auch nicht geblockt.

Damit der RPG-Compiler nicht auch noch das Compilieren unterbindet, habe ich dann immer eine Pseudo-SR, die alle nötigen E/A-Befehle enthält.

Beim ILERPG funktioniert das auch ohne Pseudobefehle.

FRCDTA verlangsamt das System drastisch, das Blocken wird dann aber auch verhindert.
Im Joblog findet man dann meist den ominösen Hinweis "... wurde in SEQONLY(*NO) geändert ...".