Nachrichtendatenfeldformate

[TROJANB]

Hallo zusammen,

vielleicht kann mir jemand helfen.

Wie komme ich in einem CL-Programm an die Nachrichtendatenfeldformate (FMT) einer Nachricht, wenn ich die MSG-ID habe.

Mit RCVMSG komme ich ja an die Nachrichtendaten. Dies ist ja ein "langer String". Wenn ich diesen String nun aufteilen möchte, dann benötige ich die
entsprechenden Nachrichtendatenfeldformate, oder?

[Fuerchau]

Genau.
Der DSPMSGD kannst du dir den Feldaufbau ansehen.
In der Beschreibung steht &1 für das 1. Feld, &2 für das 2. usw.

[Pikachu]

Willst du die Nachricht selber wieder ausgeben? Vielleicht genügt dir ja ein RTVMSG, dem du die Nachrichtendatenfeldwerte mit übergibst?

[TROJANB]

Zuerst danke für die antworten.

Das Problem liegt im Zusammenspiel zwischen JAVA und COBOL Programmen.
Aus interaktiven Java-Programmen unter Websphere werden ILE-Cobol Programme aufgerufen. Diese ILE-Cobol Programme schreiben ihre Fehlermeldungen in ihre Programmnachrichtenwarteschlange.
Nun habe ich mir das so vorgestellt, daß am Ende des ILE-Cobol Programms ein "Fehlerhandlingsprogramm" aufgerufen wird. Diese liest alle Nachrichten in der Jobnachrichtewarteschlange aus (egal ob eigene oder Systemmeldungen) ermittelt sich bei den eigenen die Nachrichtendaten und konvertiert diese wie z.B. bei einer CSV-Datei. Sprich die Felddaten werden nicht als einen String an die Java-Programme zurückgegeben, sondern mit z.B. Simikolon getrennt. Die Java Programme können damit ihre Nachrichten aufbereiten und an die Benutzer weitergeben.

Dazu muß ich aber an die Feldinformationen der Nachrichten kommen, um die Nachrichtendaten "zerlegen" zu können.

Mit den "normalen" Commands wie z.B. DSPMSGD komme ich nur über den Umweg *PRINT ==> kopieren in die Datenbank ==> Auslesen und ermitteln der Felddaten ran.

Als weitere Möglichkeit habe ich nun das API QMHRTVM im Forum gefunden. Geht das mit dem, oder gibt es noch eine andere Möglichkeit?

[BenderD]

Hallo,

- gegen DSPMSGD output(*PRINT) ... spricht, dass das nicht Sprach- und Release-fest ist.
-QMHRTVM ist wohl die richtige Ecke, aber wenn ich mir das Ding genauer ansehe, würde es mir wahrscheinlich mehr Spass machen, die COBOL Funktionen in Java neu zu schreiben, aber manchmal wird nach Spass nicht gefragt und man hat keine Wahl, viel Spass also mit QMHRTVM...

D*B

Zuerst danke für die antworten.

Das Problem liegt im Zusammenspiel zwischen JAVA und COBOL Programmen.
Aus interaktiven Java-Programmen unter Websphere werden ILE-Cobol Programme aufgerufen. Diese ILE-Cobol Programme schreiben ihre Fehlermeldungen in ihre Programmnachrichtenwarteschlange.
Nun habe ich mir das so vorgestellt, daß am Ende des ILE-Cobol Programms ein "Fehlerhandlingsprogramm" aufgerufen wird. Diese liest alle Nachrichten in der Jobnachrichtewarteschlange aus (egal ob eigene oder Systemmeldungen) ermittelt sich bei den eigenen die Nachrichtendaten und konvertiert diese wie z.B. bei einer CSV-Datei. Sprich die Felddaten werden nicht als einen String an die Java-Programme zurückgegeben, sondern mit z.B. Simikolon getrennt. Die Java Programme können damit ihre Nachrichten aufbereiten und an die Benutzer weitergeben.

Dazu muß ich aber an die Feldinformationen der Nachrichten kommen, um die Nachrichtendaten "zerlegen" zu können.

Mit den "normalen" Commands wie z.B. DSPMSGD komme ich nur über den Umweg *PRINT ==> kopieren in die Datenbank ==> Auslesen und ermitteln der Felddaten ran.

Als weitere Möglichkeit habe ich nun das API QMHRTVM im Forum gefunden. Geht das mit dem, oder gibt es noch eine andere Möglichkeit?

[Fuerchau]

QMHRTVM, Format RTVM0300 ist das einzige API, mit dem du die Formate auslesen kannst.
Zu beachten ist, dass du Dezimalfelder, Binärfelder, variable Felder beliebig mischen kannst.
Das Trennen in z.B. CSV-Format macht auch hier wenig Sinn, da du ja trotzdem den Nachrichtentext bzw. die Bedeutung (MSGID) der Inhalte benötigst.
Mit RCVMSG und RTVMSG erhältst du direkt den formatierten Text, was wohl erheblich sinnvoller ist.

[TROJANB]

Danke Fuerchau.

Das Problem ist die Sprache. Der Java Banutzer arbeitet in einer Sprache. Die COBOL Programme (existieren alle schon lange) werden mit einem technischen Benutzer aufgerufen. Die Nachrichten, die die COBOL-Programme ausgeben, sind ja von der Jobumgebeung abhängig. Diese wird über die JOBD im Benutzerprofil bestimmt.
An die Java Programme übergebe ich eine MSG-ID (diese Nachricht wird in der Javaumgebung verwaltet) und die entsprechenden Werte mit z.B Simikolon getrennt. Das Java-Programm baut dann die Java-Meldung in der entsprechenden Sprache zusammen.

[Fuerchau]

Die Toolbox der AS/400 erlaubt auch Zugriffe auf Nachrichtendateien.
Man kann je nach Sprache ja eine andere MSGF verwenden und per RTVMSG ja aus der entsprechenden Benutzersprache lesen.
Dann hat man auch nicht das Problem mit dem Auseinandernehmen und neu zusammenbauen.