Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Looking for some help-VMS Severs running Openvms V8.3-1H1

Go to solution
Shriniketan Bhagwat
Trusted Contributor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1


You can use the cluster over IP feature for your DRP setup. This is a new feature in V8.4. Please refer section 5.1 from the v8.4 new features documentation.


Also refer section 3.3 from VMS clusters.


Shriniketan Bhagwat
Trusted Contributor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

The Gunners
Regular Advisor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

Hi Shriniketan,
Thanks for the info there , we are still on V8.3 at the mo unfortunately , Im not sure they will agree to an upgrade just yet. I'll have to put that on the 'things to do' list that we can look at down the line , I guess its back to the backup or copy option again so :(
Frequent Advisor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

Clustering with Host based shadowing would be nice. However if you can't do that, I am wondering if a simple BACKUP will do what you want. It will be, as long as you restore the files on node 2 after every BACKUP.

If you don't do the restore, you would end up with a whole bunch of savesets on node 2 and then in the event someone wanted to use this system, the files would have to be restored at that time.

I would suggest that you might want to consider using a COPY/MODIFIED/SINCE=
Honored Contributor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

In addition to what Ketan has indicated, it has been possible to cluster over IP for a decade or two (and supported), using what is known as LAN bridging. Bridging a LAN requires no software upgrades and no related processing, but does require bridging hardware in your network. Cisco managed switches have been commonly used for this for many years; you'll see this technique used both for SCS and for LAT, too. (The V8.4 stuff saves you on some LAN hardware, but requires you to mess around with some of the low-level setup and with IP. Bridging allows connections via classic SCS, so it works as it always has.)

One of the other options (which is easier than clustering, requires no VMS V8.4 upgrade and requires no clustering) is DECnet over IP via DECnet-Plus (also referred to as DECnet Phase V, DECnet/OSI), and that allows you to use all the usual old VMS tools directly. This is software-only and you likely have licenses for it, and this allows you to use DECnet DCL task-to-task and related among your hosts. Even via the open internet, if you have enough bandwidth for that.

Here's a simple DECnet tool for BACKUP:


However... Clustering via the V8.4 support or clustering via bridging is probably overkill here. Probably also DECnet-Plus here, too.

While you won't find modern IP networking tools on VMS, any experienced VMS DCL programmer can write some baseline stuff easily. For this case, that's usually based on a zip "-V" (to compress the files and the "-V" to protect the RMS metadata attributes) and then COPY /FTP /BINARY over to the remote host. Zip works as well as BACKUP for this stuff, and you can access the zip contents on arbitrary platforms. And since you're just doing backups, a simple approach is to ftp (or sftp) the zip archives over to HP ProLiant or HP-UX or VMS or other analogous servers; just dump the copies on some big disk storage somewhere else.


Alternatively, use BACKUP and a DCL procedure such as the following:


and that procedure probably modified to zip "-V" (to compress and with "-V" to protect the saveset's metadata) the resulting BACKUP saveset and toss each saveset over to the file server via ftp or sftp.

And yes, I keep pointing to "-V" on the zip command. Read up on it. Hug it. Kiss it. Use "-V" on your command. Yes. And yes, with the quotes, unless you're running extended RMS parsing. "-V" is your friend.


As for the original question, I'd probably be looking at the predicament of the development staff. In all bluntness, a VMS programming staff that cannot effectively write baseline DCL backup procedures and similar utilities and tools probably needs some additional training and platform time, or the organization needs an escalation or custom support path for getting these utility procedures written, or needs to acquire or access to some staff that can provide these tools. Not having basic DCL experience available means your organization is inherently not using the VMS platforms to their full advantage. Your organization is potentially leaving performance optimizations, process optimizations and simplifications on the proverbial table. This is entirely your call and your management's call here, of course, but something to ponder.
The Gunners
Regular Advisor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

Ok , thanks to everyone for all the replies so far (points to come :) , I have a bit more info now having chatted to one of the users. It seems out of all the disks , there are only really four that will be updated. I dont have the exact directories yet from them but basically all they want is a script that will run every hour or two on these directories , check what has been created or modified , and copy it over to the second node into the same named directories. A house keep job could then be setup on the send node to purge down versions etc. - Re one question that someone asked re the users skillset ( I think it is more political to be honest) they asked/want us to do it as it falls under backups as far as they are concerned
Robert Gezelter
Honored Contributor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1


Clustering would be a nice option, but it may well be overkill in this context (and I say this as a OpenVMS cluster advocate).

This is more a problem of source/image control. Personally, I would be inclined to treat this using a build type tool together possibly with proxy file access.

One cautionary note, depending upon precisely how this is implemented, it may be very important to keep both sets of system clocks fairly well synchronized (e.g., an external source of UTC).

BACKUP may even be overkill, this may well be implementable using vanilla COPY (although the archived BACKUP save sets would provide a useful audit trail).

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

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

Are these users seeking the tools to manage and maintain source code and build products (images, libraries, etc) across multiple systems?

Are these users seeking to acquire or to implement some sort of a distributed version control system (DVCS)?

If so, then I'd probably skip all the DCL and ftp and the periodic file copies and related, and start looking at setting up and migrating to a Mercurial (Hg) distributed version control repository, and using that with VMS.


(Git is another very popular DVCS. And while there is a jgit tool available for accessing remote git repositories from VMS and other Java-capable platforms, what few discussions are posted around imply that an approach based on jgit on VMS might not be particularly robust, nor necessarily as well-documented as other options.)

There are other and older DVCS systems around, too. Subversion (SVN) can work, for instance. There are others.

Choosing to create and deploy your own source code control and versioning system can be somewhere between wasteful and impolitic.
The Gunners
Regular Advisor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

Ok , I finally have the definitive requirement.
Basically we have two standalone systems in separate locations that wont be clustered (about 10 miles apart just for info and the network is quiet good).

lets call them SYSTEM A and SYSTEM B both running Openvms version 8.3-1H1.

System A is the primary Developement server and if theres an issue with this , then they will use SYSTEM B (at a best endeavours basis).

So, what they have asked for is mabey twice or 3 times daily a job that either does an incrementaltal backup or a copy/since the previous one (ONLY IN CERTAIN DIRECTORIES ON ONE OR TWO DISKS)
and then copies the contents over to SYSTEM B (which will have the same directory structure either by means of a restore from a save_set or either a direcct copy over decnet (if this is possible Im not sure)

Ive been thinking of a few ways of doing this including taking into a/c some of the advice you have given me, and Im thinking stuff like 'backup/record' and then a since qualifier in tandum with that command , however Im stuck as regards how to actually write this stuff up (My main role is Oracle DBA) so I dont have the dcl skills - could someone even advise on a simple script here , and I can then modify it to my own requiremnts. This wold be a great help and I may even learn something about dcl in the process.
Thanks as always guys n gals
Joseph Huber_1
Honored Contributor

Re: Looking for some help-VMS Severs running Openvms V8.3-1H1

The easiest for copying a single directory update using DECnet is using COPY on the target system (SYSTEMB::):

$ SET DEFAULT dev:[targetdir]
$ COPY SYSTEMA::remdev:[sourcedir]*.*/since="''f$time()'-4" [][/log

This assumes to have a DECnet PROXY defined for the user issuing the command, otherwise the remote system specification has to include the user credentials like
SYSTEMA"user password"::

To do incremental backup of several subdirectories, use backup on the source system to a remote saveset like:

$ backup/record [...]/since="''f$time'-4" SYSTEMB::last.sav/save