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