System Default-Parameter

[Toschie]

Hallo zusammen,

dieses mal habe ich kein Problem sondern würde gerne was in Erfahrung bringen.
Wir haben ab und an das Problem, das ein Programm mit einem Dezimaldatenfehler abbricht.
Ein Dump hilft nur so weit, das wir die Felder prüfen können.
Es wird hierbei eine Zeilennummer ausgegeben, die der Sequentiellen Zeile entspricht (So habe ich das verstanden!).

Nun habe ich festgestellt, das es div. Optionen gibt, die man im Header von ILE-Sourcen angeben kann um u.a. die richtige Zeile im Dump zu erhalten.
Die Option: *SRCSTMT ist dabei die interessante.

Ich habe bei uns vorgeschlagen, den Parameter automatisch beim generieren von ILE-Sourcen aufzunehmen.
Die Bedenken meiner Kollegen, warum hat die IBM diesen Parameter nicht als Standard, was bewirkt diese Parameter noch alles, das man nicht direkt sieht?

Wisst ihr mehr über diesen Parameter bzw. könnt mir Quellen nennen, wo ich mich über diese Option weiter schlau machen kann =)


Anbei noch ein kleines Programm, wo ich einen Dump provoziere um die richtige Zeile zu erhalten.



0001.00 H DEBUG DECEDIT('0,') DATEDIT(*DMY.) OPTION(*SRCSTMT):confused:
0002.00 FFMX04PF IF E K DISK
0003.00 C**
0004.00 C EXSR SUB10
0005.00 C**
0006.00 C MOVE '1' *INLR
0007.00 C*----------------------------------------------------------------
0008.00 C** S U B 1 0 AUSLESEN DRUCKDATEI BEI SAMMELAUFRUF
0009.00 C*----------------------------------------------------------------
0010.00 C SUB10 BEGSR
0011.00 C**
0012.00 C Z-ADD 0 FXDRNR
0013.00 C Z-ADD 0 X2 4 0
0014.00 C FXDRNR SETLL RFMX04PF
0015.00 C *IN35 DOUEQ '1'
0016.00 C READ RFMS04PF
0017.00 C ADD 1 X2
0018.00 C *IN35 IFEQ '0'
0019.00 C X2 IFGT 999
0020.00 C MOVEL 'ÄÖPKNK9*' X2
0021.00 C END
0022.00 C END
0023.00 C END
0024.00 C**
0025.00 C ENDSR



Danke für eure Bemühungen =)

[AG1965_2]

Weil die IBM nachträglich eingeführte Schlüsselworte nie (oder nur ganz selten) als Standard benutzt, weil es existierende Programme evtl. gefährden könnte.
Es hätte sich ja wer schon irgendwelche Programme schreiben können, die sich auf die alte Nummer verlassen. (Fehlerhandler, Debugger, etc.)
In dem obigen Beispiel nutzt Dir der Datenbereich RPGLEHSPEC leider auch nichts, weil ja schon eine H-Bestimmung im Programm vorhanden ist.
Am besten ist man wohl nach wie vor mit dem guten alten /COPY unterwegs, in das man all die Goodies eintragen kann, die über die Jahrzehnte daherkommen und somit bei der nächsten Umwandlung der Programme verwendet werden. (z.B. OPTION(*NODEBUGIO), das ein Stehenbleiben des Debuggers auf I und O-Statements verhindert, usw.)
Das ist auch besser als z.B. der Datenbereich, da beim Posten einer Source gerne auf so etwas vergessen wird, oder jemand, der in die Source schaut, nicht an den Datenbereich denkt.

[MR-BN]

unsere Header-Anweisungen sehen grundsätzlich so aus

H DECEDIT('0,') DFTNAME(AR039) DATEDIT(*DMY.)
H OPTION(*NoDebugIO: *SRCSTMT: *SHOWCPY)
H INDENT(' |') USRPRF(*OWNER)
H DEBUG(*DUMP)

[Toschie]

Also habe eure Bemerkungen gelesen und auch soweit verstanden.
Des Weiteren habe ich mich noch weiter mit dem Thema befasst und das so verstanden, das zur Wandlung die Source neu numeriert wird und das dann im Objekt gespeichert werden.
Ergo passiert doch nichts weiter damit oder?
Fehlt mir da noch eine Info?

Danke =)