Sun-Spots Digest, v6n37

William LeFebvre Sun-Spots-Request at RICE.EDU
Sun Mar 27 15:44:35 AEST 1988


SUN-SPOTS DIGEST        Wednesday, 23 March 1988       Volume 6 : Issue 37

Today's Topics:
                  Re: Questions about 256 entry colormap
                         Re: Sun 4 info requested
                          Re: Stuck in caps lock
                       Re: Block Diagrams in troff
                SouthEastern Michigan Sun Local User Group
                     IP options crash our Sun gateway
                    leap year clock problem revisited
                      Changes in user mail interface
                   Bug(s) in library routine innetgr()
                 Help sources TCP / ditroff / transcript
                    Fig: is there a f2tex or f2latex?
                 SUN <=> APOLLO cartridge tape exchange?

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
    TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are stored on "titan.rice.edu".  For volume X, issue Y,
"get sun-spots/vXnY".  They are also accessible through the archive
server:  mail the word "help" to "archive-server at rice.edu".

----------------------------------------------------------------------

Date:    Tue, 15 Mar 88 11:04:33 EST
From:    warsaw at cme-durer.arpa (Barry A. Warsaw)
Subject: Re: Questions about 256 entry colormap
Reference: v6n25

Using the colormap segment stuff is tricky.  Things have to be done in the
right order or you don't get what you want.  I've done a lot of hacking on
the color stuff and most of what I describe below is the result of
extensive experimentation (my sun manuals just don't go into heavy
detail).  I wrote a library of color routines to sit on top of sunview's
cmseg stuff that I feel is a cleaner and more robust interface and I've
written an interactive color editor to utilize this library.  I'm now
working on a more robust version of this editor.

You *can* get panels and frames, etc. to use the colormap for a canvas.
This is how I do it:

1) build all the window structures that you want to use.
	a) window_create the base frame
	b) window_create the canvas and panels BUT don't draw to the
		canvas yet
	c) populate the panel with panel items
	d) be sure not to call window_main_loop or make your windows
		visible yet

2) Now that you have all the subwindows and panel items set up and
	positioned the way you want them, retrieve all the pixwins of the
	windows that will use your 256 slot map.
	a) use canvas_pixwin for canvases
		eg: pwc = canvas_pixwin(canvas);
	b) use window_get for other windows
		eg: pwf = (Pixwin *) window_get(base_frame, WIN_PIXWIN, 0);
		    pwp = (Pixwin *) window_get(panel, WIN_PIXWIN, 0);

3) Now build your colormap by populating the red, green and blue
	arrays with your rgb triplets.

4) Then for EACH canvas, frame, panel, etc. that will have your custom
	colormap, I do the following:
	a) pw_setcmsname(pw, map_name);
	b) pw_putcolormap(pw, 0, 256, r, g, b);

5) All pixwins that you've applied step 4 to will now be truly 8 bits
	deep with the associated 256 slot colormap.  So you can now draw
	to your canvas.  Also when you call window_main_loop and sunview
	automatically draws your panels, they will be drawn in 8 bits, using
	your colormap.

Note that each time you change the colormap, you've got to perform step 4
(I call it 'downloading' the colormap) for each pixwin so that they will
use the new colormap.

There are a few bizarre things to note about this.  First, you've got to
be careful about how you assign foreground and background, especially if
you're mixing color and monochrome windows (or if you want to be able to
see non-active windows and panels when the colormap "flashes").

Sunview really uses 3 slots to handle grounds, slot 255 is always the
foreground for panels.  For active windows (ie: those that use your custom
colormap), background is slot 254 (or n-2 for an n slot colormap).  For
passive windows (sunview sets the colormap), background is slot 0.  On my
new color editor I have an option to select which grounds are visible:
none, active, passive or both.

You also need to note that there is a safety "feature" of colormap
segments which will not allow you to set slot 0 and slot 255 to the same
rgb triplet.  If you do, sunview overrides your triplets and sticks black
and white into these slots.  I vigorously disagree with this mentality
since I figure if I wanted to set s0 and s255 to the same value I must
have had a reason.  Of course this makes reading the screen difficult at
times, still...  Anyway, my color library defeats this "feature" by
tweeking one of the rgb triplets by 1 in the red componant, a totally
imperceptable tweek.

