Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!sdd.hp.com!usc!ucsd!ucbvax!HWCAE.CFSAT.HONEYWELL.COM!rand From: rand@HWCAE.CFSAT.HONEYWELL.COM (Douglas K. Rand) Newsgroups: comp.sys.apollo Subject: SR10.3 (long) Message-ID: <9011232353.AA19553@hwcae.cfsat.honeywell.com> Date: 23 Nov 90 23:53:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 153 Well, around the end of October (the listing of /, reports that the creation time was October 23, 1990), I volunteered to be the guinea pig for SR10.3. Since then I have learned a few things. The biggest gotchas is color maps. At 10.3 HP/Apollo tried to make the DM polite in dealing with the color map. There is a new feature called ~/user_data/color_map. Just put a copy of your own color map in that file, and login. Or so the manual says. The DM does everything right. I load up a color map that prints all the text in this pukish orange (supposed to be amber); makes all of the pad backgrounds black (I hate that white); and loads up a nice set of paisely pad borders. Great. Everything works as advertised, except GNU Emacs (18.54 with Zubkoff mods). It prints all the text in black. And my pad backgrounds are black too. Oops. (How good a touch typist are you?) Got on the horn to HP/Apollo, and found out they are learning, just like me. They were helpful, and full of questions. This is not a flame. I guess this is what you get for being on the leading edge, you get cut sometimes. Turns out that when the DM reads ~/user_data/color_map it realizes that the color in slot 0 of your ~/user_data/color_map is the text color, and then loads that color in ANY color slot it chooses. All of the text is printed in the right color, but there is no way for a GPR program to figure out the color. Slot 0 is still black (the system default). And the old way (SR10.2 and previous) way to get the color of the text was via slot 0. Now for the solution. Login, and do a lcm -p ~/user_data/color_map. All of your colors will go screwy, but a CTRL-F will solve most of them. Now logout, and log back in. Things should work find till you reboot the node. (At least, they will work fine for your color map and you. If anybody else logs in, things will probably break again.) I asked HP/Apollo for a gpr call like gpr_$foreground to get the text color, and an APR is being written. So far, the only solutions are to use the LCM command. Or, create an option to pass to the GPR program to specify the color to use. I don't really like either, but the LCM is livable. The other thing I notices was rubber banding windows. I couldn't see the rubberbands over the black background of my pads. HP/Apollo finally reproduced the problem, and it turns out that my forcing the color map with the LCM call caused this problem. Here is how rubber banding was described to me by HP/Apollo. At 10.3, the index of the color of the pad border of the pad you are moving/resizing is xor'ed with the index of the color the rubber band is over. The new politeness of the DM causes all black regions of the screen to use a single entry in the color map. In my case it picked 7 (the text of the pad titles). Well here is a little binary math done in decimal: 9 xor 7 = 14 11 xor 7 = 12 13 xor 7 = 10 15 xor 7 = 8 7 being the index used to print the pad titles (and all of the pad backgrounds too, because they are all black). 9,11,13,15 are the indices for the pad borders (lovely shades of pastel) . 14,12,10,8 are the indices for the pad back grounds (all black). So, rubber banding over the pad backgrounds caused the rubber bands to be painted black. As advertised. My solution was to change the color for slot 7, to be a very dark shade of gray (1,1,1 rgb). That worked better. (An aside. There is a cool utility in /systest/ssr_util called color_probe. It draws the current color map in your pad. And you can point and clock on colors and it flashes them on the screen, and tells you the color.) Now on to more GPR stuff. I've got a stupid bar charting library that behaves a little like dspst. It uses auto refresh (gpr_$set_auto_refresh(TRUE,status)) instead of doing it myself. (I'm lazy, what can I say?) At SR10.3 there is a new undocumented feature for this. GPR creates a file in /tmp called gpr_autorefresh_ that is the bitmap for the entire screen. Well, it won't work if that file does not have the following privileges: u=rwx Yes, the x is very important. Our /tmp directories have (I believe) the default initial file ACLs: % llacl -L /tmp Object ACL: Network-wide access allowed Required entries: root.%.% prwx- %.staff.% -rwx- %.%.none -----I %.%.% -rwx- Extended entry mask: ----- Initial Directory ACL: Network-wide access allowed Required entries: rand.%.% ------UP %.none.% ------UP %.%.none -----I %.%.% ------U Extended entry mask: ----- Initial File ACL: Network-wide access allowed Required entries: rand.%.% ------UP %.none.% ------UP %.%.none -----I %.%.% ------U Extended entry mask: ----- Which uses the umask. And mine is of the paranoid school: 177. So my GPR autorefresh files had only rw. They needed rwx. My solution was to do a umask just before the gpr_$set_auto_refresh() call, and then set it back after. A better solution would be to have HP/Apollo change GPR to try to set the ACL of the file when they create it. They, after all, know what priviledges it requires. Now, for some TCP/IP stuff. Our tcpd was running with the -c switch, just like it should. But we couldn't transfer more than on the rough order of 128 bytes via either ftp or telnet. I'd get the login prompt (via telnet) and maybe the password prompt, and then it would say 'connection closed by foreign host'. Our solution was to add a -p0 option to tcpd. We never called HP/Apollo on this one, probably should though. So much for the complaints. The X performance is a lot better than before. The F monitor stuff is still kinda slow (I have a 4500, 16 Meg, a F monitor [1280x1024], ethernet and ring). (X on the new 400's is good. Almost great.) The new process limits are great. No more full tables. It seems a bit quicker, but that might just be my newly involed disk. (Who says Domain/OS never fragments!) All in all, it was pretty painless. Finally, ANSI compatible include files! Now I can get rid of my prototypes for malloc()! I'm waiting for CR1.0. Here is what is loaded on my node: C++ 2.0 C 6.7 (both m and mpx) DSEE 3.3.2 Pascal 8.7 (both m and mpx) TECHnet 1.1 (when is VMS post 5.1 support coming?) Thats all I can think of. Over all it was a very painless process. The advantages of 10.3 far out weigh the problems. (But you still gotta fix them!) I would be interested in hearing any thing else about 10.3. -- Douglas Keenan Rand Honeywell -- Air Transport Systems Division Phone: +1 602 869 2814 US Snail: P.O. Box 21111 Phoenix AZ 85036 Internet: @cim-vax.honeywell.com:rand@hwcae.cfsat.honeywell.com UUCP: ...!uunet!hpfce!apciphx!hwcae!rand