- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- override system table in batch?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2009 07:39 AM
тАО12-14-2009 07:39 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2009 07:49 AM
тАО12-14-2009 07:49 AM
Re: override system table in batch?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2009 08:40 AM
тАО12-14-2009 08:40 AM
SolutionI 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2009 08:44 AM
тАО12-14-2009 08:44 AM
Re: override system table in batch?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 05:58 AM
тАО12-15-2009 05:58 AM
Re: override system table in batch?
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 06:29 AM
тАО12-15-2009 06:29 AM
Re: override system table in batch?
>>>
$ 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 08:04 AM
тАО12-15-2009 08:04 AM
Re: override system table in batch?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 08:36 AM
тАО12-15-2009 08:36 AM
Re: override system table in batch?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 11:32 AM
тАО12-15-2009 11:32 AM
Re: override system table in batch?
$ 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 01:19 PM
тАО12-15-2009 01:19 PM
Re: override system table in batch?
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