Ultrix/32 & VMS

[David R. Stampf]

>From: senetza%vp.uleth.adhocnet.ca%UNCAEDU.BITNET at cornellc.cit.cornell.edu
>Message-Id: <890301094554.043 at vp.uleth.adhocnet.ca>
>Subject: Ultrix/32 & VMS
>To: unix-wizards at sem.brl.mil
>X-St-Vmsmail-To: ST%"unix-wizards at sem.brl.mil",SENETZA
>
>
>Our institution is considering the purchase of some VAXStation 3100's so that
>we can run both Ultrix/32 and VMS.  We've been told, by Dec, that there will
>be no problem with the 3100's running either of the OS's (they can choose the
>operating system while booting up).  This is fine, we can live with this.  But,
>I've got some questions about the compatability twixt the two.
>

	I would check this out - as far as I know, the 3100 only runs ultrix
and dec had no plans to port vms to the risc architecture.  If vms is
important to you, the 3100 is not.

>I've noticed that when I write a C program under VMS, there are a couple of
>'little' problems.  The main one is that files under VMS are stored in a
>different format (machine level stuff excused); they are stored in a record
>type of format whereas Ultrix stores files in a stream format.  So, when ever
>I write any programs which use, for example, fseek() to move to the end of file
>and then to back up through the file, i first have to run the file through a
>filter (basically a copy program).
>
>So, has anyone linked Ultrix/32 and VMS and had any problems that we, as
>possible buyers, should be aware of?  Any suggestions, hints, etc. that might
>be relevant?  Enquiring minds wanna know...
>
>Leonard Senetza   <senetza%vp.uleth.adhocnet at UNCAEDU.BITnet>
>
>"I'm not aware of too many things,
> I know what I know, if you know what I mean."
>
>

	Actually file formats are the least of your problems (although it is
a BIG problem!).  If you are porting code from unix to vms beware of

	1) signals - there simply aren't that many on vms
	2) ioctl -   simply isn't there
	3) fork -    works differently
	4) select -  ain't there either.
	5) #includes - the directory names don't work without some work on
			your part to define some alises.

	The problem is that the system level stuff in unix is really easy
to get at with one or two lines of code while the vms stuff is a bear to
get at from C.  For example, with 3 ioctl call in unix you can learn all
of the characteristics of the terminal that you are using.  With vms, about
three calls also suffice, but you first have to set up a channel to the
terminal, build up sets of descriptors (structs with field names like
dsc$b_class and other nonsense  - just in case you wanted to write a
subroutine or two in Fortran).  Even this isn't the end of the world - 
the *real* problems come in on semantic differences - the different way
unix and vms view files, terminals, exceptions and processes.  

	Toy programs should move fairly easily, and filter types of programs
have a chance (but the lack of real pipes makes those programs less valuable).
Expect problems from other programs however, and don't make any plans
concerning how fast you will port code.

This isn't a flame at vms (well kindof) its just that vms and unix are 
different.  A lot of this comes from an attempt to port some code from unix
to vms and hitting a lot of nasty roadblocks.

	Actually in my experience, if you told me that you were concerned
with moveing Fortran from one machine to another, I would feel that your
chances were much better.  I just don't feel that C code (not the language,
but the programs)  is all that portable.

Good luck.

	< dave stampf