Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: schultz@mmm.serc.mmm.com (John C Schultz) Newsgroups: comp.sys.sun Subject: Summary of how well HP and SUNs work together (L Message-ID: <1224@mmm.UUCP> Date: 3 Feb 89 00:57:06 GMT Sender: usenet@rice.edu Organization: Sun-Spots Lines: 253 Approved: Sun-Spots@rice.edu Original-Date: 26 Jan 89 03:35:23 GMT X-Sun-Spots-Digest: Volume 7, Issue 134, message 5 of 5 In response to several inquiries I got about my original question concerning mixing SUN and HP workstations, I have condensed several people's opinions in the paragraphs below and also included some received comments and tips on how to get SUNs and HPs to work together. The most serious problems that I can see are 1)that HP requires preformatted DC300/600 tapes, available only through HP (or from 3M I have found), which are not readable on a SUN cartridge drive, 2) HP networking and HP Unix is general is apparently not up to SUN's quality. HP and SUN work togehther more because of Sun's flexibility than vice-versa, and 3)HP uses COFF and adb. GDB won't currently work. A minor point is HP's fourteen character filenames. In terms of the hardware (I had pointed out that an HP 350 was significantly cheaper than a comparable Sun 3) the responses were split almost 50/50 between SUN is great and HP is great. (Also at the moment I am looking at EE Times Jan 16, 1989 with DEC's new 3100 price/performance entry into the workstation marketplace so the comparison of SUN/HP needs to SUN/HP/DEC.) Thank you everyone for the information and the opinions. john c. schultz __________ Summarizing some common responses: NFS - consensus was that NFS should work fine subject to the 14 char files names under HP-UX and where the standard places are for file. HP-UX is not Sun-OS or vice-versa. HP is Sys V based while Sun-OS is BSD based. This leads to somewhat differenent syntax on occasion. Separate executables - separate executables are required. I have included some very useful comments suggesting a means of organizing disks to help keep the binaries straight. __________ Selecting portions of responses uiucuxc!purdue.edu!trinkle: The main networking problem is that HP's TCP/IP is barely up to 4.2 BSD status. They do not allow you to configure the broadcast address, but the default is at least standard (all 1's in the "host" portion). You should also make sure you disable the IEEE software when configuring the network on the HP's. Mark Davis : 2. HP/UX in not SunOS or BSD. I could not get most of my programs to compile because of diffent include and library file locations uiucuxc!wheaties.ai.mit.edu!glenn (Glenn A. Adams): We just integrated 40 hp9000s300 systems into a large networked Sun environment with few problems. ... The main complaint with the HPs is the lack of job control, i.e., SIGSTOP, SIGCONT, etc. NFS interoperates nicely. In fact we adopt a file system architecture on the HPs similar to SunOS 4.0: we moved the HP /usr to a Sun file server under /export/exec/hp. This required moving a few things out of /usr to /var, e.g., /usr/spool, /usr/tmp, /usr/lib/cron, etc. All user directories live on Sun file servers. This leaves only 17MBytes on the local HP disk, giving pleny of space for swap and temp space. jcs>re my question on different executables__________ To solve this, we created a link tree for each system which is isomorphic to the source tree. Makefiles, objects, and executables are local to the link tree, sources stay in the source tree. For building X, your imake template will pick up the correct macros depending on the /lib/cpp predefines and build the correct Makefile tree specific to that system. The same can be done with most generic systems, e.g., GNU emacs, etc. As for installing local binaries, libraries, etc., we created an /export/exec.local/{hp,sun3} on the Sun file servers which gets mounted to /usr/local on HPs and Suns. All architecture dependent files go in there. Architecture independent local files go into /export/share.local/{lib,man,...} which gets mounted to /usr/local/share. Things like the emacs lisp libraries, X library directory (excluding SNF fonts), local man pages, etc. go there. Merging the systems certainly complicates matters a bit, but makes updating a bit easier in that you don't have to remember where all the copies of variants live; you can just conditionalize shared files as appropriate for minor variants. For example, we have default .cshrc and .login files that live in /usr/local/share/lib/ that get run by both HPs and Suns. This allows us to instantiate as identical environments as possible on the different flavors of systems. uiucuxc!Sun.COM!mhyman%hsfmsh (Marco S. Hyman): ::::::::.cshrc:::::::: ... if (! -e /bin/sun) then set path = ($path /usr/hp64000/bin) endif ... # set up proper prompts for HP system sub-shells. hp-ux will have # set a bogus prompt at this point. if (! -e /bin/sun) then if ($?PS1 == 0) then set PS1="% " endif set prompt="`hostname`$PS1" endif # suntools only aliases/commands if (-e /bin/sun) then if ($?WINDOW_ME != 0) then alias cd 'cd \!*;echo -n "^[]l`hostname`:$PWD^[\"' cd endif endif ::::::::.login:::::::: if (-e /bin/sun) then w else who endif echo "" # Commands tp perform only when logged in from the system console if (`tty` == /dev/console) then if (-e /bin/sun) then # startup suntools unless on the server if (`hostname` == hsfsrvr) exit echo -n "Suntools? (^C to interrupt) " sleep 2 suntools clear set tmplink=/tmp echo -n "clearing $tmplink... " find $tmplink -user `whoami` \ \( -name MT\* -o -name Text\* -o -name tty.txt\* \) \ -exec rm {} \; -prune echo "done" logout else # fire up X-windows echo "X-Windows? ([y] or n) [timeout in 3 seconds] \c" set response=`line -t 3` if ("$response" == "") then set response=y echo $response endif if ($response == y) then xstart clear bye endif endif endif ------ Notice the use of if (-e /bin/sun) ... instead of if { sun } ... For some reason when /bin/sun was linked to /bin/false on the HP the Sun startup stuff ran on both machines!? uiucuxc!grad1.cis.upenn.edu!salex (Scott Alexander): It is also worth noting that HP's use COFF so gdb doesn't currently work on them. This is one of my biggest problems when trying to do code development locally. uiucuxc!cad.cs.cmu.edu!Clauss.Strauch: HP-UX is SYSV with Berkeley extensions. At one time HP-UX #$%^&*. Right now, it's actually pretty good. HP is slowly adding more Berkeley-isms, and when HP-UX 6.5 comes out(this March??), they'll have job control(long filenames come out in 6.2). A bad point is that, right now, some of your favorite Berkeley code won't compile without some reworking at the system call level. This problem is supposed to mostly go away, as we progress to HP-UX 7.0 and up. The good news is that most of your(at least my) favorites are there and working OK: NFS, X11, GNU Emacs, Lucid(and Allegro) Common Lisp, Berkeley sockets, Berkeley print spooling. In fact, if you run X11 on an HP, you'll ***never*** want to go back to a Sun, it's soooo much faster. uiucuxc!harvard!ulowell!infinet!rhorn (Rob Horn): We just hooked up an HP 9000/3xx on tuesday (3 days ago). So far I can say: a) HP system setup/build facilities are much worse than Sun's. Particularly when on a multi-vendor network. uiucuxc!uunet.UU.NET!stpeters%dawn%steinmetz: We have a pair of 350's on our Sun-dominated network. As they say, there's good news and bad news. The HP's slipped right into our overall NFS filesystem: the Suns can mount the HP's and vice-versa. HP's NFS seems to work well - better than some others. HP's UNIX definitely has a different "feel" from SunOS. It's SysV based with BSD add-ons. Most of the commands are the same, but the options are often different. Things are sometimes in different places; for example /etc/fstab is known as /etc/checklist. By default, HP UNIX has the SysV 14-character limit on filename length. Supposedly, you can configure away the limit somehow. However, the software for the hardware attachment for which we got the HP's in the first place doesn't work if you do this reconfiguration, so we haven't done it. The HP's use terminfo, not termcap. Since the Sun can use either - and has utilities to go from one to the other - we were able to generate Sun terminfo entries for use on the HP's and to make HP termcap entries for use on the Suns. Note that it was the Suns that provided the flexibility needed to accommodate the HP's: this as much as anything else seems to characterize the differences. A couple of gotchas: although the HP cartridge drives use the same physical media (e.g., DC600A cartridges) as other machines, THE HP DRIVES WORK ONLY WITH CARTRIDGES FORMATTED BY HP. You cannot read from a Sun tape, and you cannot write to a regular unformatted blank tape. In other words, they go out of their way to be incompatible. Needless to say, HP charges a premium for formatted cartridges. HP does not yet have a remote dump/restore. This has been a major headache for us, since we have a local in-house network backup service and can't use it for the HP's. uiucuxc!longs.LANCE.ColoState.Edu!scott: Re: HP-UX 6.2 I hear dump is less than robust in the device handling end so we pipe to tcio. In our case tcio uses 1/3 the wall clock time to finish. Dump assumes /etc/dumpdates exists and will fail (at the end) if it isn't there, so you should touch /etc/dumpdates the first time you run dump. Another HP omission is a worldly print spooler. HP-UX does not (yet) support disk partitioning, and you must export the entire disk (no exporting subdirectories here). You may not grant root access to an exported filesystem (you can mount from the SUN with root access). We have found problems trying to use SunOS .login and .cshrc files with HP-UX. john c. schultz schultz@3M.Com ..!uiucuxc!mmm!schultz (612) 733-4047 3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000 The opinions expressed herein are, as always, my own and not 3M's.