[mod.computers.sun] SUN-Spots Digest, v3n9

Sun-Spots-Request@RICE.EDU (Scott Alexander) (11/02/85)

SUN-SPOTS DIGEST              Friday, 1 Nov 1985           Volume 3 : Issue 9

Today's Topics:
				Re: LCF memory
		 vi across Ethernet, login server, LCF vs LMI
			  weird window sizes on SUN
			Need 'ypchsh' (like yppasswd)
				  bad blocks
			non-SMI disks and controllers
			    SUN RPC source and NFS
			   Tape controller query...
		   Bug with long lines and ptys in Sun 1.4
			    cgi_pw and vdc_extent
       Frame Grabber Boards for SUN Micro, Color Compression Techniques
				configurations
				REDUCE on SUN?
		     How to set up extra pixwin clipping?

------------------------------------------------------------------------
From: Deutsch.pa@Xerox.ARPA
Date: 27 Sep 85 10:09:26 PDT
Subject: Re: LCF memory

Re the LCF 4 Mb memory boards for the Multibus Suns: a Xerox group
bought one and they are very, very happy with it.

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

Date: Sat, 28 Sep 85 15:13:04 edt
From: cbosgd.ATT.UUCP!mark@seismo.CSS.GOV (Mark Horton)
Subject: vi across Ethernet, login server, LCF vs LMI

	We have a random but frequent problem when using vi across our
	ethernet.  If we are rlogin'ed to one of our Suns and try to
	use vi, the window size is sometimes set incorrectly, so that a
	24-line terminal may appear to be 34 lines.

We haven't run into this problem here, but I can make a guess as to what's
happening.  The window size code in vi (and other programs that use curses,
termcap, or terminfo) at the lowest level (e.g. inside tgetnum("LI")) will
do the appropriate ioctl on stdout to see if it's a window, and if so, how
many lines and columns are in the window.  On a true Sun window, you're
really on a pty, say /dev/ttyp2.  Now, let's suppose that someone fires up
suntools on a 120 with several windows - the window manager will use another
ioctl from the master side to set /dev/ttyp2 to be 34x80.  Now, he shuts
down suntools (possibly abruptly) and the pty is freed up.  Later, someone
rlogins to the same 120 from over the net and happens to get ttyp2.  The
window size 34x80 is still stored in the pty, so vi will think it applies.

The proper way to handle this is when the last close is done on the pty
device, the window size is cleared out.  Perhaps Sun's implementation doesn't
do this, or perhaps the last close is being messed up somehow, or perhaps
some other process has the pty open so it isn't really the "last close".

With this information, you can probably reproduce the problem.  Write a
little program which uses the TIOCGSIZE ioctl to print the window size,
this will save you calling vi a lot.
	
	We are considering using a Sun 130 FS as a login server, with all it's
	serial lines talking at a Gandalf switch already in operation, and
	with people logging on remotely to the rest of our 4.2BSD systems.
	This let's our Vaxen stop answering (most) telephones and provides
	a load balancing facility for our phone in too. Any comments on the 
	scheme? Anything I'm overlooking - advice of the form ``Oh,
	a 2mB 130 would never handle 32 processes, or 32 pseudo terminals,
	or....  better get 4mB'' or  other goodies about Sun perfermonce.

Sounds like you want a TAC.  While the Sun 120 makes a fine TAC (we used
one as a TAC for awhile) it's awfully expensive.  Much more cost effective
is the CS/100T from Bridge Communications.  It costs about $6000 for a 14
port server which speaks both user and server TELNET (not rlogin, sorry.)
Other configurations exist: $4000 for 4 ports, $5000 for 10 ports, and
the CS/1T is a more flexible box which can hold up to 32 ports but costs
more per port (I think the base 8 port box costs $10000 and each additional
8 ports cost $2K.)  Bridge is in Mountain View somewhere.
	
	We just bought one of the LMI 4MB RAM boards you probably all got a
	flyer in the mail for.

Oops - I meant LCF, not LMI.  Sorry for the confusion.  I just got a call
from a guy at Sales One, and he says they just got an instruction sheet
for the board and would be sending me one.  I must have been confusing LCF
with the outfit that offers a Symmetric-box clone for the amazingly low
price of $20K (Symmetric sells them for $10K) and then in the fine print
they mention that the price is really $26K unless you qualify for the
Educational Discount rate of $20K.  This kind of misleading advertising
really turns me off.

	Mark

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