Note that all this work was done on a 3/160.  I've run my color editor on
a 3/110 and I know it works, but I'm not up on the effects of the extra
planes to the colormap segments and how passive panels get painted.  We
don't have any 3/60's so I can't comment on their performance.

Also, its much more difficult to get sunview to draw panel items in any
pixel value other than foreground.  I've never got that to work but at
least the above method won't cause your canvas to "flash" when you move
the cursor into an adjacent panel.

I hope this helps.

NAME:   Barry A. Warsaw                 TELE: (301) 975-3460
USMAIL: National Bureau of Standards    ARPA: warsaw at cme-durer.arpa
        Rm. B-124, Bldg. 220            UUCP: {...}!uunet!cme-durer!warsaw
        Gaithersburg, MD  20899

------------------------------

Date:    Tue, 15 Mar 88 16:25:19 EST
From:    weltyc at nisc.nyser.net (Christopher A. Welty)
Subject: Re: Sun 4 info requested
Reference: v6n25

>From:    wucs1!wucs2!krf at uunet.uu.net (Kevin Fenster)
>We are replacing a number of Vax 11/750s starting this summer, and are
>looking at various machines to put in their place.  One of the machines
>which we are looking at is...the Sun 4/280 Server.....

We were in a similar situation last year, and decided to replace our
4.3BSD Vax 11/780 with a SUN-4.  Oh how enthusiastic our Sun reps were
about such a proposition!  Quite clearly did we explain the function of
our Vax as a central mail/networking/terminal/computing machine to Sun,
and quite positively did they state that the SUN 4 would blow the Vax
away.  However, it wasn't until after we had signed the deal, that we
began to learn things about the Sun4 that sounded shady.  More than shady,
we had been blatently lied to.

US: "We MUST convert this Christmas, this is a school and we need to be at
full operation when classes resume after xmas break, remember this is to
be our central machine"

SUN: "No problem, we'll ship it late december" --- SUN4 delivered February 10.

US: "We must be able to use this as our central mail/network server,
	we are a major node in an Internet Style Network (NYSERNET),
	remember this is to be our central machine"

SUN: "No problem, you already have many suns running in your
	environment, see how well they work" --- On February 11th we
	learn SUN4s only run OS3.2, WHICH DOES NOT SUPPORT SUBNETTING
	(among other things).

US: "Our Vax has 56 terminal lines, we MUST have at least 32 to support
	our people, remember this is to be our central machine"

SUN: "No problem, we'll give you 2 ALM2s" -- On March 10th after
	speaking to a higher level person in the sales hierarchy
	1 of our ALM-2s arrived.  We are still awaiting the other.
	There have even been rumors that the ALM-2 doesn't work right
	with the SUN4 (as yet unconfirmed by us, but we haven't
	connected the one ALM-2 up yet).

US: "OK, if your sure this will al work out, we're going to make a
	deal to sell our Vax to one of those DEC junkyards"

SUN: "No problem" --- well, luckily we didn't actually sell our Vax
	yet, and it looks like we'll be keeping it a while longer,
 	looks like we lost some deals, though...

The moral of this story is get it all in writing.  If SUN promises you
something that you feel is important, make sure you COMMIT them to saying
"if you don't get it when you need it we'll give it to you for free" or
something like that.  Make them stand by their word, because they clearly
won't by themselves.

Also I just heard (not confirmed) that Apollo is offering a new machine
that blows the Sun4 away...

Christopher Welty  ---  Asst. Director, RPI CS Labs
weltyc at cs.rpi.edu       ...!rutgers!nysernic!weltyc

------------------------------

Date:    Mon, 14 Mar 88 17:39:48 PST
From:    cvbnet!cvedc!opus!markh at sun.com (Mark Holm)
Subject: Re: Stuck in caps lock

Another thing that can cause this is the support left in for the old ADM
terminals.  If the caps lock is on when you login, then all keys get
mapped to upper case characters with real uppercase characters having a
"\" before them (ie. Hi => \HI). The way to turn this off is to type (in
your root window) "stty -lcase".

