Re: Get a definition for a constant in a source member into a CL program

Birgitta

Seems the SQL global variables could work for something like this - they ARE variables and can be changed, of course, simply by using the SET SQL statement - maybe could be done using RUNSQL, their last value persists even through IPLs.

For others,, one merely uses the CREATE GLOBAL VARIABLE statement - this in some ways feels like what you describe here, since these are implemented as service programs, as I recall.

HTH
Vern

On 6/10/2017 9:51 AM, Birgitta Hauser wrote:

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