override system table in batch?

[Roger32909]

The problem is to simulate two different environments on one machine. The development environment works fine and a system table contains all logicals needed.
We are using CA Scheduler for all batch jobs.
The test environment works fine in interactive mode, but when we submit batch, scheduler jobs use the development environment database instead of the test database. Is there a way to override the system table in batch mode so that the logicals point to the test database when we use the test environment?

[Hoff]

Do your due diligence, and figure out what the difference is.

As a start, get the test environment (whatever that is in your environment) out of the system table.

Possibly migrate it to the group table or to a locally-created shared table?

Probably also move the production logical name definition "stuff" out of the system table, too, given a shared locally-created table can allow you to run two or more versions of production in parallel. Which can have its advantages.

Messing with the system logical name table would not be the path I would choose here. You have good tools and capabilities available to you by better isolating your production and testing logical names and name tables, and given the posited system logical name table override approach suggested here stinks very severely of unstable hackery.

[Robert Gezelter · Accepted solution]

Roger,

I concur with Hoff on many points.

In general, I recommend that things be kept out of the system logical name table.

What I prefer to do is create one of more logical name tables for the applications, and drive the difference between production, test, development and others by using a single rooted logical that all of the names depend on.

I then place the applications logical name tables in the logical name search sequence using LNM$FILE_DEV.

This approach accomplishes minimizing the differences between test and production environments.

This was the one of the bases of my 2004 OpenVMS Technical Journal paper "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters ", reprint available at: http://www.rlgsc.com/publications/vmstechjournal/inheritance.html

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Roger,

to begin: WELCOME to the VMS forum!

Your question: I could not agree more with Hoff!

Set up EACH and any environment (as many as you need) in its own (application-) Logical Name Table. (check HELP create/name & define/table= )
Then at login (here, the choice would depend on the process's MODE) add the relevant table to your LNM search list.
VERY versatile, and VERY robust.
And, as long as no environment is chosen, the proces knows of NO environment, meaning it can not accidentially connect to the wrong one.

hth.

Proost.

Have one on me.

jpe

[Roger32909]

I prefer the suggestion to get rid of the system table. The decision makers want 3 different environments on the same machine, so why give preference to development with dev logicals in a system table?
So far, the sysmgr has declined to try this suggestion.
As for the table, a table was made and this was put into the user's login.com:
$ DEFINE/job/table=lnm$process_directory lnm$file_dev lnm$process, lnm$job, lnm$TEST_table, lnm$group, lnm$system.
Does this seem to be correct?
It did not seem to make a difference. We don't know yet what define or setting we are missing.
Also, is a table required? If there were no system table, could not the different environments pick up their respective logicals say at the JOB level (or even GROUP or PROCESS level)?

[Jan van den Ende]

Roger,

>>>
$ DEFINE/job/table=lnm$process_directory lnm$file_dev lnm$process, lnm$job, lnm$TEST_table, lnm$group, lnm$system.
<<<
Seems almost OK.
Leave out the "/job" -- I am not sure if that, or the /table=.. takes preference, but they seem to conflict.

And, indeed, you need to create the lnm_TEST_TABLE ( please do NOT use any "$" sign in things not coming from Engineering -- that is "Reserved for use by Digital since VMS V1.0; and it might come into conflict with some future addition to VMS )

Create similar name-tables for DEVELOP ; PRODUCTION ; and whatever.
Do that during bootstrap, and DEFINE the relevant logicals to the relevant tables then.
Make sure those authorized can use them(read, and for applic mgt write ).
ACLs combined with Rights Identifiers are perfect for that.

And any time an environment is needed, do the relevant DEFINE for LNM$FILE_DEV.
If suitable, (some) users can switch environment that way, Just give a command symbol for the DEFINE (or hide that within a menu)

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

Roger,

First, I can assure you that the approach of three environments on one machine does work, having done it on quite a few occasions.

/JOB and /TABLE= are contradictory. /JOB equals /TABLE=LNM$JOB (LNM$JOB translates to a different logical name table for each job in the system). For a start, remove the /JOB qualifier from the DEFINE command.

It is always difficult to debug these from a distance, but the simplest approach that I can quickly construct would be to create a logical name IDENTITY in each of three logical name tables: APPLICATION_DEVELOPMENT, APPLICATION_TEST, and APPLICATION_PRODUCTION. The value should be different in each case. For example: DEVELOPMENT, TEST, and PRODUCTION respectively.

Then, redefining LNM$FILE_DEV in table LNM$PROCESS_DIRECTORY should work correctly.

For testing, explicitly enumerating the extant logical name tables is acceptable. However, I strongly discourage it as an actual practice.

In the real code that people will actually use, iterate down the existent translation of LNM$FILE_DEV, building a string until LNM$SYSTEM is encountered. A that point, insert your new logical name table, then LNM$SYSTEM.

A certain third party product has done this incorrectly for a long time, resulting in a variety of problems, including difficulties with DECwindows support (DECwindows also modifies the search list).

The best rule is to insert into the existing search sequence, not to presume that the search list is an expected value.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Roger,

the problem Bob cites can really be ugly.

We circumvent it by redefining LNM$FILE_DEV only ONCE during bootstrap, by inserting an extra LNM_APPLICATION.
(do this in LNM$SYSTEM_DIRECTORY, NOT in LNM$PROCESS_DIRECTORY)

Then, for environment selection, DEFINE LNM_APPLICATION as LNM_whateveryouneednow in LNM$PROCESS_DIRECTORY.
Yes, it _IS_ one extra step, but it puts all the cmplexity Bob named into that extra (bootstrap) step, keeping the frequent per-user-per-environment action much simpler.

hth

Proost.

Have one on me.

jpe

[Roger32909]

I changed the define in my login.com as follows:

$ DEFINE/table=lnm$process_directory lnm$file_dev lnm$TEST_table, lnm$process, lnm$job, lnm$group, lnm$system

and Scheduler found the TEST database as desired.

I know the sequence is slightly different, but hey, it worked, and I have other problems to work on.

Thanks to all for your suggestions.

[Robert Gezelter]

Roger,

With all due respect, please reconsider the sequence of the name tables in your definition of LNM$FILE_DEV.

The application table at the front overrides all other tables. This can cause many problems since it means that the definitions cannot be overridden at the job, process, or group levels.

As noted in my 2004 paper, the safest place in the sequence is between the group and system logical name tables. Then it is possible to override the general definitions in the same way that the process, job, and group logical name tables override those values in the system logical name table.

- Bob Gezelter, http://www.rlgsc.com