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

Rory,

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

That doesn't address the issue. QMHSNDPM always reports the procedure which
called it as the message originator ("From Procedure" item on the message
details display). The call stack entry/counter are used to determine the
message target, not the source. Check it out for yourself; no matter how you
call your sndPgmMsg() procedure, the resulting message will ALWAYS say that
it originated in procedure sndPgmMsg() because, well, it did.

 
> 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)?

There is a bigger downside yet. This technique will result in the call to
QMHSNDPM failing if it is called after the program has been recompiled while
in use. When that happens, the module and program name in the PSDS will no
longer be accurate. The actual call stack entry now belongs to a program
named something like "Q1348573" in QRPLOBJ.

All in all, this is not something which I've ever lost sleep over. When I
need to have the originating procedure represented correctly in the message
details, I simply call QMHSNDPM directly and it's done. 

The original discussion was about whether or not subroutines had a place in
modern day RPG. I simply used QMHSNDPM to illustrate a single example to
support my position that, yes, subroutines can still be useful.

Regards,

John Taylor