VMS 5.1.1 - Porting the existing application to a new OS

[Lim Jiann Neng]

Hi there,

Firstly, I am sure many of you might be surprised. VMS 5.1.1? Well, I know this has become a "dinosaur" but the fact is...I guess if you can help me on this, that could save our company :)

I just joined my company recently only to know that they have a machine running on VMS 5.1.1 for the past 14 years! There is a very critical application (very important to the business of our company) running in it. So my task is to try to "port" this apps to a new machine before that "fossil" dies out.

To be frank, I don't know anything about VMS. It doesn't seem to be a UNIX to me. I know HP has a new OpenVMS, but before I actually break my company's budget (we are just a small company) to get any replacement for it, I really wish to have a few questions solved:

1. Well, is VMS a UNIX?

2. If it is a UNIX, can I port that old apps to any UNIX clones? e.g. Linux?

3. If it is not, is HP's OpenVMS the saviour?

4. After browsing through many websites, I still don't have a clue about this VMS 5.1.1...so can anyone teach me some basic commands that I can use to "dig out" the contents of that old machine? Currently, I can use HyperTerminal in Win98 to dial in, but that OS doesn't seem to like my UNIX commands...

Thank you. Hope anyone out there can help me.

Lim,
Malaysia.

[Simon Tebbutt · Accepted solution]

Good morning Lim.

A quick answer is that no, (Open)VMS is not a Unix variant. As a starting point I'd recommend you check out the FAQ at (urls may wrap)http://h71000.www7.hp.com/wizard/openvms_faq.html

This forum is very new, and I would also suggest you may get more response if you post this to the comp.os.vms newsgroup (http://groups.google.com/groups?hl=en&group=comp.os.vms)

[Bradford Hamilton]

Lim wrote:

After browsing through many websites, I still don't have a clue about this VMS 5.1.1...so can anyone teach me some basic commands that I can use to "dig out" the contents of that old machine? Currently, I can use HyperTerminal in Win98 to dial in, but that OS doesn't seem to like my UNIX commands...

Hi Lim,

This site contains a quick primer for System Management of VMS systems:

http://h71000.www7.hp.com/training.html

The User's Guide also contains valuable information:

http://h71000.www7.hp.com/doc/731FINAL/6489/6489PRO.HTML

Please note that both resources are keyed to the current version of VMS (V7.3-1), but there are enough similarities between V5.5-1 and V7.3-1 to make the resources useful.

One other thing - VMS and OpenVMS are the same thing, just revised nomenclature. Most veterans of VMS consider the "Open" to be silent.

:-)

[Todd Maurer]

Lim,

Others have already made excellent pointers to web solutions.

For that version of OpenVMS (then simply VMS) there used to be what was affectionately called the "Gray Wall." This was a set of loose leaf gray binders that can fill a tall bookshelf. See if you can find this set of documentation at your site.

In the gray wall there were two sizes of binders. The larger binders were mostly reference material in the format similar to a dictionary. The smaller size binders were "User Guides..." that were more like an encyclopedia. I'd suggest that you start with those.

Todd

[Stanley F Quayle]

Your VMS system is running on a VAX. While new VAXen (plural of VAX) haven't been made for a few years, you can move the existing application, without a re-write to a VAX emulator.

I suggest you look at:

www.stanq.com/charon-vax.html

(And, yes, I happen to sell VAX emulators and services. If you fill out the attachment and email to stan@stanq.com, I can get you a quote on mirating your system.)

[Martin Johnson]

The docuementation for OpenVMS is some of the best I have ever seen! Try to get your hands on it.

Whether or not you can "port" this application depends on whether you have the source code and what environment you want to port to.

Porting to later versions of OpenVMS (6.x, 7.x) should be no problem - just backup and restore. The same for other VAX hardware.

OpenVMS is not Unix. While it supports Posix standards, they are not enforced. So porting to Unix may incur some problems. For example, if the developer made heavy use of system service calls, you may be doing a rewrite as opposed to a port.

Using a OpenVMS emulator will incur addition resource overhead, particularly CPU. If performance is an issue, this may not be a viable alternative. If you do not have the source, this is the only way you can port to non-OpenVMS.

If you are attempting to OpenVMS/alpha you will need the source. Once ported to OpenVMS/alpha you will be in position to port to OpenVMS/intel, which is the future of OpenVMS.

HTH
Marty

[Lim Jiann Neng]

Thanks everyone. I really appreciate all your guides and links given to me on VMS.

After reading through the faq and some documentation, I started to get to know VMS, and just a bit more time, I think I will be able to find a solution to my company.

Thanks again!

[Warren Sander]

For some of the 'what is vms' etc you can also look at a page we prepared for 'student research' at http://h71000.www7.hp.com/wizard/student_research.html

which as a number of pointers, some already given here but others like the 20th anniversary book have some insight.

also you might want to look at http://h71000.www7.hp.com/openvms-release-history.html which will let you know what 5.1.1 was released in June 1989

as for your unix commands that won't work. but of key importance is the HELP command (man in unix).

DIR (directory) command is the same as ls

VMS uses 'switches' the way unix uses command line options

