We have a different approach (which is indeed a lot of work at first, but
very flexible).
We have a service program, that includes for each constant a function, which
returns the constant value.
In this way we do not care about from which language it is called and we do
not care how we determine the constant value, i.e. if tomorrow someone
decides to put all of our constant values in a table.
We only have to change it in a single place.
And if someone decides tomorrow a "constant" value needs to be changed (my
manager sometimes has those ideas!), no problem either, we change it in a
single place.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John
Yeung
Sent: Samstag, 10. Juni 2017 00:27
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Get a definition for a constant in a source member into a CL
program
On Fri, Jun 9, 2017 at 3:38 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
Alternatively (and probably better) create a small DB2 table that holds
all constant definitions and actually attach a trigger that regent both RPG
and CL (and even COBOL!) on any update.
As cool as Denis's polyglot solution is, I would go this route. If these
really are supposed to be systemwide constants, then the system's database
is the most sensible place for them to be. (There are plenty of production
systems out there that actually store their constants in a table, and any
programs that use them just read them straight from there at init time! No
/copy or /include at all for that
purpose!) And manually maintaining two lines of code for every constant (or
more, if you have more languages to support) doesn't feel quite right.
John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.