schultz@mmm.serc.mmm.com (John C Schultz) (02/03/89)
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 <uiucuxc!cs.unc.edu!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.
burdick@hpindda.hp.com (Matt Burdick) (02/22/89)
Since the summary that I am reponding to has some inconsistencies in it, I thought I'd try to clear some things up. All the information I post here applies to the most recent versions of HP-UX. Earlier versions may be different. Also, I have not commented on all of the possible subjects - only the areas in which I know something about. Cartridge tapes: The format for the cartridge tapes for HP's series 300 workstations are not compatible with SUN's. HP's format is based on a 3M standard. Operating System: HP's HP-UX is entirely compliant with System V R2, but the networking code is Berkeley 4.2-based. HP is also adding functionality from 4.3 BSD when possible. Many Berkeley library functions are available in /usr/lib/libBSD.a for compatibility. SUN's Sun-OS is Berkeley 4.3-based. Job control (SIGSTOP, SIGCONT, ...) is supported on HP's series 800 machines, but not on the 300 series (at least up to HP-UX 6.2). HP-UX 6.5 (coming out Real Soon Now) will have job control. File System: SUN's file system supports long file names (255 character names) only. HP-UX supports both long and short file names (14 character names). Short file names are supported because some applications do not expect file names to be any longer than 14 characters. The catch is that once you convert a file system from short file names to long file names, it isn't possible to reverse the process. NFS does work between the two systems, but HP doesn't support version 4, which means that you can't export subdirectories - only file systems. Also, it is not generally possible to grant root access to an exported file system. The hack below, however, will allow this, since it patches the kernel to change the uid of 'nobody' to 0 rather than -2. Note that this patches the bits in the /hp-ux file rather than the running kernel. Therefore, to use it you must reboot the system: #!/bin/sh /bin/adb -w /hp-ux <<-"END_SEMI_CLUSTER" nobody?W 0 END_SEMI_CLUSTER Networking: HP-UX systems allow either IEEE 802.3 or Ethernet packets on the LAN. Executable programs: These cannot be shared between HP and SUN workstations. Terminal support: HP-UX uses terminfo while SUN uses termcap. Printer support: HP-UX uses 'lp' rather than Berkeley's 'lpr'. However, 'lp' does connect to 'lpr' in such a way that the two work together transparently (a SUN can print to a printer on an HP-UX system and vice-versa). For purists, there is an 'lpr' script that is a wrapper around 'lp' that can be used (I'm not sure if it's shipped with HP-UX or not, though). I hope this helps to clear things up a bit. -matt Disclaimer: The opinions expressed above are my own, and not those of my employer (or perhaps any rational being). Matt Burdick | Hewlett-Packard burdick%hpda@hplabs.hp.com | Technical Communications Lab