Trials and tribulations of QMHSNDPM (Was: No Subroutines...)

John, Bob, et.al,

>> And yes.. yes... I understand that QMHSNDPM can be wrapped in a
>> sub-procedure. I've done it and have one in my toolkit. But I don't use it
>> often because in most cases I want the message to contain the correct
>> originating procedure/module name. As soon as you wrap QMHSNDPM in a service
>> pgm subprocedure, you lose that information.


What's the problem with wrapping QMHSNDPM in a procedure which takes the name 
of the current procedure (and possibly a callstack level above it) as 
parameters, and using those to send the message.

The module and owning program/srvpgm name can be retrieved from the PSDS 
(assuming you've coded it in your module) and that's all you really need. If 
you haven't coded it in your module, here is an example of mine that Scott put 
in his newsletter in January:

http://code.midrange.com/index.php?id=9c259a573f

The only downside is that there is no easy way to retrieve the name of the 
current procedure from within a procedure. I tend to create a constant in each 
procedure (always called THISPROC) which contains the name of the current 
procedure. Anyone got a better way to retrieve the name of the current 
procedure ,aside from having a SUBROUTINE to call QMHSNDPM/QMHRCVPM to get it 
using one of the more esoteric formats)?

This is my SndPgmMsg() wrapper procedure for QMHSNDPM. Call it with e.g.:

Eval rc = sndpgmmsg( 'CPF9999' : THISPROC : 2 )

http://code.midrange.com/index.php?id=931ee5ee06


Rory