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




In my opinion, that is a lot cleaner than including the call to QMHSNDPM
with all of its parms for each field test.

Definitely.


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.

Okay, but in this case a subprocedure call would've been better if it weren't for a flaw in that particular API that prevents you from specifying where the message is coming from.

For example, the following code would've been better:

     if field1 = 'bad';
        diag('Field 1 must not be bad');
     endif;

     if field2 = 'bad';
        diag('Field 2 must not be bad');
     endif;

The only reason you can't use it is because there's no way to tell that API that diag() is a wrapper procedure and that the "real" originator is the proc before it. So you use a subroutine purely because it doesn't create a different call stack level.

There's another situation where subroutines make sense as well... the situation of wanting to have a *PSSR that catches any errors in a subproc.

But other than those two situations, I can't envision why you'd ever want to use a subroutine in RPG.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.