- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- OpenVMS TCPIP unattended configuration
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-26-2003 02:51 AM
тАО12-26-2003 02:51 AM
OpenVMS TCPIP unattended configuration
For an OpenVMS upgrade to OVMS V7.-2 with TCPIP V5.4 of approx. 180 OpenVMS AlphaServers I would like to automate (via DCL scripts) as much tasks as I could.
How to do a TCPIP configuration without using the menu?
Who can help me? Which commands to use.
Assume the new created system disk is a "virgin". So no TCPIP*.DAT files exists.
I am interested in how to create the DAT files or will these auto created when issueing the first configuration command such:
TCPIP SET CONFIGURATION INTERFACE WE0 /NETWORK_MASK=255.255.0.0.
The TCPIP docu does not explicit refering to an unattended installation option and how to do it.
Your feedback is very much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-26-2003 02:54 AM
тАО12-26-2003 02:54 AM
Re: OpenVMS TCPIP unattended configuration
Sorry for the confusion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-26-2003 04:19 AM
тАО12-26-2003 04:19 AM
Re: OpenVMS TCPIP unattended configuration
Assuming the 180 systems are setup to be similar (or at least there are big subsets that are similar), I would configure one master system fully, then clone the disk (e.g. shadow copy, SA backup).
With this disk boot the other systems, change system names/network addresses and off you go.
Another way to share much of the configuration is obviously a cluster with shared files ;-)
Greetings, Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-26-2003 08:23 AM
тАО12-26-2003 08:23 AM
Re: OpenVMS TCPIP unattended configuration
You have to type in the information at some point, and we have decided that doing it interactively when we create the OS root takes less time than trying to make scripts to do it automatically.
If this is a new system that does not have an active TCPIP interface, and you only have console access to the disk, you are not going to be able to copy/FTP your script there anyways! You could possibly Copy/Paste from one windows session into another session.
Pro - You think that it takes less time???
CON - If you are not watching, you will never catch any problems!
We also clone new roots. I have a DS20 dedicated to this that is called CLONE1. This see's all of the HSG's that I might want to clone an OS pack too. So while I have file cabinets full of licenses, we use the same licenses on almost all of our systems.
After a BACKUP/IMAGE of the OS pack. I have about an hours work (Including re-boots) to set the Node Name, Decnet Parameters, IP parameters, Timezone... Etc.
When you change the node name, it whipes out the IP configuration. Running through @TCPIP$CONFIG will allow you to setup the TCPIP parameters fairly easily. This may be the command script that you are looking for.
What I do (Condensed)
Edit Modparams.dat (Change node and decnet)
Set cluster parameters. (SYSMAN)
Autogen re-boot.
@net$configure
@utc$time_setup
mcr decnet_register
@tcpip$config
Re-boot.
(IF network is connected)
Setup mail.
Setup NTP.
Overall, about an hours work per root. 4-node cluster = 4 hours.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-27-2003 07:42 AM
тАО12-27-2003 07:42 AM
Re: OpenVMS TCPIP unattended configuration
Hello Mike,
Thanks a lot for your feedback.
Yes, cloning of the system disk we have in mind by using a prepared master disk.
But the mentioned 180 servers are distributed in several countries within Europe. For sure these systems are productive. On the D-Day we have only a very limited maintenance window and therefore, additional we will switch from DECnet Phase 4 to DECnet Plus.
We would like to gather the current network settings and transfer these over to the new system disk.
Yesterday I found out there is a "semi" silient installation mode for TCPIP.
By providing two parameters, P1 & P2, when calling TCPIP$CONFIGURE.COM => "SERVER" "ENABLE". This surpresses the sometimes nasty menu and the interactive answering are really reduced. I used the word "semi" because there are still some
interactive questions issued be the procedure.
But the DB files are created! The next step is to configure the all node specific parts via the CLI instead by using the gathered network information.
I have to do some more tests. As soon I have more information I will provide more information.
On one hand you are right if you question the effort to reduce the manual intervention but this task will be repeated with the next OpenVMS release again...
Also we would like to update as much as possible systems at the same day. 1 hour per system just for the OS is too much. We must also upgrade ORACLE RDB and our own written application etc...
So far, thanks a lot for the hints and any more suggestions are welcome.
Let me know if you are interested in my findings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-27-2003 11:12 AM
тАО12-27-2003 11:12 AM
Re: OpenVMS TCPIP unattended configuration
actually we do run kinda-sorta a similar network, the only difference being that we do not have Rdb out in the field, but only at our main datacenter.
One thing we found useful is to separate OpenVMS and application upgrades. There are two main reasons for this:
1.)It makes trouble shooting much easier. If you do run into an issue after D-day, it can be either VMS (+ layered products), Rdb, or you own application, plus all kinds of interactions between them. This makes for a "fun" excercise at trouble shooting in a production environment. Taking out the OS upgrade at least does reduce the complexitiy considerably. And yes, I am convinced you do dilligent testing (I know we do ;-), but unless you have mathematically proven your application is correct (few people do) there is always a chance of trouble.
2.)It allows you to stagger the OS introduction, avoiding an (OS) D-day alltogether, giving an additional safety margin (The application changes in our case also on a specific release weekend).
All the best,
Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-27-2003 02:22 PM
тАО12-27-2003 02:22 PM
Re: OpenVMS TCPIP unattended configuration
What are your back-out procedures? and how much time is alloted for them? Or is that not part of managements planning. (Nothing ever goes wrong, or is delayed. Correct!)
It sounds like you have a much smaller maintenance window than should realistically be allowed for the maintenance tasks that you are performing. I know that Oracle Upgrades to a Live production cluster can mean up to 24 hours of downtime depending on the size of the DB. In comparison, my VMS upgrade is miniscule.
You have me beat on sheer number of Alphaservers. I have 156 with about 20 more on order. But mine are all in one data center!
Our clients allow for the quarterly/yearly maintenance activities that we require. We ask for a 4 hour window for a VMS Upgrade, OS Patches, Firmware, Layered Products, Oracle re-link, Time/Timezone, Re-boots and checks. This also allows us time to backout the changes if they do not work.
We used to do VMS upgrades in a 2 hour downtime window*, but then NOTHING can go wrong, and delays in shutting down the app/OS can send you over your 2 hour window.
* VMS Upgrade portion depends on the speed of the Alpha performing the upgrade.
What are you doing about Printer queues, UAF files, NTP, Mail/SMTP, ...Etc. All stuff that is potentially on the OS pack? Too me, there is just too much that could go wrong with so little time to do it in.
Are all of your Alphaservers the same hardware type? I.E. ES40's? or do you have a mixture. If you build this OS disk on a DS20, and then you move it to an ES40, you may need to perform an Autogen re-boot agains an ES40 prior to adding the OS pack to your production ES40. Otherwise your Alphavmspar files may get you.
Martin brings up a very good point about seperating your downtime work. If you really want to prove that there are no application bombs waiting to explode in your face, a full re-boot is required. This can add up to an hours time onto any maintenance window. (How long do your systems take to fully boot?) But it does prove if your maintenance messed it up or not.
Personally, I think that you are being setup for failure with your current implementation plan. There is too much that could go wrong with not enought time to do it in!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-27-2003 05:21 PM
тАО12-27-2003 05:21 PM
Re: OpenVMS TCPIP unattended configuration
(Repeat this for each cluster/OS pack)
Take a backup of your current OS pack. Restore the backup to a new disk.
VMS Upgrade the disk.
Apply any OS patches.
You now have a disk that is possibly*** ready to be placed into your existing cluster.
*** The Autogen re-boot will perform changes based on the hardware that is present at the time. If you have similar hardware, use this.
Note: Any changes that have been made after the time of the backup will be lost. (UAF, Printers... Etc)
The only way to fully avoid any loss of data is to perform the VMS upgrade during a downtime window. Make sure that your management knows the risks that they take by attempting to do the VMS upgrade offline.
I would not be too surprised if you find that you need to run Autogen and re-boot as a final step in your procedure. Or to fix your systems if you don't.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-28-2003 03:06 AM
тАО12-28-2003 03:06 AM
Re: OpenVMS TCPIP unattended configuration
Again many thanks for your feedback.
No, the mentioned servers are not in ONE datacenter and the system are not clustered nor we do use a SAN for them, just standard Ultra3-SCSI disks (MA)...
Each system is a DS10 with 1GB or 2GB memory and these have all the sam configuration. We are using hostbased volume shadowing (HVS).
On the D-Day we will dismount one shadowset member and this will be untouched (for sure we run before backup!).
If something goes wrong we can always reboot from that preserved shadowset member and continue the production.
Your agruments are correct referring to the fact if doing to much at the same time the risk is increasing that all could go wrong.
I will consider this.
Yes, considering the LPR/LPD print queues are also important to move.
The UAF settings are quite standardised...
We keep in touch.
BR
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-28-2003 04:02 AM
тАО12-28-2003 04:02 AM
Re: OpenVMS TCPIP unattended configuration
how about the old suggestion of moving your config files actually off the system disk? A short $show log tcpip* shows that all kinds of config files are actually referenced by logical names. So how about this: Prepare the config files for the systems before the rollout, ship them to the systems in the field (diskspace should not be a problem in this case ;-). Add an appropriate sylogicals to your master disk and you should be able to run this excercise with only one installation, that is the same for all systems.
Greetings, Martin