From: wallen@nprdc.arpa (Mark Wallen)
Date: 27 September 1985 0900-PDT (Friday)
Subject: weird window sizes on SUN

I read about your problem in Sun-Spots.  Here is the
answer (I can't believe that SUN  doesn't know about
it since we reported it over a year ago). 

First, sit at the console, open some windows and
size one of them to an odd size (i.e., not the default).
Now in that window, start a background job: say, sleep 3600 &
Do a 'tty' in that window and see which pseudo tty you have.
Exit that window.  In another window (don't open a new one)
or from another system, rlogin to your sun.  If you wind
up on the same pseudo tty as your window held before, vi
et all will think the window is whatever size you made it
earlier.  If you kill off the background process, log out
and rlog back in again, all will be well.  The problem, of
course, is that the background process keeps the pseudo tty
from closing and thus it retains it's notion of "window
size".  rlogin does nothing to change this notion (i.e.,
does not set it at all), so when vi and company start up
they assume (incorrectly) that the are running in a window.

Hope this helps,

Mark Wallen
UC San Diego

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

Date: Wed 30 Oct 85 15:14:17-EST
From: Ralph W. Hyre Jr. <Ralph.Hyre@C.CS.CMU.EDU>
Subject: Need 'ypchsh' (like yppasswd)

I'd like to provide the capability for users to change their login
shell.  The problem is chsh assumes the passwd file is on the local
machine, so I need an analog to yppasswd, which lets users change
their password in the yellow pages.

					- Ralph
-------
------------------------------

Date: Sun, 29 Sep 85 15:44:43 cdt
From: morris@convex.UUCP (Robert Morris)
Subject: bad blocks

Is there any way to forward bad blocks on SMD drives without
reformatting?

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

Date:     Sun, 29 Sep 85 23:03:10 MET
From: Jim McKie <mcvax!jim@seismo.CSS.GOV>
Subject:  non-SMI disks and controllers

We never bought any disks/controllers from SMI or their
agents here in The Netherlands, we buy direct from others
at realistic prices. We have had no trouble at all installing
our own Eagles and Fujitsu 80M drives on both the old
Interphase controller and the Xylogics 450.

Pity the rest of the SMI product we can't second-source is
so unreliable both in hardware and software.

Jim McKie	Centrum voor Wiskunde en Informatica, Amsterdam

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

Date: Tue 1 Oct 85 01:38:34-PDT
From: Heinz Muehlenbein <MUEHLEN@SRI-CSLA.ARPA>
Subject: SUN RPC source and NFS

I would like to get the SUN RPC source and the NFS source.
I am working in germany and there is'nt a sun sales representative
available.
thanks
-----------Heinz Muehlenbein
-------

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

Date: 2 Oct 85 18:34:31 EDT
From: Charles <MCGREW@RED.RUTGERS.EDU>
Subject: Tape controller query...

Hi,

   We are thinking of buying a tape controller for a Sun network file
server, and hooking it up to a Kennedy tridensity (6250 bpi) tape
drive (that we already own) to do backups.  One of our Sun sales reps
says that there might be interface problems with us doing this, and
suggests buying an entire system from them (controller + drive).

   My question:  will we have problems if we use the setup described
above?  Is anyone running the above configuration?

Thanks,

Charles
-------

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

Date: Thu, 3 Oct 85 09:52:26 edt
From: ted%bragg1@braggfs (Ted Nolan)
Subject: Bug with long lines and ptys in Sun 1.4

Description: Bug in handling very long lines in pseudo ttys found in Sun
	     release 1.4.

	     After typing about 253 characters in a window controlled by
	     a pty (or during a script(1) on the console) without hitting
	     a return, the pseudo terminal locks up completely.  If it is a
	     window, all you can do is quit it.  If it was a script on the
	     console, you will have to login from someplace else and kill 
	     it.  The proper thing for the software to do would be to
	     flash the "bell" on the pty as happens on the bare console
	     when the line length limit is reached.

Repeat By:   Get some naive users who think line wraparound is the same as
	     hitting return, or open a shell window and hold down a key
	     until it stops being echoed. Now try to do anything with the
	     window; you can't.

