× 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.



Chris,

What you have to keep in mind is that when you send a message to program
message queue, it is up to the receiving program to do something (or not do
anything) with that message.  If you call a CL from the command line and the
CL sends a completion message that is shown on completion, it is the command
line program that is showing the message.  If your CL would call an RPG and
the RPG would send the completion message (with your settings), the
completion message would be received by the CL.  If the CL wouldn't do
anything with it, it would not show on the screen either.

Now, with ILE things get more complicated.  When you create an ILE RPG
program, the program consists of at least two procedures: the PEP (program
entry procedure), which is automatically added by the compiler (or is the
binder? don't really know) and the main procedure, your program.  When you
call this program from the command line, the PEP is called and the PEP calls
the main procedure.  So if you send a program message from your main
procedure (again, with your settings), it is sent one level up the call
stack, which happens to be the PEP.  I'm not quite sure what the PEP does
apart from passing on parameters, but it certainly does not concern itself
about showing anything on the screen; so your message does not show up.  You
could change the MsgQueueNbr parameter from 1 to 2 to bypass the PEP, but
then you will run into trouble again when you move the call to a sub
procedure.  That is why *PGMBDY is a useful option.

Joep Beckeringh


----- Original Message -----
From: "Chris Devous" <cdevous@antigua.com>
To: <rpg400-l@midrange.com>
Sent: Friday, February 22, 2002 6:22 PM
Subject: RE: QMSHNDPM API


>
>
> On 22 Feb 2002 at 11:42, Kevin Monahan wrote:
>
> > How is the BRKMSG parameter of your interactive job set?  If set to
*HOLD,
> > no message will be displayed to your screen.
> >
>
> Kevin,
>
> *NORMAL is the current setting.
>
> On 22 Feb 2002 at 16:37, Martin Rowe wrote:
>
> >
> > Do you have a message subfile on your screen to receive & display the
> > message? Other than that it looks okay. What level on the program stack
> > do you need it to be sent? to the invoking one, or one further back?
> >
>
> Martin,
>
> I don't have a message subfile.  Do I have to?  What I was
> trying to do was have my RPGLE program do what SNDPGMMSG does
> from a CL.  If I call a CL that contains the following
> command:
>
> SNDPGMMSG  MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(&MSGTXT)
>
> where &MSGTXT = "The message I want to send"
>
> Then the words "The message I want to send." appears at the
> bottom of my screen, when I call from a command line, or from
> a program displaying a *DSPF with a message subfile.
>
> SNDPGMMSG defaults it's stack entries as follows:
>
> Call stack entry message queue:  TOPGMQ
>   Relationship . . . . . . . . .                *PRV
>   Call stack entry identifier:
>   Call stack entry . . . . . . .                *
>
>
>
>   Module . . . . . . . . . . . .                *NONE
>   Bound program  . . . . . . . .                *NONE
> Send to non-pgm message queue  . TOMSGQ         *TOPGMQ
>
> I thought that using * for the call stack entry and 1 for the
> call stack counter would have the same impact as the
> *PRV/*/*NONE/*NONE entries for the TOPGMQ parameter of the
> SNDPGMMSG command.  These are the default entries.  I've tried
> * 0, * 1, * 2, etc. to no effect.
>
> Maybe this won't work?  If not, would I have any alternative
> API?
>
> --Chris





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.