Mark Holm       		..tektronix!ogcvax!cvedc!mholm
Computervision                  ..sun!cvbnet!cvedc!mholm
14952 NW Greenbrier Parkway     Phone (503)645-2410
Beaverton, Oregon 97006         FAX   (503)645-4734

------------------------------

Date:    Tue, 15 Mar 88 22:11:34 EST
From:    ted at braggvax.arpa
Subject: Re: Block Diagrams in troff

Pic does exactly this, and the recent fig program lets you draw
interactively and generate pic output.  

Unfortunately, Sun does not distribute pic with SunOS, and to work with
the Sun supplied old (CAT) troff, you need an old pic (it uses
pointilism.. (sp?)).

[[ Sun does not distribute pic with SunOS because they do not have a
license to do so.  Pic is not part of System V, nor is it part of BSD.  It
comes with the device-independent troff package from AT&T and also with
documenter's workbench.  Last time I checked, it was licensed *separately*
from Unix.  --wnl ]]

Ted Nolan
ted at braggvax.arpa

------------------------------

Date:    Wed, 16 Mar 88 10:24:30 EST
From:    dwon!lokkur!scs at citi.umich.edu (Steve Simmons)
Subject: SouthEastern Michigan Sun Local User Group

The SouthEastern Michigan Sun Local Users Group (SEMiSLUG) has been
meeting for a year now on the second Thursday of every month.  Most
meetings are at Schlumberger CAD/CAM, 4251 Plymouth Road, Ann Arbor, MI,
48104.  The April 14 meeting will be at the Industrial Technology
Institute, 2901 Hubbard, Ann Arbor, MI. 48109.

SEMiSLUG meets jointly with the Michigan USENIX chapter.  At the meting we
try to have one brief presentation for each group, then things break up
into discussion groups (listed as "rumors and innuendo" on the agenda).
Attendance has been running 30 to 40 people, split about 50-50 between mid
level and high level technical folks.

To be added to our mailing list, send to
	semislug-request at lokkur.uucp

If you have questions, feel free to call me at 313-995-6366.

Steve Simmons
scs at lokkur.uucp

------------------------------

