senetza%vp.uleth.adhocnet.ca%UNCAEDU.BITNET@CORNELLC.CIT.CORNELL (03/02/89)
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'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@UNCAEDU.BITnet> "I'm not aware of too many things, I know what I know, if you know what I mean."
drs@bnlux0.bnl.gov (David R. Stampf) (03/02/89)
>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 <senetza%vp.uleth.adhocnet@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
warner@hydrovax.nmt.edu (M. Warner Losh) (03/02/89)
In article <18496@adm.BRL.MIL>, drs@bnlux0.bnl.gov (David R. Stampf) writes... > 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'd like to clarify one point here. The VAXstation 3100 DOES run VMS and ULTRIX. The DECstation 3100 is a MIPS box only runs ULTRIX. Damn I hate it when major companies have different products with the same product number :-) -- Warner Losh warner@hydrovax.nmt.edu ...!unmvax!nmtsun!warner%hydrovax What happened to our innocence, did it go out of style? My spelling and views are my own. Only the letters have been changed...
parker@waters.mpr.ca (Ross Parker) (03/02/89)
In article <18496@adm.BRL.MIL> drs@bnlux0.bnl.gov (David R. Stampf) writes: >>From: senetza%vp.uleth.adhocnet.ca%UNCAEDU.BITNET@cornellc.cit.cornell.edu >> >>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. > The *DECstation* 3100 only runs Ultrix... the *VAXstation 3100 will run either. It seems a little ambitious, however, to be able to choose between VMS and UNIX at boot time... the file systems are *waaaaaaaay* different. This would perhaps be possible if you had a set of disks for UNIX, and a set for VMS. Ross Parker uunet!ubc-cs!mpre!parker | Microtel Pacific Research Ltd. | You can't erase the dream, Burnaby, B.C., | you can only wake me up... Canada, eh? |
brolsma@bbn.com (Bruce Brolsma) (03/02/89)
> I would check this out - as far as I know, the [VAXstation] 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. You're not the first person to confuse the VAXstation 3100 (which runs ultrix and vms) and the DECstation 3100 (the risc machine). The DEC marketing folks could have made it easier on us with two names that aren't so similar, but I've never had much luck figuring out a lot of marketing decisions... -bruce brolsma bbn software products corp
avolio@decuac.dec.com (Frederick M. Avolio) (03/02/89)
Just to fill in a few blanks. VMS and ULTRIX both run on the VAXstation3100. The VAXstation3100 is a VAX. See? That's why we didn't call it the FREDstation3100 (my choice) :-). (The DECstation3100 is the RISC machine, ULTRIX-only.) VAX/C runs on both ULTRIX and VMS. As does VAX/Fortran. That helps with portability as well as the fact that both are built on industry standard specifications. Typically what I've seen people do is have the VAXstation be part of a LAVc when it runs VMS, and have a local disk to run ULTRIX in its ULTRIX live (or be diskless and boot off of an ULTRIX machine -- this takes a trifle more system administrator action). Now, it would be really nice if there existed a porting guide. You know something that would say "Things to watch for between... sun/os and ultrix, hp/ux and ultrix, vax/c on vms and vax/c on ultrix, pcc and vax/c, etc. etc." But you'd have to talk to your sales rep for something like that anyway. Hope this helps. Fred (speaking as an ultrix user mostly and certainly not an official Digit)
dcmartin@cs.wisc.edu (David C. Martin) (03/03/89)
Your message:
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.
No, no, no.. there are VAXstation 3100 and DECstation 3100. The former is
the VAX chipset and the latter is the Mips chip. He was talking about the
VAX 3100, not the DEC 3100. I guess DEC wants people to be confused and
by the VAX3100 by mistake :-)
dcm
--------jdc@naucse.UUCP (John Campbell) (03/03/89)
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(). > > 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 ... and lots of reasonable, but scary compatiblity concerns. > 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. VMS 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...). 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). -- John Campbell ...!arizona!naucse!jdc CAMPBELL@NAUVAX.bitnet unix? Sure send me a dozen, all different colors.
senetza%vp.uleth.adhocnet.ca%UNCAEDU.BITNET@CORNELLC.CIT.CORNELL (03/03/89)
Just a little clarification about the 3100's we are planning to purchase. Yes, we are planning to buy VAXstation 3100's. But, to be used for teaching introductory courses (on VMS) and upper level courses (Ultrix). They will basically be used as terminals in the lower courses, and workstations in the higher (graphics, operating systems,etc.). Yes, we are planning to buy a DECstation 3100. This will be used as a boot node for when we want a VAXStation to run Ultrix. Otherwise, the VAXstations will boot off of a 6210 running VMS. So far, the comments (critisisms? flames?) have been very helpfull. We're looking forward to more -- even if there aren't any positive ones!! Leonard Senetza <senetza%vp.uleth.adhocnet@UNCAEDU.BITnet> "Philosophy, is the talk on a cereal box. Religion, the smile on a dog." (Expressed within are my own opinions, I think)
drs@bnlux0.bnl.gov (David R. Stampf) (03/03/89)
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.)
bzs@Encore.COM (Barry Shein) (03/04/89)
>It seems a little ambitious, however, to be able to choose between VMS and >UNIX at boot time... the file systems are *waaaaaaaay* different. This would >perhaps be possible if you had a set of disks for UNIX, and a set for VMS. Actually, something I thought about years ago when in a similar situation was to get a big disk, set it up for VMS and put all of Unix into a contiguous VMS file. It would take some minor changes to the boot, partition and driver (maybe not anything to the driver as long as the partition info matched) but seems like it should work, no guarantees, but I thought I'd pass the idea along. Might make for at least one amusing note to this group... -Barry Shein, ||Encore||
daveb@geaclib.UUCP (David Collier-Brown) (03/05/89)
| From: senetza%vp.uleth.adhocnet.ca%UNCAEDU.BITNET@cornellc.cit.cornell.edu | 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@UNCAEDU.BITnet> From article <18496@adm.BRL.MIL>, by drs@bnlux0.bnl.gov (David R. Stampf): | 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. [...] | 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. Well, I won't claim to have much use for VMS, but several classes of programs can be ported usefully. The obvious ones (If you've read my signature), are interactive editor-like programs, like word processors and cad-cam programs. The hard part is dealing with system-level facilities: the massive front ends you have to create to do on-screen interactive stuff dominate the effort (:-)) --dave David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B