Re: EXTPROC(*CL) and V6R1

I'd note that separate length and/or format parameters might be a
little less error prone...

But there's no reason that the DS format Rory describes couldn't work.

Could a developer screw it up? Sure. But you could make it pretty
easy to do right.
d t_InputFmt1 ds TEMPLATE
d 10i 0 inz(%size(t_inputFmt1))
d errorcode 10i 0
d 8a inz('FMT0100')
d Fmt1Fld1 10a

d t_InputFmt2 ds TEMPLATE
d 10i 0 inz(%size(t_inputFmt2))
d errorcode 10i 0
d 8a inz('FMT0200')
d Fmt2Fld1 10i 0

Charles

On Fri, Dec 18, 2009 at 12:44 PM, Rory Hewitt <roryhewitt@xxxxxxxxx> wrote:

Dennis,

Given that the OP says that their functions are all called with 2 DS
parameters, what's the problem with having both of those parameters include
formatting information in them (as the first few fields)?

In other words, all data structures being passed around would include
something like the following:

D ParmDS             DS
D   BytesAvail                       10I 0
D   ErrorCode                        10I 0
D   ParmFormat                      8A
...
other DS fields go here

Every procedure which receives a DS parameter checks the first few bytes to
see what format the information is being passed in and how big the DS is.
The 'length-of-DS' doesn't need to be a separate parameter.

Rory


On Fri, Dec 18, 2009 at 9:25 AM, Dennis Lovelady <iseries@xxxxxxxxxxxx>wrote:

While I don't recommend this approach, it isn't the end of the world
you make it out to be.  You need to remember that you're passing by
reference, meaning it doesn't matter how big the DS is the only thing
passed in and out of the procedure is a 16 byte pointer.

Charles, Charles, Charles.  I'm so surprised to hear you say that!

You're saying that, because only a 16-byte pointer is passed to my
routine, the actual size of the DS doesn't really matter?  So that if
the routine is expecting, say, 100 bytes in but only 80 are provided by
the caller, then that's OK?

Or, if the called routine will pass back 100 bytes but the program has
allocated 80 for the effort -- then that's OK too?

These are not problems that can be circumvented by planning, design,
and use of features?  Remember: "the problem with making anything
foolproof is that fools are so ingenious."  This design opens the door
to that ingenuity.

Dang it, I sent too soon.  (I guess I pressed CTRL+ENTER but I sure didn't
mean too.  Anyway...)  I understand what you're saying about the "number of
bytes to return" parameter.  First off, I saw nothing about that in the OP,
so I won't assume that it's there.  Secondly, IBM does that to ONE of its
parameters (generally speaking, except that there are some "control-block"
based APIs), not as an effort to future-proof against the addition of
alternate parameters.

This too is something IBM does quite often. In the early days, some of the
APIs didn't use an Error Structure return.  Now that's been added as an
optional parameter.  There are many, many examples of IBM's (proper) use of
this function.

Format of output is entirely a different thing, and I align with you on
that
thinking.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"People are usually more convinced by reasons they discovered themselves
than by those found by others."
       -- Blaise Pascal

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.