Date:    Tue, 15 Mar 88 13:52:37 EST
From:    oconnor at sccgate.scc.com (Michael J. O'Connor)
Subject: IP options crash our Sun gateway

When our stock SMI DDN gateway attempted to forward IP-grams containing RR
or LSRR options, it would crash.  Our box is a 3/260 running SOS 3.5 and
acts as a gateway between our local ethernet-based network and the
ARPANET.  We have only been able to test this behavior on outgoing
packets, but if we are correct in our diagnosis, the problem should occur
when the box attempts to forward any IP-option bearing packets in either
direction.

According to the engineer assigned to our service request, Sun has
assigned the problem bug number 1008944 but will not supply a fix for 3.n
SOS.  He stated that the problem should be fixed in 4.0 SOS which will be
distributed later in 1988.

Based on a report from Allison Mankin of MITRE, that the crashing is
caused by a previously reported typo in ip_stripoption(), I have patched
our binary in an attempt to reverse the effects of the typo.  The patch
has been working now for a little over 2 weeks.  Working in the sense that
our machine no longer crashes when forwarding IPgrams which contain
options.  I have yet to verify what is going out the other interface.

If anyone else is affected by this, and the legal boys allow it, I am
willing to supply the binary patch.  It only consists of modifying a
register value in 2 consecutive instructions.

			Mike

------------------------------

Date:    Tue, 15 Mar 88 20:06:03 est
From:    umix!oxtrap!rich at rutgers.edu (K. Richard Magill)
Subject: leap year clock problem revisited

Hold on to those leap year bug patches, you'll need them when/if you
upgrade to 3.5! 4.0? 5.0? 6.0?  (mine having been long since thrown away).
grumble, grumble.

------------------------------

Date:    16 Mar 88 07:26:09 GMT
From:    woods at handies.ucar.edu (Greg Woods)
Subject: Changes in user mail interface

I have noted that Sun has decided to reverse the sense of the 'R' and 'r'
commands in /usr/ucb/Mail, at least on a Sun-4 running Sun-OS Sys4-3.2. I
wonder why they did this. It has broken a couple of well-ingrained
personal habits and even some shell scripts. 

For those who have no idea what I'm talking about :-) , I'm referring to
sending replies while reading mail, and on most 4.xBSD systems, 'r'
replies to the sender and everyone else who got the original message, but
'R' replies to the sender only. On the Sun, 'r' sends only to the sender
and 'R' sends to everyone.

Why did they change this, and has anyone done what I'm thinking of doing:
spending some time looking for a way to change it back to the way it was
(and the way all our users are used to), without available sources, using
adb(1) or some other tool on a binary-only system?

--Greg

------------------------------

Date:    Wed, 16 Mar 88 15:57:17 +0100
From:    steinar at ifi.uio.no
Subject: Bug(s) in library routine innetgr()

This bug report applies to SunOS 3.4:

In Sun-Spots v6n26  Michael Eldredge reported a bug in rpc.yppasswdd.
Almost the same bug (but even more serious) can be found in the library
routine innetgr(3N). 

The routine performs lookups in the "netgroup" YP map by calling a local
routine doit(grp) which in turn calls itself recursively if necessary. The
bugs are all located in this routine.

After having located a (host,user,domain) triplet, doit() does the
following test:

	if (strncmp(name,p,q-p) == 0)
	  match++;

Above, "name" points to the "user" parameter for innetgr(), "p" points to
the beginning of the user-portion of the triplet and "q" points to the end
of this field.

Obviously, this test checks for subtext matching only - not full string
comparision. So, imagine user "foo" being member of netgroup "bar" and
user "foobar" being member of group "baz".  The call ..

	innetgr("bar","-","foobar",domain)

will return TRUE(1) instead of FALSE(0).

The correct if-test is obvious and may be written in several ways, do it
in whatever way you like!

Also, note that the same if-test is done when the routine looks for a
match of "machine" and "domain".

Remember that innetgr() is part of the standard C-library, libc.a, which
usually sits on the /pub nd-partition on nd client machines. Shut down
your clients  if you intend to patch the libc.a on the server!

Steinar Kjaernsroed,
Institute of Informatics,
University of Oslo,
Pobox 1080, Blindern
0316 Oslo 3
N O R W A Y

email: steinar at ifi.uio.no

------------------------------

Date:    Wed, 16 Mar 88 02:55:41 PST
From:    tsunami!nswed5!efb at sun.com
Subject: Help sources TCP / ditroff / transcript

Looking for legal, obtainable sources for System V and Sun/BSD for ditroff
/ transcript / TCP and UDP tools .. please, help ... clues.  Hold 5.3
Source

Everett F. Batey II          UUCP:  sun!tsunami!nswed5!efb
USNSWSES - Code 4V33         ARPA:  efbatey at NOBBS.UCSB.EDU
Blg 1214                     DDD:   805/982-5881
Port Hueneme,CA  93043-5007

------------------------------

Date:    Wed, 16 Mar 88 13:17:24 GMT
From:    Colin Walls <colin at polaris.central-services.umist.ac.uk>
Subject: Fig: is there a f2tex or f2latex?

I have just retrieved Fig from the archive. My difficulty is the filter
supplied (f2p) is for pic. Does anyone have a suitable filter for TeX or
LaTeX. If so could they mail it to me.

Colin Walls (Colin at umist.ac.uk)

------------------------------

Date:    Wed, 16 Mar 88 00:00:50 MST
From:    sf at lanl.gov (Steve Finn)
Subject: SUN <=> APOLLO cartridge tape exchange?

I would like to exchange data between an Apollo DN3010 and a SUN 3/60 each
of which has a cartridge tape drive. Thus far I have tried DD and TAR
without success. The SUN is using SUN OS 3.2 and the APOLLO uses AEGIS
9.7-DOMAIN/IX 9.5 

Any hints would be appreciated.

Please reply to me at 600213 at lanl.gov

Thanks

Steve Finn

------------------------------

End of SUN-Spots Digest
***********************



More information about the Comp.sys.sun mailing list