Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!bnlux0!drs
From: drs@bnlux0.bnl.gov (David R. Stampf)
Newsgroups: comp.unix.wizards
Subject: Re:  Ultrix/32 & VMS
Message-ID: <861@bnlux0.bnl.gov>
Date: 3 Mar 89 14:09:54 GMT
References: <18496@adm.BRL.MIL> <1184@naucse.UUCP>
Reply-To: drs@bnlux0.UUCP (David R. Stampf)
Organization: Brookhaven National Lab., Upton, N.Y.
Lines: 72

In article <1184@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes:
>From article <18496@adm.BRL.MIL>, by drs@bnlux0.bnl.gov (David R. Stampf):
>With regard to porting unix 'C' to VMS:
>> 
>> 	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.
>You forgot link() and unlink().
>> 
>> 	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.
>> 
>
>Well, how about gawk, bison, flex, sc, diff, patch, and a whole bunch more
>``small'' programs that I've taken over to VMS.  Everything you've said is
>true in theory, but my experience has been that a lot of code is relatively
>portable and the problems encountered are familiar and easy to solve.

	Most of the programs you mentioned do not use signals, ioctl, fork
select, and the includes are managable.  Editors, network based programs, and
most interactive screen based programs are orders of magnitude harder.
I think it is fair to say that works like Gnuemacs and X have taken a
non-trivial amount of work to port which involved not only an editing of
the source code, but a rework of the program architecture as well.

	Also, I'm not speaking from theory here but my experience is quite
different from yours - primarily because of the types of programs that I am
porting.  (tn3270 is the most recent example which has a lot of unix built
in to it.)

>can be a pain, but I disagree that FORTRAN is easier to port than 'C' 
>(especially VMS FORTRAN from some place like LLL's headed toward unix...).
>

	(VMS FORTRAN) != (FORTRAN).  Anyone who programs *in* VMS Fortran has
just married DEC.  They should learn how to use the "/Standards" switch.  But
I agree, programming in a non-portable language is worse than programming in
C.  The only problem is that if a person hears that a program is written in
C, it is assumed (for some reason) that it is easily portable.  In fact,
programs are portable if they were written to be ported.  A fellow here
was writing a fortran program in a collaboration with people at CERN running
on an IBM and I beleive that it was also run on a VMS system.  This program
is HUGE, but because the development of the code was occuring all over the
world and the authors were aware of protability concerns, updates would circle
the globe virtually continuously and the code would always run on the various
OS's.

>Don't discourage people from trying these ports!  There is a ton of very
>nice unix code that can be ported and used on the more deficient VMS
>system (for those of us who will continue to earn a living on these
>dying machines the next few years).

	My remarks were not meant to discourage, but were only offered for
there information content and to temper unreasonable expectations.  Even if
some unix code cannot be exported, it is worth any effort to export the ideas.

>	John Campbell               ...!arizona!naucse!jdc
>                                    CAMPBELL@NAUVAX.bitnet

	< dave stampf

(P.S. Thanks to the dozens of people who straightened me out on the 
difference between DECStation-3100, and VAXStation-3100.  Sometimes it
pays to look beyond the least significant bits.)