|
I'm in the process of designing a multi-customer system on a single box
which will segregate data to separate libraries based on the customers'
unique settings. In other words, there is global functionality and data
that is common to all users, and there is customer specific data that
should not be accessible by other users. Rather than duplicate the
common functions to each unique customer library, I want to have a
common ground for the core of the program, and only differentiate
between customer specific data which will reside in a unique customer
library. Since the data file structures in question will be consistent
across the various libraries, I believe the programs will be indifferent
to the location of the physical and logical files in question. PLEASE
let me know if this is not the case, else the remainder of my query is
moot.
The overall plan is to establish library lists and environment variables
for each unique customer database via CL. Before you suggest it, I am
fully aware that this can be accomplished via DB2 SQL and pure ILE.
However, time is of the essence and many of our expert resources are
most comfortable with programming in an RPG/RPGLE environment, which
precludes the desire to define the environment without keyed file
structures.
I've reviewed the APIs for environment variables in CL which allow for
additions, changes and removals. All of the documentation that I've
come across states that querying the value of a specific environment
variable needs to be prototyped as an external call to either getenv()
or Qp0zGetEnv(). Is this really the case, or is there a CL method of
retrieving the value of a specific environment variable? Some of the
common methods in place will record the specific data library. I'd like
to know if this is possible without duplicating and supporting common
functionality across multiple libraries.
Thanks,
Tom Armbruster
As an Amazon Associate we earn from qualifying purchases.
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.