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



Mark:

> I've been trying to write a service program that wraps the 
> QMHSNDPM and QMHRMVPM API's. I've copied the code from the 
> Doug Pence/Ron Hawkins article from MC Press Online from a 
> few years ago. No luck. It's like the subfile is never being 
> cleared. When I look at the job log, I get a Call Stack Entry 
> Not Found error. Here is the send code.


1) When you say the Subfile is not being cleared, that indicates that
you have a display file issue. Your code sample showed a write to the
"msgctl" record, but didn't show you setting any indicators beforehand.
The SFL control record should have keyword SFLINZ specified with a
control indicator. The control indicator should be set on just before
loading new messages, then set off right after. Or did you actually mean
that the message queue is not being cleared?

2) You didn't say where the "Call Stack Entry Not Found" error was being
generated, "snderrmsg", or "rmverrmsg". Since snderrmsg() always sends
to the calling procedure, I'm going to assume that it's rmverrmsg()
which is hitting a bad call stack. You'd need to show us that code in
order to say for certain what is happening.


3) Note that snderrmsg() doesn't actually work the way I believe you
intended it to. Based upon the following:

>      Dproc1            PI
>       /free
>         sndErrMsg('CPF9898':'Message from Proc 1');
>       /end-free
>      P                 e

it appears that you are trying to send a message from Proc1 to the
mainline. However, what is actually happening is that Proc1 is the
TARGET of the message, and snderrmsg() is the source. 
Your API call:

>      C                   call      'QMHSNDPM'
>      c                   parm                    msgId
>      c                   parm                    msgFIleLib
>      C                   parm                    msgdata
>      c                   parm                    msgdatalen
>      c                   parm                    msgtype
>      c                   parm      '*'           msgPgmQ
>      c                   parm      1             msgQueNbr
>      c                   parm                    msgKey
>      C                   parm                    errords


is sending a message to the prior call-stack entry, but remember that
snderrmsg() itself is considered the current call stack entry from the
perspective of the API. In other words, snderrmsg(), as currently
implemented, can only be used to send a message to the calling procedure
itself.

I started writing a service program for message handling back in 1997,
on V3R2. I finished about half a dozen procedures before ultimately
abandoning the project in favour of using the API's directly. The reason
I gave up on the wrappers is because using a procedure like snderrmsg()
meant that my messages would always show SNDERRMSG as the sending
procedure. That proved frustrating because what I actually wanted to
know was who called snderrmsg().

In any event, I still have the service program, and you're welcome to
take a look at it if you think it will help you.

Regards,

John Taylor



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.