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



Simon,

thanks for your (as usual) in depth reply.  I now have a few avenues to
investigate.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Simon Coulter
Sent: Friday, February 25, 2005 3:46 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: QMHCHGEM API & Invocation pointer



On 26/02/2005, at 9:35 AM, Paul Jackson wrote:

> I am trying to use the QMHCHGEM (Change exception message) API as a 
> default
> handling program for a particular message ID.  Unfortunately the API
> requires an "invocation pointer".  The handling program is passed 
> program
> queue and message key information but not pointer.

This API is not designed for use from anything except C. C supports 
invocation pointers directly but you can often fake them with RPG 
pointers as long as you do nothing other than set them and pass them 
around.

The API should have allowed an invocation pointer OR the usual 
program/module/procedure method like most of the other MH APIs. I see 
QMHPRMM also expects an invocation pointer.

> I have been searching through the API's on the web with no luck and am
> wondering if there's a method I can use to retrieve the invocation 
> pointer
> for passing to the API.

You can pass a NULL pointer (which means your current invocation i.e., 
the invocation that calls QMHCHGEM) and use the call stack counter to 
determine the relative invocation.

If that's not suitable then the C interface to MI functions may help 
you.

_INVP(0) will return an invocation pointer to the caller's invocation. 
Perhaps your caller could use this and pass the invocation pointer to 
you?

fndrinvn() will search for a specified invocation. In your case you 
would probably want to get a system pointer to the program (using the 
program queue name and the rslvsp() function). This will return a 
relative invocation number which you could use on the call stack 
counter parameter of QMHCHGEM in conjunction with a NULL invocation 
pointer.

matinvs() will materialise the invocation stack in a variable (or 
space) that you could then search for matching program. You would need 
to materialise the program pointer in each invocation entry using 
matptr() and check if the object name matched the program name. When 
you found that you could use its invocation number and your own 
invocation number to derive a relative invocation value for use on the 
call stack counter parameter of QMHCHGEM.

There may be other methods too but these are the ones that occur too me.

> Any help would be appreciated.

The real question is why are you doing this? What are you trying to 
accomplish?

Regards,
Simon Coulter.
--------------------------------------------------------------------
    FlyByNight Software         AS/400 Technical Specialists

    http://www.flybynight.com.au/
    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
    Fax:   +61 3 9419 0175                                   \ /
                                                              X
                  ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------


-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.