Fix:	     We're not a source site, but I can't recall any line length
	     lockups on the vax, so it shouldn't be too hard.

Comments:    Has anyone else seen this bug?  Is it gone in later Sun
	     releases?  Can we do anything about it?

From:	     Ted Nolan
	     SRI ADDCOMPE testbed 
	     Ft. Bragg NC
	     ted@braggfs

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

Subject: cgi_pw and vdc_extent
Date: 10 Oct 85 11:48:07 PDT (Thu)
From: Michal Young <young@UCI-ICSC.ARPA>


How does one change the vdc to device coordinate mapping when using the
cgi_pw (cgi and pixwins) package?  There does not seem to be a
cgi_vdc_extent function, which according to the SUN CGI manual means I
should use the normal vdc_extent function.  When I do so, vdc_extent returns
no error code but then I am unable to draw anything with cgi functions. The
cgi_pw stuff works fine in device coordinates when I comment out the call to
vdc_extent. Is there another function I should be using, or some
restrictions I am unaware of? 

--Michal Young, UC Irvine
  young@icsc.uci.edu  or young@uci or ucbvax!ucivax!young

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

Date: Tue, 15 Oct 85 00:01:37 EDT
From: Dan Blumenfeld <DAN@MIT-MC.ARPA>
Subject: Frame Grabber Boards for SUN Micro, Color Compression Techniques

Has anyone integrated frame grabber or imaging boards with a SUN Microsystems
2/160-C or 3/160-C Color Workstation?  Specifically, I'm interested in
learning what boards are available (e.g. Matrox, Datacube, ITI, etc.),
availability of device drivers, what people already have experience with,
and so on.

The application is capturing medium resolution (approx. 512 x 512) full-
color (24 bit) images of histological samples (i.e. photomicroscopy),
which will then be cropped and color-compressed to 512 x 384 x 6-8 planes.
I'm also curious as to what color compression algorithms and methods
exist to squeeze down a 24 bit color image to 6 or 8 planes.

Dan Blumenfeld
University of Pennsylvania
[blumen@wharton, dan@mit-mc]

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

From: Ralph Martin (on ICF GEC 4090 at Cardiff) <XACF03%geca.cardiff.ac.uk@ucl-cs.arpa>
Date:    Mon, 14 Oct 85 14:52 BST
Subject: configurations

We are thinking of getting something along the following lines:
A sun 2/160 ethernetted to a sun fileserver, with a multiplexer and about 12
vanilla vdus, for teaching students about graphics. The idea is that they
will do the development work on the FS machine, and then take it in turns to
have a go with the colour machine. (Where sun 3s may now be more appropriate
than sun 2s).
Has anyone out there got such a system, and if so, would they care to make
any remarks we may find useful, such as unanticipated problems, and
general impression of performance?
More generally, are many people out there using suns as essentially 
multi user machines (with more than, say 3 users at once) ? And if so,
are you using database software in such a configuration ?
Thanks in advance for anything you can tell me,
Ralph .

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

Date: Sun, 27 Oct 85 14:22:41 est
From: Ken Mandelberg <km%emory.csnet-relay.csnet@CSNET-RELAY.ARPA>
Subject: REDUCE on SUN?


Does anyone know of an implementation of the symbolic math package
REDUCE on a Sun?

Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322

{akgua,sb1,gatech,decvax}!emory!km   USENET
km@emory                      CSNET
km.emory@csnet-relay          ARPANET

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

Date: Tue, 15 Oct 85 02:51:29 edt
From: Stuart Friedberg  <stuart@rochester.arpa>
Subject: How to set up extra pixwin clipping?

I am trying to develop an graphic application under the SunWindow
environment.  The application is to manipulate and display a hierarchy
of rectangles within a tool subwindow.  The rectangles can have a
variety of graphic properties: various frames, transparent or opaque
covering pattern, transparent or opaque underlying pattern, labels and
so forth.  There is a display precedence on rectangles: parents obscure
children, younger siblings obscure older ones.

All this sounds very much like the SunWindow environment itself.  Why
not use SunWindows?  Because I want potentially hundreds of rectangles
and using a device for each one is unreasonable.  Also, the "top" and
"bottom" patterns require a different clipping/damage strategy than
SunWindows.

