Hi, Jeff:
I have been following this thread with some interest ....
When you use a "symbolic name" for these "constants" in your programs
(instead of hard-coding the literal values directly in your source
code), whether those symbolic constants are defined in a "copy book" or
"include file" or by some other means, you are still, in effect,
"hard-coding" these constant literal values (that have been assigned
some kind of "meaning" by someone), at compile-time. And, if you ever
change them, you must then recompile every program that uses them.
And, if those values are stored in some database columns, in rows or
records of one or more tables (or files), then you also need to do a
(potentially massive) SQL UPDATE ... WHERE ... to change every instance
of a given "hard-coded" value to the new value.
So, I think Birgitta is "on the right track" here with her
suggestion to somehow "encapsulate" this knowledge into some kind of a
function, probably in a *SRVPGM ... and perhaps define that function as
an SQL UDF so it can be used directly within SQL statements.
Perhaps also an SQL UDTF could be defined, so that you can "join"
using the "symbolic" value name, rather than its encoded value?
The"big idea" here seems to be that you should strive to have one (and
only one) authoritative version of "the truth" ... and so this kind of
stuff probably belongs "in the database" ...
Donald Knuth, in a now-famous paper, "Structured Programming With GoTo
Statements" (Computing Surveys, Vol. 6, No. 4, 1974) wrote:
"Programmers waste enormous amounts of time thinking about, or
worrying about, the speed of noncritical parts of their programs,
and these attempts at efficiency actually have a strong negative
impact when debugging and maintenance are considered. We should
forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil. Yet we should not
pass up our opportunities in that critical 3%."
The key phrase here, (and so, my "quote of the day") is, "Premature
optimization is the root of all evil." Hard-coding such symbolic values
in programs is just another form of "premature optimization." (It's a
"Pay now, or pay later" kind of thing...)
Just saying ...
All the best,
Mark S. Waterbury
> On 6/10/2017 10:53 AM, Jeff Crosby wrote:
On Sat, Jun 10, 2017 at 10:51 AM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx>
wrote:
And if someone decides tomorrow a "constant" value needs to be changed (
Oh the irony. :)
midrange.com
