× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Not documented in [all] the /correct/ place(s) perhaps, but it is [even if not well] documented.
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/smsg.htm

The RTVMSG CL and the QMHRTMSS Retrieve Message API are both affected by the documented result of message CPF2457 in QCPFMSG being returned for the condition of a message identifier not found in the specified message file. And although not explicitly stated, presumably the MSGF(*LIBL/QCPFMSG) is utilized to locate the CPF2457. I can only guess that the effect for MSGID(CPF2457) not found in MSGF(QCPFMSG) might be blanks :-) since *that* is [rightly] not documented ;-)

The status message can be monitored, e.g. MONMSG, and it is listed as such on the RTVMSG help text.

Regards, Chuck

Bruce Vining wrote:
You are correct -- it's not documented and that is (somewhat) what is returned for the MSG parameter. Which really, really surprises me.

Is your &TXT variable defined as *Char 30? The reason I ask is that the actual text returned is 'Text not available for message
XXXXXXX file YYYYYYYY.' which would not compare as *EQ if &TXT is
defined as longer than 30 characters.

The CPF2419 should really be signaled as an *ESCAPE, rather than *STATUS, which makes me wonder if "someone" in the deep, dark
past was too scared to add an escape to this command (years after
it became available).

Would anyone with a non-English NLV installed care to try this? I
suspect (hope) it's picking up the text from a message file, in
which case this code would not work properly outside of an
English environment. If, on the other hand, it still comes back
as English then "someone" has hardcoded English text in their
code. A very nasty thing to do.

In any case, this should be reported to IBM.

On Thu, May 6, 2010 at 9:24 AM, Robert Rogerson wrote:

A base package program program (CLLE) uses the RTVMSG command to decide which message file to use.

RTVMSG MSGID(&MSGID) MSGF(TFMMSG) MSG(&TXT)

IF COND(&TXT *EQ 'Text not available for message') THEN(DO)
SNDPGMMSG MSGID(&MSGID) MSGF(WFMMSG) +
MSGDTA(&MSGDTA) TOPGMQ(*SAME +
&SFPGMQ) KEYVAR(&MSGNO)
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSGID(&MSGID) MSGF(TFMMSG) +
MSGDTA(&MSGDTA) TOPGMQ(*SAME +
&SFPGMQ) KEYVAR(&MSGNO)
ENDDO

It works fine but I'm curious where &TXT is being populated with 'Text not available for message' after the RTVMSG, if not
found in message file TFMMSG.

I checked and RTVMSG doesn't mention this text is returned if the message is not found. It does mention CPF2419 is returned
so I checked the WRKRPYLE (Work with System Reply List Entries)
but this message was not found.

Is it just undocumented or did I miss something where RTVMSG does populate the MSG parameter if the message is not found?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.