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
In general, nothing. That is, as long as one remembers to preset
BytesAvail, etc. etc. As was pointed out, IBM does use this approach on a
*per*parameter* basis.
Again, the OP didn't specify how the parameters are passed; didn't specify
anything about the format of them, didn't say that there's a length
attribute - none of that. He mentioned only that there were two parms
passed to every routine: one in and one out, and said this was because
(quoting now) "This idea was a work around to avoid changing modules when
one needed to add a parameter."
How that gets accomplished is not my call. But let's call it what it is.
This no better approach (and no worse, *if* *done* *right*) than the
optional parameter approach. So there's some ignorance at play here, I
think. (Note I did not say stupidity; it's an educational opportunity.)
Personally, I'd much rather be called upon to maintain a set of procedures
where the parameters are all properly named and properly identified in the
prototype, than a set of procedures where the parameters are DSIN and DSOUT
and I have to figure out what the layout differences, et cetera are. Give
me clarity. This is lost in the other approach.
Yes, yes, I know about externally described data structures, standard
definitions and all that. But it's another level of indirection in order to
find out what the actual parameters are.
There's also the topic of updated fields. Where are these passed? Input?
Output? Both? Is there a standard? If they're in both places, then at any
given time, which one is correct? Why should I need to know? What if we
want to share parts of input and parts of output with some other (sub-sub)
procedure? How much moving around of data will need to be done in order to
set up for the call? And THEN... where is the most recently updated data
now?
Come to think of it, how much movement of data will there be in order to set
up for ANY of these calls? And how much movement after? Gosh, it's
beginning to sound like a PLIST issue. Why do these sound like problems
from the previous century?
Oh, now I remember: because they were. And they were also solved in that
century.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"We lived for days on nothing but food and water."
-- W.C. Fields
midrange.com
