|
midrange.com
Simon,
I agree that programmers have a responsibility to ensure that their programs
function properly,
but what is the advantage in forcing every programmer to know every API
interface intimately?
Productivity for programmers at all levels can be greatly enhanced when
black-box style reuse is
employed. I create a high level interface for any API that we are going to use
more than once. During
the process of creating the interface, I try to simplify the use of the API and
ensure that parameter
defaults are supplied where possible, parameter relationships are validated,
and meaningful diagnostic
messages are sent. There are many advantages to this, one advantage is that you
have a single point
of change when your use of an API changes. For the send message API other
potential advantages
include the ability to default the target queue, ignore PEP's when sending by
level, default the message
file based on message ID, and send multiple messages if logging is in effect.
David Morris
>>> shc@flybynight.com.au 07/18/00 06:13PM >>>
Hello Barbara,
I haven't yet made up my mind on this. I don't know any HLL that allows those
sorts of
related definitions. My view tends to be that since the API itself enforces
the
parameter requirements omitted parameters from a group will be caught during
Unit Test.
The purpose of the prototype is to ensure that IF a value is passed it is at
least of the
correct type and length. It is the programmer's responsibilty to ensure the
proper
parameters are actually passed. Although it's a good idea, perhaps what we
need is a
Parameter Group tag so we could code:
/if defined(LONG_PROC_NAMES)
QmhSndPgmMsg PR
/else
QMHSNDPM PR
/endif
EXTPGM('QMHSNDPM')
D reqGroup PG
msgId 7 CONST
qualMsgF 20 CONST
msgDta 32767 CONST OPTIONS(*VARSIZE)
msgDtaLen 10I 0 CONST
msgType 10 CONST
D callStkEnt 4102 CONST
D callStkCnt 10I 0 CONST
D msgKey 4
D errCode 1024 OPTIONS(*VARSIZE)
D optGroup1 PG OPTIONS(*NOPASS)
D callStkEntLen 10I 0 CONST
D callStkEntQual...
D 20 CONST
D dspPgmMsgTime 10I 0 CONST
D optGroup12 PG OPTIONS(*NOPASS)
D callStkEntType...
D 10 CONST
D msgDtaCCSID 10I 0 CONST
What say you all?
Regards,
Simon Coulter.
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software AS/400 Technical Specialists «»
«» Eclipse the competition - run your business on an IBM AS/400. «»
«» «»
«» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «»
«» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «»
«» «»
«» Windoze should not be open at Warp speed. «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
//--- forwarded letter -------------------------------------------------------
> Date: Tue, 18 Jul 2000 14:07:34 -0400
> From: bmorris@ca.ibm.com
> To: RPG400-L@midrange.com
> Reply-To: RPG400-L@midrange.com
> Subject: How to prototype CL modules
>
> > ...
> >Here is my prototype for the same function. I'd be interested in comments
> and
> >criticism:
> > ...
>
> Simon, since RPG doesn't allow you to group optional parameters (you can't
> code anything to indicate "if parm 10 is coded, parm 11 must be coded
> too"), then for APIs that have this type of optional parameter, I think you
> should create more than one prototype:
>
> D QMHSNDPM PR EXTPGM('QMHSNDPM')
> D msgid 7 CONST
> ... more basic parms
> D errCode 1024 OPTIONS(*VARSIZE)
>
> D QMHSNDPM_opt1 PR EXTPGM('QMHSNDPM')
> D msgid 7 CONST
> ... more basic parms
> D errCode 1024 OPTIONS(*VARSIZE)
> * optional parms group 2 begin here
> D callStkEntLen 10I 0 CONST
> D callStkEntQual...
> D 20 CONST
> D dspPgmMsgTime 10I 0 CONST
>
> D QMHSNDPM_opt2 PR EXTPGM('QMHSNDPM')
> D msgid 7 CONST
> ... more basic parms
> D errCode 1024 OPTIONS(*VARSIZE)
> * optional parms group 1 begin here
> D callStkEntLen 10I 0 CONST
> D callStkEntQual...
> D 20 CONST
> D dspPgmMsgTime 10I 0 CONST
> * optional parms group 2 begin here
> D callStkEntType...
> D 10 CONST
> D msgDtaCCSID 10I 0 CONST
>
> Barbara Morris
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
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.
