werner@aecom.UUCP (Craig Werner) (03/09/85)
The following appeared originally in HCS News, The Harvard Computer
Review (now known just as The Harvard Computer Review) in response to a
similar discussion that was going on at the time in the local harvard readnews.
It is posted here without knowledge of the current editor, but I
was the editor of the Review at the time of publication. I mention this
only to save the author, Marty Sasaki, a lot of unnecessary mail.
---------------------------------------------------------------------------
Why UNIX Programs Don't Work on VMS
Marty Sasaki
There has been a lot of discussion recently about the relative
merits of UNIX and VMS. This article hopes to describe why UNIX programs
don't work well on VMS.
*Assumptions That C Programs Make*
Although C programs can be made to be portable, and compilers
exist for lots of machines and systems, most C programs assume that
they will be run on UNIX. These assumptions can be quite
subtle, but are nevertheless there. Here are some that have foiled many
program porting eforts:
1. Processes are cheap, i.e., they can be created and destroyed easily.
2. Input and output are cheap.
3. Input and output will be just like UNIX.
4. Input and output operations are device independent.
5. The command line interpreter will do wild-card file name expansion.
6. The command line interpreter won't do anything "unexpected" to a
command line.
Let's look at each of these and discuss why they don't work (or don't
work well) on VMS.
*Processes are NOT cheap.*
Processes on VMS are not cheap. They are very expensive to
create and the total number of processes around is very limited.
Typically VMS systems have a limit of 80 processes while UNIX
systems typically have several hundred. Process creation is very slow, as
is image activation (EXECing), compared to UNIX. VMS wasn't designed to
run many processes and balks when you try.
*Input and Output Operations are NOT Cheap*
A READ or WRITE on UNIX is relatively cheap, i.e., less than a
few hundred instructions are required. VMS i/o requires thousands of
instructions to queue an i/o request. You can measure the time (even on
a VAX) in tens (or hundreds) of milli-seconds.
Programs like VI that do a lot of i/o calls run horribly slow on VMS.
*Input and Output on VMS is VERY Different than on UNIX*
UNIX i/o is synchronous. UNIX i/o treats all devices uniformly
with no record types; data is just a stream of bytes. VMS i/o is
asynchronous. VMS i/o treats file system devices differently than
non-file system devices. VMS i/o is record oriented, the system keeping
track of the file type and record type.
When you do an i/o operation on VMS (a QIO), the operation is queued
and the program is free to do whatever it wants. When the operation is
complete, a software interrupt is sent to the program. Obviously, the code
required to implement this is much more complicated than a UNIX
i/o operation. The QIO mechanism is much more general, but when you
do a synchronous i/o operation without any bells and whistles you still
need to carry around all of the excess baggage.
VMS File handling i/o is done using the Record Management System
(RMS calls. RMS views a file as a sequence of records. There are several
types of records, and certain record types have user specifiable
attributes. RMS calls generally require the use of an Ancillary Control
Proces (ACP), which means a context switch, and the attendant
overhead.
*I/O is NOT Device Independent*
VMS treats file system devices differently than non-file system
devices. Mailboxes, which are used to implement pipes, form a third
group which can't be treated like terminals because pipes are
record oriented. Mailboxes are therefore between files and terminals and
must be special cased. Most C programs don't know about these things and
either act stupidly (and slowly) or do the wrong thing.
*The Command Line Interpreter Does NOT do file Name Expansion*
The command line interpreters (DCL or MCR) do not do wild card file
name matching or redirection of any kind. Programs which just read from
standard input and write to standard output or programs which don't do
ther own file name expansion will break.
*DCL Dos Funny Things to the Command Line*
DCL and MCR both capitalize everything on the command line. The way
to get around this is to put the thing you don't want converted between
double quotes. Of course everything between a pair of double quotes is a
single argument. This means that if you want your program to work exactly
the same way on VMS that it does on UNIX you have to write a parsing
routine to convert the mess that DCL gives you to something that your
program understands.
The flag or switch indicator ("-" on UNIX) is a "/" on VMS. Sometimes
DCL will confuse a "/" that is an argument to a command with a
switch. When it does this it will likely not find the switch in it's
table, print an error message, and never execute your program.
This list is just the beginning of the incompatibilities, but
should shed some light on the difficulties of porting C programs from
UNIX to VMS..
----------------------fr. The Harvard Computer Review
Volume I, No. 6, April 1984
--
Craig Werner
!philabs!aecom!werner
What do you expect? Watermelons are out of season!