Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!uflorida!haven!adm!xadmx!drs@bnlux0.bnl.gov From: drs@bnlux0.bnl.gov (David R. Stampf) Newsgroups: comp.unix.wizards Subject: Re: Ultrix/32 & VMS Message-ID: <18496@adm.BRL.MIL> Date: 1 Mar 89 22:17:18 GMT Sender: news@adm.BRL.MIL Lines: 75 >From: senetza%vp.uleth.adhocnet.ca%UNCAEDU.BITNET@cornellc.cit.cornell.edu >Message-Id: <890301094554.043@vp.uleth.adhocnet.ca> >Subject: Ultrix/32 & VMS >To: unix-wizards@sem.brl.mil >X-St-Vmsmail-To: ST%"unix-wizards@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 > >"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