ie

$dir/size=all/date/prot is fairly close to
ls -l

and
copy file.ext newfile.ext
is the same as
cp

etc.

[Stanley F Quayle]

Martin Johnson wrote:

> Using a OpenVMS emulator will incur addition resource overhead, particularly CPU. If performance is an issue, this may not be a viable alternative.

Actually, current versions of CHARON-VAX running on a 2 GHZ dual-processor PC are faster than any single-processor VAX ever built.

And they're working on creating multiple-processor versions...

[Martin Johnson]

Stanley,

You are right, the hardware has come a long way since they stopped producing VAXes. I was thinking about my experiences with emulaors back when they were still producing VAXes.

Marty

[Vinit Adya]

Lim,

The machine has been running for 14 years. Its is probably very stable. Its a critical app. Why do u want to get rid of the setup?
Just curious, what is the uptime of this node?
the command is:

$sh sys

We want to see the first line of the output. :)

[Bob Blunt]

Lim, VMS applications running for decades are
fairly common, no surprise there.

We need more information to be able to help you with the specific questions you've asked. Could you please provide the following information?

1) Please post the first line of output from
$ SHOW SYSTEM in it's entirety

2) For what is this VMS system being used, in
general (shop floor, database,etc)?

3) Please find the model of VMS system in
use, probably on the front near the
Digital logo, and post here; look for
"VAX" and a number

To add to the previous replies and to address your general questions... VMS isn't a Unix implementation. The interface you'll be using to interact with the system is called "DCL" and is an "English language-type" set of commands. There are books available that try to provide some correlation between Unix/shell commands and DCL. The command structure is pretty simple. The first command you'll probably need is HELP, which is somewhat similar to the Unix "Man" pages. This will list the commands that are available to you and give you a BRIEF tutorial. A word of caution, though. There ARE some commands that can cause your system to stop operating correctly, so be careful before proceeding!!! Check around for documents in gray or orange vinyl binders with the Digital logo. You should look first for manuals that have titles like "Guide to System Management." These can provide you with a good starting point and will probably generate more questions.

Generally speaking, replacing a critical system must first be a learning process. Once you understand the system's applications and how it works for your company, we can proceed with trying to help suggest viable solutions and replacements.

Have you considered having HP visit your site to work with you to help understand your system and what it does for your business?

bob

[Lim Jiann Neng]

Wow! Really thanks all the VMS Experts here.

Actually, it is my boss who is worried about the machine. He was the first user when they bought it back in the days when I just enrolled my high school :) I am still optimistic about the machine but of course, looking at the dusty appearance, I think it would be wise to ease his 'fear'.

I will resume my work on Monday so I promise I will paste all the screen output here with all the commands you have taught me. I am also raring to see what the system might tell me.

[Lim Jiann Neng]

I just read Todd's thread on "Points"...and oops, I guess I might have assigned them not accordingly.

I will amend this for future replies, although my original intention of giving everybody full points is not only I see that reply as a solution, but also it provides me with guides to the vast knowledge in VMS.

[ShyGuy]

Lim,

moving the applications on your VAX to a newer version of VMS should (as was mentioned by someone else) be as easy as upgrading the OS to the latest and greatest version, assuming the application is running in user mode.

It would also be good to know if you for example have any "special devices" attached to the system that might need special attention when you upgrade. Hence it would be nice to know the exact type of machine and if you have any "interesting" devices attached to it.

/ShyGuy

[Stephen Hoffman]

My first concern here would be to the integrity of the current application files and the application data. Ensure that you have reliable, complete, and consistent BACKUPs of the current system and current application configuration. (eg: a full standalone BACKUP of the system disk, and BACKUP copies of all data disks made with applications quiescent.) I would view this task -- ensuring current BACKUPs -- as critical.

I would then look for the source code for the local applications and for the names of the prerequisite products. With this information and with details of the existing VAX hardware, folks here can determine what the best upgrade path might be.

Most application images -- executable programs -- are expected to directly operate on more recent versions of OpenVMS VAX and also on other VAX systems, barring latent bugs in the code.

This path could involve an upgrade to less-old used VAX hardware, or (with the DECmigrate VAX-to-Alpha translation tool, or with the SRI or other VAX emulator for Alpha, or with the application source code and a source rebuild -- and the prerequisite products) a move to OpenVMS Alpha could be easily feasible. (Porting to OpenVMS Alpha is largely and usually a recompile-and-go operation, assuming the prereqs are available. Porting documentation is available.)

OpenVMS itself is presently being ported to Intel Itanium hardware, though I expect that any of the later VAX systems or most any AlphaServer or AlphaStation
system will provide you with years of continued service for this particular application.

[Stephen Hoffman]

My first concern here would be to the integrity of the current application files and the application data. Ensure that you have reliable, complete, and consistent BACKUPs of the current system and current application configuration. (eg: a full standalone BACKUP of the system disk, and BACKUP copies of all data disks made with applications quiescent.) I would view this task -- ensuring current BACKUPs -- as critical.

I would then look for the source code for the local applications and for the names of the prerequisite products. With this information and with details of the existing VAX hardware, folks here can determine what the best upgrade path might be.

