Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) Newsgroups: comp.sys.apollo Subject: re: Apollo Miscellany Message-ID: <9106051253.AA01516@pan.ssec.honeywell.com> Date: 5 Jun 91 12:53:22 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The Internet Lines: 84 > 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?!? ) 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 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.