ruben@bcstec.boeing.com (Reuben Wachtfogel) (06/05/91)
Apollo Miscellany
I've been working on apollo for 4 years now and overall,
I've enjoyed the experience. Some thoughts, technical
questions, etc.. to share with anyone who's interested.
1) At the ADUS conference in New Orleans, the first after
Apollo became HP/Apollo, the subject of doing away with
AEGIS came up. The uproar was quite significant.
At a subsequent conference the subject of not supporting
OSF on most Apollo platforms came up. Again an uproar with
the result that now we get OSF but we can forget about
DOMAIN O/S. Also, HP gets to send everyone letters titled
"We listened to YOU !"
Now I'm not saying good or bad, but it occurs to me that
if HP WANTED to do away with DOMAIN O/S, they couldn't
have picked a better strategy. By threatening not to give
us the new stuff, we practicaly begged them to dump support
for DOMAIN OS.
AHA. Eets Ze old if they want the new stuff, they can't
have support for the old stuff ploy. Whatever happened to good
old buzzwords like "upgrade path". Maybe I'm just nachully
too suspicious but time will tell if we've sold the cow for
a handfull of rotted beans.
Sure, sure, standards make life easier in the long run but
If Mom were here wouldn't she say something like, "If the
standard said to jump off a cliff, would you do that too ?"
Will HP/Apollo at least offer documentation for suggested
OSF alternatives to DOMAIN/OS sytem calls where applicable ?
Let me know if I'm completely off-base here. I may be
missing something (e.g. like a screw or two).
2) How come that bug I reported never got fixed ? I don't
know if it's strictly a domain dialog problem but my Hi-Res
colors nodes (F-series) have been freezing up since 10.0
every now and then when the cursor leaves the dialog window.
About 6 seconds later the screen blinks out, comes back,
and the input buffer (which by now has overflowed) starts
spitting mouse and keyboard events all over the place.
3) Why do my black and white dn3000s feel faster than my
F-series 4500s, and why does everybody at APOLLO look at me
funny when I say so. I'm not crazy... I'm not... get away from
me... I hate nets... I hate em...
4) Why does tone_$time(1000) crash the node. I know it's a bug,
but gee that's kind of harsh.
5) Why does GPR exit full-screen mode when you hit control-Q
even though you have those signals ignored. The only way I've
found to do this is with the now unsupported
smd_$set_quit_char(0, status);
- I think I tried removing it from the gpr_enable_input keyset
with no luck but I wouldn't swear to it.
- I haven't tried zeroing ISIG on the tty IOCTL TCSETA command,
but I'm not hopefull.
6) This little man showed up at work and told me that we don't like
Apollo's Token ring anymore and that ethernet is gobs better.
He had such a pleasant smile but gosh I just don't know. Does
anybody out there have a probelm with this ?
7) All that time I spent wearing down my management to get me a
DN10K and to tell it straight, I just don't want it anymore.
The only power machine I want now is the one that comes with
a future support upgrade/enhancement plan signed in blood by
Mr. Packard. Throw in a money back gaurantee and I may be
willing to forgo the driver's side airbag
8) Why does my head hurt so much when I look through the release
notes. And where does it mention in the 10.3 notes anything
about the new timed supplied to synchronize node clocks.
9) I know the IOCTL stuff will allow you to simulate input to a
tty but is there any way to do the same thing to a gpr event
wait ?
A) Is there any way to change the text displayed in the window frame,
once the window has been created ?
B) How cum some people seem to know how to use unsupported and
undocumented apollo commands ? Did they use to work for Apollo ?
Do they reverse engineer the stuff or use the debugger ? Are they
just good guessers ? Anybody care to share a method,list,or insight ?
C) Ever notice how all the usefull facilities end up in
/systest/ssr_util ? Whom do I have to kill to get the source code
to those things ?
D) Isn't the pad_$dm_cmd call a major security hole considering CRPs ?
E) To any AEGIS die-hards. Just stop it. I know it's hard but think
about your families. "AEGIS guru" just doesn't work on a Resume'.
- awk grep yacc, sure but where's thhwwppsttt...
P.S. Please respond here or to ruben@dsp35001.boeing.com . More
interested in answers to the technical questions but feel free
to let me know if I'm full of spit on the other points too.
---------------------------------------------------------------------
Disclaimer: All of the above was written by my evil twin who is
slightly deranged and should not be taken too seriously.
No major Aerospace company beginning with a 'B' has
anything to do with the opinions voiced herein.thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (06/05/91)
> 1) At the ADUS conference in New Orleans, the first after > Apollo became HP/Apollo, the subject of doing away with > AEGIS came up. The uproar was quite significant. > ... > AHA. Eets Ze old if they want the new stuff, they can't > have support for the old stuff ploy. Whatever happened to good > old buzzwords like "upgrade path". Maybe I'm just nachully > too suspicious but time will tell if we've sold the cow for > a handfull of rotted beans. A couple thoughts on this. First, when there was an uproar in New Orleans, it would have been 2 years ago. Times change, and so do we. I remember everybody gasping over the changes to Aegis brought about by sr10. Now, only a few engineers here complain about Aegis's "death." (It should be noted that Aegis _did_ die at sr10 -- this new stuff is too close to JLRU to be _real_ Aegis. :-) However, I think you're a little hard on HP/Apollo (me?!? Say that?!? <gasp>) in this case. Except for the DN10000 / Snake boxes, HP/Apollo seems to be charting a reasonable transition to OSF/1. It's just us poor little rich kids who have DN10Ks, or who want the new hardware (silly us) that have transition woes. Anyone who can wait 1 1/2 years before going to new hardware can transition at a leisurely pace. (I figure there are about 3 people who fit that description.) :-( > Will HP/Apollo at least offer documentation for suggested > OSF alternatives to DOMAIN/OS sytem calls where applicable ? As I understand it, OSF/1 will come with "a _Lint_ _tool_ with user selectable databases ... to assist customers in transitioning these applications. This tool will scan source code for specified system calls, taken from an input database. Upon finding a match, it will look up ... the appropriate replacement call.... For example, ... for Aegis calls, then refer to ... the suggested XPG3 call." They plan database sets for "[Aegis|Berkely|SysV] --> XPG3," "SOCKETS --> Streams," "Remaining OS Calls --> Standards," "K&R C --> ANSI C." (from the Domain/OS and HP OSF/1: Interoperability and Operating System Evolution paper.) Now, reading is not believing. I'm definitely from Missouri on this one, so you'll have to show me. I'd love to see their suggestions for mbx_$xxx, task_$xxx, aclm_$xxx, pad_$xxx, and pbufs_$xxx calls. Also, it should be noted that we're supposed to use standard Unix calls when possible, but we aren't supposed to use Unix calls with tasking programs (Domain/OS Call Reference, Vol II, page TASK-4). We have found that many Unix calls aren't reentrant (betcha didn't know that even strcpy can give grief). > 6) This little man showed up at work and told me that we don't like > Apollo's Token ring anymore and that ethernet is gobs better. > He had such a pleasant smile but gosh I just don't know. Does > anybody out there have a probelm with this ? HP/Apollo has promised ("cross our hearts and hope you die, if what we say becomes a lie") to support ATR on the Snakes with OSF. Now, how long they keep the support going is still questionable.... > B) How cum some people seem to know how to use unsupported and > undocumented apollo commands ? Did they use to work for Apollo ? > Do they reverse engineer the stuff or use the debugger ? Are they > just good guessers ? Anybody care to share a method,list,or insight ? We do lots of poking around, use the debugger, use 'bind' to find a list of globals, pray a lot, and crash nodes. There are also people who have some unreleased calls, but I wouldn't name names, even if I knew them.... > C) Ever notice how all the usefull facilities end up in > /systest/ssr_util ? Whom do I have to kill to get the source code > to those things ? See <B> above. These are even worse. I wouldn't expect HP/Apollo to release source in any case. Just getting some of the progs supported would be accomplishment enough. (Does anyone _NOT_ use lsyserr???) > D) Isn't the pad_$dm_cmd call a major security hole considering CRPs ? I haven't tried it, but I suspect it isn't too bad anymore. At sr10, the DM started checking out who was making the call, and who was running the display_manager. That's why you can't run xdmc and toast people on remote nodes without some extra work (and/or root privileges). -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com When in danger, when in doubt -- run in circles, scream and shout.
dennis@nosc.mil (Dennis Cottel) (06/06/91)
John Thompson asks:
> Does anyone _NOT_ use lsyserr?
This rang a bell for me, so just for fun I looked up the details.
Some time ago, I was trying to write a system watching program that
would determine when the last error on a node took place and what the
error was. Because of the format of the lsyserr output, it takes some
contortions even with Perl to figure this out. In June 1988 I sent in
an APR asking that the output of lsyserr be made more compatible with
automated scanning. In June of 1989 I got a reply stating "this has
already been answered and was stamped 'to impl' for SR11".
I'm still waiting... ;-)
Dennis Cottel, dennis@NOSC.MIL, (619) 553-1645
Naval Ocean Systems Center, San Diego, CA 92152rees@pisa.citi.umich.edu (Jim Rees) (06/06/91)
In article <912@bcstec.boeing.com>, ruben@bcstec.boeing.com (Reuben Wachtfogel) writes:
Apollo Miscellany
Glad to see the folks at the Lazy-B Ranch (one of my many ex-employers, and
the place where I first encountered Unix, in 1977) still have a sense of
humor.
3) Why do my black and white dn3000s feel faster than my
F-series 4500s...
Why does my dn330 feel faster than my dn3500? Maybe it's because I run
sr9.7 on my dn330.
6) This little man showed up at work and told me that we don't like
Apollo's Token ring anymore and that ethernet is gobs better.
He had such a pleasant smile but gosh I just don't know. Does
anybody out there have a probelm with this ?
I sure do. NACKs are so much nicer than timeouts when nodes or routers go
bad. Besides which, it's (in general) impossible to boot diskless on an
ethernet, unless the ethernet is only used by Apollo nodes, and even then
it's a problem. The bug is that netboot seems to be unable to discard
packets intended for that node but not of the proper type (say, xntp peer
packets when it's expecting bits of Domain/OS). There are other theoretical
differences, but these are the ones I notice every day.
B) How cum some people seem to know how to use unsupported and
undocumented apollo commands ? Did they use to work for Apollo ?
Do they reverse engineer the stuff or use the debugger ? Are they
just good guessers ? Anybody care to share a method,list,or insight ?
I've been meaning to write up something about this. I used to work for
Apollo, and I have access to source code. But if I had none of these
advantages, I would proceed as follows:
1. Write a program (call it "syscall") that takes the name of a system
call, looks up its entry address in the KGT (using kg_$lookup), then
interactively reads a list of arguments, makes the call, and prints out any
args that have changed.
2. Run "nm" on the contents of /com and /systest/ssr_util to find
interesting system calls. Run "nm" on /lib/pmlib for a list of all system
calls (and lots of good library calls, too).
3. Run "syscall" on the calls revealed in 2. Experiment. Crash your node.
Have fun. Learn something.
C) Ever notice how all the usefull facilities end up in
/systest/ssr_util ? Whom do I have to kill to get the source code
to those things ?
Bring me the broomstick of the Wicked Witch of the West... I don't think
you get this even with a source license.krowitz@RICHTER.MIT.EDU (David Krowitz) (06/06/91)
Well, last I heard, Sr11 had been renamed to SR10.4 (to emphasize that it would *not* be an SR9.7==>Sr10.0 sort of transition), which would be released this fall or winter. There goes my prediction that SR11 would be out by the end of this year ... maybe you'll get your wish by Christmas. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
bag@tech.perpk.nt.com (Bill Gutknecht) (06/06/91)
I believe that they did the SR11 -> SR10.4 thing so that SR9.7 would not be 2 major revisions old (and therefore would not be supported). I could be wrong ... Bill
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/07/91)
Nah, they said outright that the name change was for reasons of perception. They wanted to stress that any conflicts between SR10.3 and POSIX would be resolved in favor of SR10.3. (this was at the ADUS sys-admin SIG meeting in Orlando). == Dave
edwill@ariel.lerc.nasa.gov (Glenn L. Williams) (06/07/91)
In article <dennis.676156123@woodstock>, dennis@nosc.mil (Dennis Cottel) writes... >John Thompson asks: >> Does anyone _NOT_ use lsyserr? > >This rang a bell for me, so just for fun I looked up the details. > >Some time ago, I was trying to write a system watching program that >would determine when the last error on a node took place and what the >error was. Because of the format of the lsyserr output, it takes some >contortions even with Perl to figure this out. In June 1988 I sent in >an APR asking that the output of lsyserr be made more compatible with >automated scanning. In June of 1989 I got a reply stating "this has >already been answered and was stamped 'to impl' for SR11". > >I'm still waiting... ;-) > > Dennis Cottel, dennis@NOSC.MIL, (619) 553-1645 > Naval Ocean Systems Center, San Diego, CA 92152 Try using grep (either BSD4.3 or SYSV.3) and pipe into it the output of lsyserr, then search for the text you want using the grep parameters. You can even do this from AEGIS (using /bin/grep).
smv@apollo.HP.COM (Steve Valentine) (06/08/91)
In article <9106061857.AA10627@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >Nah, they said outright that the name change was for >reasons of perception. They wanted to stress that any >conflicts between SR10.3 and POSIX would be resolved >in favor of SR10.3. (this was at the ADUS sys-admin >SIG meeting in Orlando). Let me nip this one in the bud. Conflicts between SR10.3 and POSIX (and other standards) will be resolved in favor of SR10.3 only in the default compilation mode. If you build in -ansi mode, with _POSIX_SOURCE defined, you'll get the differences resolved in favor of POSIX.1-1990. We want to make it easy to: a) Just recompile existing "non-standard" programs. b) Compile standard conforming programs. In order to implement the standards correctly, we have to break some existing behavior. For example, to implement ANSI C correctly at sr10.3, we had to make the <stdio.h> stop using '_iob' because that's a symbol that is reserved to the implementation. We changed it to use '__iob' instead, but this means that programs compiled in the strict ANSI C environment at SR10.3 won't run on older SR's, because they don't provide '__iob'. The solution was to bend the standards in the default compilation environment (-xansi), while providing strict adherence to the standards in a controlled environment (-ansi). Similar niggling little changes like this will be required to implement POSIX.1-1990 to the letter of the standard. We figure that most people will care more about being able to build programs on SR10.4 nodes that will run on SR10.3 nodes than will care about these little corners of the standards. However we do plan to provide a compilation and execution environment at SR10.4 which will comply fully with POSIX.1-1990, no if's and's but's or weasle words necessary. Now, having said that, I do have to add the weasle words to THIS message, and say that I'm not speaking for HP/Apollo and these are my words not theirs, etc. -- Steve Valentine - smv@apollo.hp.com Hewlett-Packard Company, Apollo Systems Division, Chelmsford, MA Hermits have no peer pressure. -Steven Wright