Summary of how well HP and SUNs work together (L
John C Schultz
schultz at mmm.serc.mmm.com
Fri Feb 3 10:57:06 AEST 1989
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 at 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.
More information about the Comp.sys.sun
mailing list