Message aus MSGF in RPG-ILE auslesen

[Fuerchau]

Die Ursprungsdefinition war fast korrekt. Die B-Felder sind jetzt korrekt müssen aber initialisiert werden.

p_Message ist wiederum eine Struktur: RTVMxxxx !

p_MsgLen inz(%size(p_Message)) <= Größe Empfangspuffer
p_Format inz('RTVM0100')

p_MsgFile ist eigentlich auch eine Struktur mit 2 Felder á 10 Zeichen

p_ReplData ist auch eine Struktur, die die Feldinhalte einer MSG mit Feldern enthält, sind keine Felder vorhanden, kann p_ReplDataLen auf 0 gesetzt werden, ansonsten enthält es wiederum die Größe der Struktur.

p_SubstVal muss *YES (mit ReplData) oder *NO enthalten.
p_RetFormat muss *YES/*NO enthalten (Textformatierungen der Nachricht).

In der Struktur p_Message findest du dann das Ergebnis, allerdings beginnt die Nachricht an Stelle 25 in der Länge, die ab Stelle 13 im 10I-Format steht.

[malti]

MOVE FENR ERMSG fficeffice" />>>
MOVEL 'MEB' ERMSG >>
Z-ADD 3 ERREBE >>
Z-ADD 132 ERRLNG >>
CALL 'SUBR23R3' >>
PARM ERMSG 7 >>
PARM ERRTXT 132 >>
PARM ERREBE 1 0 >>
PARM ERRRC 1 0 >>
PARM ERRLNG 4 0 >>
MOVEL ERRTXT ERRMSG 80 >>

[Frank Hildebrandt]

Wirklich interessant. Von einem Programm SUBR23R3 habe ich noch nie etwas gehört. Das Programm befindet sich in der QSYS, ist jedoch nicht in der API Dokumentation beschrieben. Daher wäre ich mit der Verwendung vorsichtig. Es könnte durchaus passieren, dass mit einem zukünftigen OS/400 Release das Teil nicht mehr da ist.

[malti]

Hat seit 10 Jahren alle Releasewechsel ohne Schaden überlebt

[kuempi von stein]

Der war GUT!

Die SUBR23R3 gibt es schon seit Urzeiten.
Kommt von der /38 oder noch älter.
Wurde schon vor 20 Jahren in den RPG-Kursen benutzt.

Siehe hierzu auch den Link.

Wenn die jemals eingestampft werden würde, würden 1000e Programme nicht mehr laufen...

kuempi

[Frank Hildebrandt]

Dann ist das Teil ja doch von IBM dokumentiert. Halt nur nicht da, wo ich es vermutet hätte. Und damit wird es wohl auch noch in 100 Jahren unterstützt, so wie es IBM ja immer macht - Ausnahmen bestätigen die Regel. Bleibt nur noch die Frage, ob TomWaf mehr braucht als SUBR23R3 bietet, oder ob es reicht.

[malzusrex]

naja, ich sehe in dem beitrag von malti jede menge smileys

[TomWaf]

Vielen Dank für die rasche Hilfe.
Ich habe mich für die Variante mit der Prozedur entschieden. Funktioniert einwandfrei.
Laut IBM-Doku wäre ich nie zu dieser Parameterbeschreibung gekommen.

[maddog]

Vielen Dank fur die Hilfe.

Ich habe mich für die CL-Variante mit dem Befehl RTVMSG entschieden.

[Fuerchau]

Das wird es auch weiterhin (denke ich):
http://publib.boulder.ibm.com/cgi-bi...BKAQU00/11.2.1

Allerdings ist die MSGF fixiert und ich benötige einen OVRMSGF wenn ich was anderes will.
Das ist obiges API in der heutigen Zeit wohl flexibler.

PS:
Allerdings frage ich mich, warum dann nicht ein kleines CLP mit Parametern und RTVMSG als CMD ?
1. Nicht so kompliziert
2. besser kontrollierbar
3. leichter verständlich ?!
Und ausserdem, wenn ich schon einen CALL machen muss, egal ob API oder SUBR23R3, dann mach ich das lieber per CLP.

[Frank Hildebrandt]

Wie immer kommt es einfach darauf an, was man machen will. Mit dem API kann man die Nachrichten abrufen, ohne die Nachrichten-Id. zu kennen. Also in etwa durchlesen wie eine Datei. Gesteuert wird das über den Parameter 'Retrieve option'. So etwas geht mit dem RTVMSG nicht. Auch ein DSPMSGD bringt da wenig, da sich die Ausgabe auf den Bildschirm und den Spool beschränkt. Wenn man natürlich die die Nachrichten-Id. kennt, dann ist RTVMSG sicherlich sinnvoll.