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



I love the tone of your voice. Please go on. Did you notice that I
said, "we are obliged".
Feel free to shoot down this idea!
I don't have an answer to the OQ, but couldn't resist responding to
this approach. You know the risks and inflexibility that are
associated with this (flawed) attempt to be maintenance free, right?
You know what happens when you decide to make one of the DS larger,
right?

You want me to go on? :) Well, it's a fallacy to think that this will
protect from future changes due to expansion. It's a train wreck waiting to
happen. I'm sure that, in such an effort, some key person has reserved
x-bytes of space to allow for expansion and yada yada. But what happens
when that space is not enough? (Hold that thought.)

The whole purpose behind optional parameters ( OPTIONS(*NOPASS) ) is to
allow for this sort of thing without breaking existing routines. Today,
some routine is called with four parameters, and some return value is
passed. Tomorrow a new twist is needed, so we add a fifth parameter
(optional), and use that in our new routine that needs the function. The
other stuff remains the same. Later (if we decide to) we compile one of the
old procedures, and guess what? It still works with the original (and only)
four parameters. What is this approach really buying you?

Let's look at the other side. Someone has (hopefully) set aside x bytes of
space that can be used in the future. Who decided this amount is enough?
Probably the same person who cannot see into the future far enough to decide
how many parameters will really be needed. And when that's not enough...
when the DS needs to be extended to accommodate the extra values that will
be passed... ALL of the routines will need to be recompiled. And if one is
missed, then there will be a surprise waiting when that program calls the
modified routine. If the input parameter is too small, the called procedure
will be working with garbage at the end of its DS. If the output parameter
is too small, the procedure will either step on data in the caller
(silently.... very nice!) or some "outside of its space" error message will
result. And due to the nature of the ("we didn't know to compile that
program" issue), this will happen in Production, potentially corrupting
Production data. Very cool, if your specialty is cleanup!

The whole approach smacks of misguidance due to misunderstanding.

Don't accuse me of being biased; I'm not. What I am, is experienced.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I knew I was an unwanted baby when I saw that my bath toys were a toaster
and a radio."
-- Joan Rivers




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