Umwandeln mit *debugio und *nodebugio

[TheDevil]

Hallo Forum,

heute war mal wieder debug Tag. Normalerweise schmeisse ich dann STRDBG an, setze einen Breaktpunkt und los gehts ... heute dann folgendes. Der Debugger kam zu einem CHAIN Statement. F10 und schwupps war ich oben in den F Bestimmungen. Dort hing ich nun und kam nicht weiter (F10 brachte rein gar nichts). Ein Testprogramm zeigte das für mich normale verhalten (CHAIN, F10 und ich stehe auf dem nächsten Programmierschritt). Suchen suchen suchen .. warum nur ??? Und dann habe ich in den H Bestimmungen die Differenz zu den beiden Programmen gefunden ... *debugio und *nodebugio. Leider kann ich mit der Erklärung der Hilfe nicht so ganz viel anfangen und deshalb hier mal meine Frage :

Warum geht ein Debug mit *debugio in dei F Bestimmungen und bleibt dort ? Was ist der Unterschied zwischen diesen beiden Optionen ?

Vielen Dank schon mal im voraus für die Antworten...

Bis dahin aus Flensburg
Ralf

[malzusrex]

Jetz mal ganz unprofessionell.
Bei *NoDebugIO nimmt der den ganzen Datensatz und geht zur nächsten Zeile.
Bei *DebugIO nimmt er bei jedem F10 (Steep) immer nur 1 Feld des Satzes. Das heißt, 50 Felder = 50 mal F10 bömpeln bevor er weiter springt.

Gruß Ronald

[Anton Gombkötö]

Was er da genau tut, kann man - wohl das letzte Mal :-) - sehen, wenn man mit DBGVIEW(*ALL) umwandelt und im Debugger mit F15 die List-Ansicht auswählt.
Hinter einer RPG-I-Anweisung steckt also ausführbarer Code (nämlich das Übertragen vom DB-I/O-Puffer in den RPG-Puffer), sonst würde er da nicht stehen bleiben.

[TheDevil]

Hallo Ronald,

:-() Habs gerade mal ausprobiert ... Bei 36 Feldern 33 mal F10 und dann gings weiter ...

OK nur ist dies sinnvoll ? Woher weiss ich welches Feld er gerade beackert ? Also ich habe es bisher noch nicht vermisst :-()

Nochmals danke ... jetzt sind WIR wieder mal ein bisserl schlauer ...

Gruß,
Ralf

[Robi]

7031er Felder liest er nicht, daher warscheinlich nur 33 statt 36 mal

[Fuerchau]

Nun ja, der Compiler generiert hinter jedem Statement einen Breakpoint (als MI-Deklaration).
Der Einzelschritt läuft nun von einem Breakpoint zum nächsten.
Die Anzahl der Schritte beim lesen/Schreiben hängt von der Verwendung der Felder ab.
Der Compiler generiert nur Moves von/nach für die im Programm verwendeten Felder. Hat man diese in einer eigenen "E DS" noch zusätzlich definiert werden eben alle Felder angesprochen.

Sinn und Zweck kommt ggf. aus sehr alten Zeiten oder aus z.B. COBOL-Anwendungen.
In DDS-beschriebenen Feldern kann nun mal mit COBOL (mit RPG nur bei intern beschriebenen) auch Schrott in numerische Felder geschrieben werden.
Beim Lesen mit RPG fällt RPG dann beim Move von Schrott auf die Nase.
Durch Abzählen der Schritte beim Chain/Read im Debugger ist nun das problematisch Feld herauszufinden, da ja ein MCH-Fehler bei der RPG-EA-Anweisung und nicht beim tatsächlichen Move ausgeworfen wird .