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



 
> Frankly, if you need to break your subprocedure up into 
> subroutines, it probably shouldn't have all been in the same 
> subprocedure in the first place. (Though, I'm guilty of this 
> -- I just don't advocate it!)



validateInput   b
                  pi            n

        if field1 = 'bad';
           msgData = "Field 1 must not be bad";
         exsr sndDiagMsg;
        endif;

        if field2 = 'bad';
           msgData = "Field 2 must not be bad";
         exsr sndDiagMsg;
        endif;

        (continue for each additional field)

      return (%len(msgData) = 0);

  begSr sndDiagMsg;
        QMHSNDPM( 'CPF9897'
               :'QCPFMSG    QSYS'
                   :msgData
               :%len(msgData)
               :'*DIAG'
               :'*'
               :1
               :msgKey
               :dsERR ); 

  endSr;
validateInput   e


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

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.

> The problem with that analogy is that hammers are much more 
> versatile (albeit slower) than nail guns.  A hammer can be 
> used for any size or type of nail. It can also be used for 
> pulling nails out. And shaping metal. 
> And breaking apart rusty fittings... the list goes on and on. 
>  A nail gun can only put it nails, it can't do any of the 
> other things that a hammer does.
> 
> That's not the case with subprocedures. Subprocedures are 
> MORE versatile than subroutines, not less. They're also 
> easier to maintain.

I won't quibble with you over my choice of an analogy. I'm sure you
recognize that my point is that there is room for both techniques.  


> Shrug.. I don't have strong feelings about subroutines and 
> subprocedures, but I do have strong feelings that RPG 
> programmers need to upgrade their skills, and that the fact 
> that people haven't changed their coding much since RPG III 
> is a major reason that the iSeries is declining.
> 
> Therefore, it makes sense to encourage people to use modern 
> techniques, and to try to push them out of their envelope and 
> get them learning.

I agree that it's good to encourage people to modernize their skills. By all
means they should understand subprocedures and make use of them wherever it
makes sense to do so. Just as they should understand subprocedures and (wait
for it..) make use of them wherever it makes sense to do so. :)


John Taylor


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