How can I create a DTAQ in one of two different li

2019-08-02 19:26发布

问题:

On our as/400 we have a test environment and a productive environment. Once we tested our programs are working, we can put them in the productive environment. Both environments contain a similiar set of libraries.

The basic mechanism to tell our programs, in which environment they work, are liblists used for the jobs they run in. That works great, for some things, but for others it doesn't. Therefore we often have a parameter passed to the programs on job submission, that tells the program to work in either test or productive environment. That annoys the hell out of me, since my programs always have to carry this parameter throughout their whole execution time, and often even pass it on to other programs. Sometimes the initial program does not even need the information itself, but still has to take it as a parameter, because it calls a program that does need it.

To present the specific problem I am faced with: Communication between individual parts of a bigger process is often done via dataqueues throughout our sytem. Reading a specific DTAQ according to the liblist works like a charm, simply call RCVDTAQ on the DTAQ's name, the liblist takes care of choosing the right lib. Same goes for writing into DTAQs.

But sometimes the program has to create a new DTAQ before listening or writing to it. Now that does not work with our layout and the liblists. Think of it like this:

PROD-liblist:

PPGMLIB1
PPGMLIB2
PDFILELIB1
PDTAQLIB1
P...
...

TEST-liblist

TPGMLIB1
TPGMLIB2
TDFILELIB1
TDTAQLIB1
T...
...

Now my program should create the DTAQ in ?DTAQLIB1, where ? should be either P or T.

My first idea would be to go through the liblist and look for the entries PDTAQLIB or TDTAQLIB, and take whichever comes first -- but than I couldn't figure out how to to that (hence my connected question: How can I read the liblist from within an ILE-Program? (preferably RPG or CL)).

I know I could possibly achieve my goal by checking, which user owns the current job, but that would break our logic of selecting the libs by liblists (like our current workaround does).

Is there anything I'm missing? Some special way to to call CRTDTAQ maybe, or some special api to do this liblist comparison, that I'm trying to write?

回答1:

Warren's configuration file idea is a good one, but sounds like it would be a lot more than you need. How about just using a data area?

For example, ensure there is always a data area called MODE in your ?DFILELIB1 library. It would have just a single character, "P" or "T", for the mode.

Or even simpler (though perhaps less clear): you could test for the presence or absence of a TESTMODE data area, and proceed accordingly.



回答2:

To read the library list in CL, use RTVJOBA. To read it in ILE RPG, I'd suggest the QUSRJOBI API, format JOBI0700. http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Fapis%2Fqusrjobi.htm
I think your idea of scanning the library list is probably the best one for your environment.



回答3:

I generally try to avoid hard-coding library names anywhere in my programs. If you are scanning for specific names or name patterns, this may work fine for now, but what happens down the line when new environments are created, perhaps with a new naming scheme. Therefore I would store environmental setup as configuration data.

I have two approaches for this.

You can set up a general configuration values table, which can be used by all sorts of programs to look up all sorts of configuration values. In our shop, we call this our Generic Values file. It has to main key fields, the first is often used for a program name, and the second for the name of the value being configured. We also frequently put a table name as the first key, and a column name as the second, each record defining a valid value for the column and a description of it.

Where I am implementing SOA services with Data Queues, I have a table specifically to define information about the service. This includes information such as library and data queue names, as well as other information used by the client interface, by the job performing the service, or by the job managing my servicing jobs.

In either case, configuration files are in the environment-specific data libraries, with values appropriate for that particular environment. I have commented SQL script members that contain the INSERTS for all the configuration records, so that a source scan can easily find library or object name references. I recommend segregating environment specific configuration from other application configuration data that will be tested and moved over to production.