Most application images -- executable programs -- are expected to directly operate on more recent versions of OpenVMS VAX and also on other VAX systems, barring latent bugs in the code.

This path could involve an upgrade to less-old used VAX hardware, or (with the DECmigrate VAX-to-Alpha translation tool, or with the SRI or other VAX emulator for Alpha, or with the application source code and a source rebuild -- and the prerequisite products) a move to OpenVMS Alpha could be easily feasible. (Porting to OpenVMS Alpha is largely and usually a recompile-and-go operation, assuming the prereqs are available. Porting documentation is available.)

OpenVMS itself is presently being ported to Intel Itanium hardware, though I expect that any of the later VAX systems or most any AlphaServer or AlphaStation
system will provide you with years of continued service for this particular application.

[Stephen Hoffman]

My first concern here would be to the integrity of the current application files and the application data. Ensure that you have reliable, complete, and consistent BACKUPs of the current system and current application configuration. (eg: a full standalone BACKUP of the system disk, and BACKUP copies of all data disks made with applications quiescent.) I would view this task -- ensuring current BACKUPs -- as critical.

I would then look for the source code for the local applications and for the names of the prerequisite products. With this information and with details of the existing VAX hardware, folks here can determine what the best upgrade path might be.

Most application images -- executable programs -- are expected to directly operate on more recent versions of OpenVMS VAX and also on other VAX systems, barring latent bugs in the code.

This path could involve an upgrade to less-old used VAX hardware, or (with the DECmigrate VAX-to-Alpha translation tool, or with the SRI or other VAX emulator for Alpha, or with the application source code and a source rebuild -- and the prerequisite products) a move to OpenVMS Alpha could be easily feasible. (Porting to OpenVMS Alpha is largely and usually a recompile-and-go operation, assuming the prereqs are available. Porting documentation is available.)

OpenVMS itself is presently being ported to Intel Itanium hardware, though I expect that any of the later VAX systems or most any AlphaServer or AlphaStation
system will provide you with years of continued service for this particular application.

[Martin Johnson]

ShyGuy is right about the special hardware. Make sure all your hardware is supported by the level of OS you upgrade to.

I don't remember the exact details, but the port I was using for DECnet dialin would not be supported in OpenVMS 7.2 without purchasing an extended network product. I moved the dialin port to a router. That fixed the problem.

HTH
Marty

[Lim Jiann Neng]

I have checked all the model numbers and use the command "show system"...here are the details:

Using "show system", the first line is

VAX/VMS V5.1-1 on node 15-MAY-2002 00:26:10.12 Uptime 33 14:48:17

The hardware comprises 3 machines, two smaller ones with dimensions of 31cm x 28.5 cm x 13.5 cm. The bigger one is of dimension 46 cm x 40 cm x 13.5 cm.

First smaller one is identified as "Server Tape" and model no. is TK502-63.

Second smaller one is identified as "Server Disk DKB 100". Model no. is RZ55-F3.

The big one is DJ-31CP1-A and is identified as "Server Disk DKA 100".

By the way, I am not sure if HP Malaysia has the experts in VMS because I have called them to request for their staff to come in...and they haven't given me any replies yet.

[ShyGuy]

Lim,

I know that that HP Malaysia has VMS experts - A customer of mine (a telco equipment manufacturer) did set up a production plant in Malaysia and Digital and later Compaq provided the customer with local VMS support. I'm confident that HP can do the same for you today.

/ShyGuy

[Vinit Adya]

Lim,
The machine has an uptime of only 33 days. Its date is also wrong.

TK50 is a tape drive
DKA100 Would be a SCSI Drive
Third one is also a disk drive. (maybe internal to the box).

Please check the following:

Memory:
$show mem

Configured disks:
$show device d/full

CPU
$show cpu

and just to make sure its not a part of cluster:
$show cluster

To check you application startup sequence:
$type/page sys$startup:systartup_v5.com

This would give yopu a basic idea on what is the Hardware/OS setup like.

Also you might want to check the DECnet settings:

$mc ncl sho exec

and for TCP/IP settings

$ucx sho interface

For you network card:

$mc lancp show device /char

[Bob Blunt]

Lim, some alternate commands that you may need, depending on your setup:

$ MC NCP SHOW EXEC CHAR (you may want to keep some of this information to yourself, the output will include passwords)

$ SHOW DEVICE E !to show network adapters

[Bob Blunt]

Lim, some alternate commands that you may need, depending on your setup:

$ MC NCP SHOW EXEC CHAR (you may want to keep some of this information to yourself, the output will include passwords)

$ SHOW DEVICE E !to show network adapters

[Willem Grooters]

Lim,

There could be another solution - I thought I posted this already but it could have been on another forum elsewehere.
There is a VAX emulator that runs on both Alpha (on VMS!) and Windows (a port to Linux is possible if paid for); all it does is: it emulates the HARDWARE and therefore you can leave your system and application environment WITHOUT ANY CHANGE; it's called Charon-VAX. Check www.softresint.com for some details. On HP hardware (either Alpha or Intel) it's fully supported by HP. They _should_ know.