|
midrange.com
>> 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.
Look at XVERRH in my Trigger Mediator. I use the ERRH_Throw to throw an error
and use message definitions with second level help with all the details. The
error is thrown, and the next level up either catches it or it lets it end with
the message containing all the details. Clean and easy. Don't have to mess with
coding error routines and next level needs to know a lot more about an error
than just the procedure name. We have the best examples in the world when
looking at IBM messages. Most of the time clear and concise with all the
information they can pack in about the problem.
So, why reinvent the wheel every time? I hate writing code more than once and
the worst thing about Microsoft environments is the "error 24 occurred" crap.
IBM gives us the best error handling system in the world. Why not use it?
d Msg_UXV0024...
d ds Qualified
d ReasonCode...
d 3p 0
d ActualState...
d 5p 0
d ActualColumn...
d 5p 0
d RecordState...
d 5p 0
d RecordColumn...
d 5p 0
// Error check to determine that the state transition record
// state and column matches to current state and column.
If StateTransitionRecord.State <> State or
StateTransitionRecord.Column <> Column;
Msg_UXV0024.ReasonCode = 1;
Msg_UXV0024.ActualState = State;
Msg_UXV0024.ActualColumn = Column;
Msg_UXV0024.RecordState = StateTransitionRecord.State;
Msg_UXV0024.RecordColumn = StateTransitionRecord.Column;
ERRH_Throw('UXV0024' :
cXVMessageFileName:
Msg_UXV0024 );
EndIf;
Message ID . . . . . . . . . : UXV0024
Message file . . . . . . . . : XVMSGF
Library . . . . . . . . . : MP1CAMPIA
Message . . . . : UXV0024-Function PARS_ParseString failed for reason code
&1.
Routine in service program XVPARS, module XVPARS_M01 failed. Reason codes as
follows:
1-Wrong state record retrieved! Should be state &2, column &3 but record
retrieved was state &4, column &5. Contact support for program XVPARS.
-----Original Message-----
From: John Taylor [mailto:lists@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, July 27, 2005 11:43 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: dRE: No Subroutines (was Re: Debugging many subprocedures)
> 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 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.