I have absolutely no interest in writing copies of all the pw_* display
routines to clip to my specifications.  The sensible thing to do is
have write some clipping set-up routines to install in pw_clipops and
use the normal pw_* display routines.  Unfortunately, there is
insufficient documentation to figure out how to write a routine
analogous to pw_exposed or pw_damaged.  (We do not yet have source)

By carefully going over the SunWindows programmers reference manual,
<sunwindow/win_ioctl.h>, <sunwindow/pixwin.h>, and so forth, I have
gotten a good notion of what has to be done.  Unfortunately, I can't
guess the exact proper use of the ioctls, or even if they're needed.

This is what I'd like to accomplish:  Get the normal exposed or damaged
rectlist from the system (via pw_exposed, etc), intersect it with a
rectlist that I supply, and then set up the clipping properly.  That
sounds pretty reasonable.  Now, how do I do it?  A detailed sketch of
one of the existing pw_exposed/pw_damaged routines would help a lot.

NOTE: I have a way to fake out the system that has been adequate for
demonstrating a preliminary version of the application, but I know
it is NOT correct.  I want to know how I am SUPPOSED to do this.

In the absence of specific help on how to accomplish this, I have some
specific questions that are not to be answered in the documentation.
Please remember what I want to do.  If you think I shouldn't have to
mess with things at the ioctl level, please feel free to suggest a
higher level of the system to tackle things.  I'd like to stay at the
pw_* level, myself.

1) pw_opsx/pw_opsy
  a) Who is responsible for setting these? pwo_lock or pwo_getclipping?
  b) What are they relative to? screen? window?
  c) What do they indicate? window origin? rectlist bounding rect origin?
  d) Do they depend on pwcd_state?

2) pw_opshandle
  a) Who is responsible for setting this? pwo_lock or pwo_getclipping?
       (I don't trust the manual on this point)
  b) Is it always the pixwin or the pw_pixrect?

2) WINGETDAMAGEDRL/WINGETEXPOSEDRL
  a) What are the preconditions on these ioctls?  WINLOCKSCREEN? WINLOCKDATA?
       What is the general sequence of ioctls needed to obtain the
       exposed or damaged rectlists?
  b) What fields of the struct winclip must be initialized and to what?
  c) How safely can &wc_block be treated as (struct rectlist *) ?  Must
       it be copied via rl_copy to a "real" rectlist immediately?  Is it safe
       to say "rl_free((struct rectlist *)&wc_block)" ?  Is it even
       true that the head (struct rectlist) of the list is at the start
       of wc_block?  Are the nodes (struct rectnode) stored consecutively
       after the head?  Are the pointers correctly set up or do they have
       to be "processed" somehow (block-relative, perhaps?) after the kernel
       fills in wc_block?
  d) Why would a WINGETEXPOSEDRL ioctl return -1 with errno equal to 27?
       (27 means "File too big")  It does this even if either of the
       two LOCK ioctls are tried beforehand.  (Release 1.2 on a 2/120)
       While "nonstandard" system calls sometimes leave junk in errno
       when returning normally, when giving an error condition the
       contents of errno are SUPPOSED to be meaningful.

3) rectlist id's
  a) Exactly when can/must the system be told to get rid of an id?
  b) Who is responsible for telling the system?
  c) Is a WINDAMAGEDONE ioctl the way to tell the system to get rid of
       a clipping/exposed reclist as well as a damaged rectlist?

4) pixwin_prlist
  a) Must a pwcd_prl always be supplied?  Can I leave it null?
  b) How should struct pixwin_prlist's be allocated? (malloc?)
  c) How should struct pixwin_prlist's be freed? (free?)
  d) Is there a handy routine to take a pw_pixrect and a pwcd_clipping
       and produce a pwcd_prl?

5) pw_prretained
     Who is responsible to creating/copying/freeing this? pwo_lock?
       pwo_getclipping?

6) pw_fixup
     Just who sets this up and who uses it?  Can I ignore it?  I know
       what it's intended for, but have seen no place it's ever used.

7) General
     Is there a handy routine to look at pwcd_clipping and do all the
       appropriate setup?

Knowledgeable responses eagerly awaited,

Stu Friedberg   {seismo, allegra}!rochester!stuart   stuart@rochester

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

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