RE: QMHSNDPM in serviceprogram

Joep,

I would assume that the two methods in question would produce the same outcome, given the scenario that you describe. The call stack entry 1 call level previous to the *PGMBDY of the ABC program identified by the invocation pointer would be the caller of the ABC program, not the PEP of program ABC.

In essence, I think that the two approaches are functionally almost identical, it is primarily a question of whether you obtain an invocation pointer from the _INVP builtin or a program name from the PSDS. - In turn, and to the QMHSNDPM API, both will point to the same call level - unless program ABC allows recursive calling. In that case the invocation pointer would still be unique, whereas the program name might not.

Cheers,
Carsten

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of j.beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx
Sent: 16. oktober 2014 16:13
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: QMHSNDPM in serviceprogram

Carsten,

If I understand correctly:
- Program ABC calls _INVP to obtain its own invocation pointer
- Program ABC calls a routine in a service program, passing its own invocation pointer as a parameter
- The routine then calls QMHSNDPM, passing the invocation pointer as the call stack entry and *PGMBDY as call stack entry qualification

Earlier I described another method:
- Program ABC calls a routine in a service program, passing its own name (from the PSDS) as a parameter
- The routine then calls QMHSNDPM, passing the name as call stack entry

The difference seems to be that your method will send the messages to (program entry procedure) _QRNP_PEP_ABC, while my method will send it to (main procedure) ABC. What would be the advantage of your method over my method?

This communication is intended only for use by the addressee.It may contain confidential or privilegedinformation.
If you receive this communication unintentionally, please inform us immediately and delete this e-mail and any attachments.
Warning: Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept
responsibility for any loss or damage arising from the use of this email or attachments.