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

[John Gillings]

Roger,

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

be careful when redefining LNM$FILE_DEV. You can't assume the list will be static. A fixed DEFINE command like the above can break other software.

To do this properly, you should first find the existing definition, which may be in LNM$PROCESS_DIRECTORY or LNM$SYSTEM_DIRECTORY. Use F$TRNLNM to find all translations, then construct a new list with your table inserted into the appropriate slot. In general I'd tend to put an application table somewhere after LNM$GROUP, possibly after LNM$SYSTEM. Simpliest logic is to put your table on the end of the list. Remember there may be other application tables. For example:

$ show log/table=lnm$system_directory lnm$file_dev
"LNM$FILE_DEV" = "LNM$PROCESS" (LNM$SYSTEM_DIRECTORY)
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"
= "DECW$LOGICAL_NAMES"
= "CONSOLE$LOGICAL_NAMES"
1 "LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY)
= "LNM$SYSCLUSTER"
2 "LNM$SYSCLUSTER" = "LNM$SYSCLUSTER_TABLE" (LNM$SYSTEM_DIRECTORY)
1 "DECW$LOGICAL_NAMES" [table] = "" (LNM$SYSTEM_DIRECTORY)
1 "CONSOLE$LOGICAL_NAMES" [table] = "" (LNM$SYSTEM_DIRECTORY)


(years ago I proposed /APPEND, /PREFIX, /AFTER and /BEFORE qualifiers for the DEFINE command to simplify modifications to search lists. Oh well :-(

[Robert Gezelter]

John,

One can find the current definition of LNM$FILE_DEV using the LNM$DIRECTORIES, the search list of LNM$PROCESS_DIRECTORY and LNM$SYSTEM_DIRECTORY.

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

[Roger32909]

Thanks for all your comments. The table in one of the other DEV environments is between the group and system and works fine. When we tested in a different environment, TEST, with the table in the preferred sequence between the group and system, the test failed. I cannot be certain it was the sequence. Time constraints prevent further testing, so we will stick with what works.
I should mention that this is a dedicated machine for only one application, all custom software. I, and the other members of the development team, control what goes into the table and also what goes into the login.coms, i.e. what is set at process or job level. we don't use group level. The only thing we do not control is the system table which the sysmgr insists on keeping for some unknown reason.
The production machine will be a dedicated machine with only one environment, so that should not be a problem. It's only this test machine with 3 environments, and now that's no longer a problem either, thanks to y'all.

[Roger32909]

You gurus will be happy to know that because another problem arose regarding logicals, I was given some more time to examine the setup for multiple environments and test the solution.

we now have 6 environments and all appear to be working OK (finally). The development
area uses the system table supplemented by logiCals set at job or process level.
The other 5 environments use a special table level to look first in the table before system:

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

I believe this is the order y'all recommended.
The table settings are also supplemented by logicals set at job or process level.
Thanks again to all for your help.

[Roger32909]

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