www.grootersnet.nl

The soft side

OpenVMS = OPEN environment

A lot of Unix and Windows software is, or can be ported to VMS. Believe it of not, but VMS is one of the most open platforms in the market. Only, one should remember that VMS is not like Unix and has his own methods for all kinds of facilities. Most of them built-in, like (distributed) lock management, record management, memory management, error handling, some built upon VMS, like TCPIP, CDSA and ACME. All industry, open standards.

Just getting an application compiled on VMS doesn't mean it's ported. That requires more than just compilation. It also means that the software should adhere to the VMS-way of doing things.

Developers ought to take a look to the next manuals, if they intend to port their software to OpenVMS:

OpenVMS programming Concepts
Guide to OpenVMS File Applications
OpenVMS Command Definition, Librarian, and Message Utilities Manual
OpenVMS Debugger Manual
HP OpenVMS I/O User's Reference Manual
OpenVMS Linker Utility Manual
OpenVMS Record Management Services Reference Manual
OpenVMS Record Management Utilities Reference Manual
HP OpenVMS System Services Reference Manual

plus the different RunTimeLibrary manuals (OTS, LIB, STR)

(Not just the non-VMS developers. Even VMS developers can learn a lot of this)

Differences

There are some differences between Unix and VMS, but most are easy to overcome.

Case senitivity

Unix is case sensitive. No-one has been able to explain why that is, but it's a fact. Fact is you have to take care of that. Within VMS, setting a number of logicals and assure the right storage environment can help overcome this behaviour:

Use ODS-5 structure. That allows you to have filenames that are rather normal in Unix: dots in a file name (even in directory names), long names, case sensitivity in naming, and, if you really want it, in searching files:

(TBD)

File IO

The way UNIX stores it's data on disk looks more like a "programmed virtual memory storage" - streams of bytes normally stored in memory are dumped to disk. It has it's consequences on file- and record attributes. Unix files are typically LF-delimited streams of bytes = STREAM_LF in VMS terminology, and record attributes - well, actually there are no records, it's just a stream of bytes.
Since Unix lacks the concept of records, there is just sequential access - and a program might be able to do some kind of "sequential record access", or even " relative record access" but indexed files are beyond the capabilities.
That makes it hard for Unix-based programs, just using the Unix way of data storage, to co-operate with native VMS files directly. Unless the program's IO is rewritten to use RMS.

Parameter passing

Parameters are normally passed to a program as a list of -<letter> [<value>] combinations. More modern Unixes use a " vms-like" way: --<name> [<value>]. Some take a value, some take none. This is implied by the C language that has this facility.
That would not really be the worst thing. It's just that these letters might be an abbreviation, but often, it's an arbitrary choice. And if a number of values is allowed, use the parameter another time, and another; as much as needed. However, some programs seem to allow a list in brackets....
The VMS way is use /AFTER /APPEND - and use a comma separated list if multiple values are used. All this specified in a Command Definition: .CLD - so it can be added to the command-tables.

In some cases, it may be too much trouble and introducing overhead. But in the VMS case, the command interpreter will take care of checking the validity and compatibility of options, where, i Unix, the program has to do that - if it does..

Error handling and messages

Start a Unix program, and if something goes wrong return status will be 1, or 2, or -1.... If it's not 0 then something IS wrong. But what? The program may tell you, but sometimes it won't, of it would but not the complete story. Worse: if it were a system error, you would probably not be told. It might even return 0...(I have seen that happen!)

In VMS, any odd value means " It's Ok", any even value means " something's wrong". The value itself tell you what the problem is. The last 3 bits tell you the severity. The upper 5 bits tell you where it comes from. The value and it's counterpart (the message text) is described in a message file that is compiled to an object file, that you link into your program (static text) or build to be a shareable image, that your program is linked against (dynamic text) - making internationalization a piece of cake.

Help

The unix command "man" means "manual" - and tells you all options of a command, program, or whatever needs to be explained. ALL, without real structure.

VMS help is different. It tells you about the command, program, or whatever needs explanation, in chunks that form a concise block of information, and just the options and extra data that is applicable at that point, so you can drill your way down (and up), following the structure of the command and it's options.

and more

Yes, there is more to look for, would you want your program to be fully VMS-compliant. Ok, if the program works without, it's a good thing to start with - most VMS users are forgiving enough and will allow differences. But if these issues are taken into account and handled properly, so more the better.

We do have JAVA, don't we?

We do, and most JAVA software really works on OpenVMS. Some things don't, but these will normally not matter.

The concept: writing software on one platform and deploy it on another, is great. And that was the original idea: to be able to create software on a (Unix) workstation that would control cell phones, machinery, whatever - a completely different processor and operating system. Second, it made it possible to have small " programs" be transferred over the Internet, to be executed in it own environment without chances of interfering with the native, local operating environment, and without the ability to ruin the host's data, like could be done using Microsoft's ActiveX execlets.

The concept of "compiling" towards a " Virtual machine" isn't new either. The new thing was that it would result in byte code to be interpreted by a "virtual machine". Mind: interpreted - and executed, in it's own 'environment', without knowledge of the underlying Operating System, if any.

Because of the interpretation by the VM, made the use of pointers (which is very efficient) impossible. It also makes an efficient memory management practically impossible. The SUN solution is an automated garbage collector, that cannot be triggered from the program.

This makes Java a highly inefficient, memory-intensive environment, that may be, in times, very CPU and IO-intensive as well.

It may be less dramatic on Unix and Windows systems, that have rather straight forward memory management algorithms.

With VMS however, with it's fine-grained memory management, JAVA is more or less a disaster. There are recommendations but the bottom line is that you have to abandon proper system management and just install a big bunch of memory and additional CPU power, and allow any process to use all of it.

My advise: if you can, avoid JAVA.

Sometimes JAVA is unavoidable.
Tomcat and AXIS are written in JAVA, and do it relatively well on OpenVMS. Still, for top performance, you need at least 1Gb of memory, throw all good system manager's practices overboard and just follow the recommendations.
In no case should you account for IO:

2180014D APACHE$TOMCAT HIB 5 1446385 0 00:25:47.13 13386 5362 M

Note that this is the harvest of 20 hours, doing nothing but "being there"...

In most cases, there is not a real problem if you have tuned these processes right and have a large enough pagefile, and in most cases, not too large Java programs work just fine. I tried JALBUM (creating photo-albums for the web) and that's Ok.

But if you have the choice between a natively build executable, or a JAVA one, I'd take the first. It is far more efficient.

If you want to develop in JAVA for VMS to be used on another platform: NETBEANS (which is JAVA) works fine - assuming you have a big machine and followed HP's recommendations. You could think of Distributed Netbeans - even nicer, because Netbeans itself could run on any platform - VMS, Unix, Windows - and storage and compilation could be done on VMS (not just Java. FORTRAN, C and C++ can be handled that way)

Developing in JAVA, on VMS for VMS is another story:

It's ridiculous.

Why should you add all this overhead and bad behaviour and non-standard requirements, if there are the native solutions in any language: COBOL. FORTRAN, PASCAL, C and C++ (and non_HP supported like RUBY, MODULA2 and EIFFEL). And, you can use Distributed Netbeans if you're fixed to a GUI....

I have been thinking of an alternative.

The main problem we face is the differences that exists between operating systems. Would it be a weird idea to abstract the functionality into a specification and create a library - Operating System specific - where these are implemented - native to the OS?
Most people seem not to realized that languages like COBOL, Fortran, Pascal, C and C++ are standardized from the beginning, and still expanding in possibilities. The latest COBOL has object orientation, I think Fortran has as well nowadays (or it will be possible in a future release.) If you keep to standards, it will compile on any platform.

I called it Open Kernel Application Program Interface - OKAPI.

But I guess the "Open Source Community" is too arrogant to think different. So I dropped it, for now. Unless others are willing to help building up a specification.

Back to HowTo

Back to OpenVMS

Back Home