Sun-Spots-Request@RICE.EDU (Scott Alexander) (11/11/85)
This message is empty.
Sun-Spots-Request@RICE.EDU (Scott Alexander) (11/11/85)
SUN-SPOTS DIGEST Monday, 11 Nov 1985 Volume 3 : Issue 10 Today's Topics: Please for less digestification. (2) Mixing Sun-2's & Sun-3's; swap space; ascii terminals make 1/4 inch tape stream. Re: SUN RPC source and NFS Re: Bug with long lines and ptys in Sun 1.4 (2) Re: vi (and emacs and more...) across ethernet cms of a panel subwindow Is your Sun UNIX 2.0 network code flakey? ------------------------------------------------------------------------ Date: Mon, 11 Nov 85 13:44:56 CST From: Scott Alexander <sun-spots-request@rice.edu> Subject: digestification I received the next note shortly before the last digest. It suggests that less time between digests means more meaningful discussion. In reply, I claimed that if the intended plan of a digest every two weeks was met, this should not be a problem. My feeling has been that the volume has been reasonably high and that the factor which has slowed the frequency of digests has been constaints on my time. Mark suggested that I should open the question to comments from the list. Thus, send comments to sun-spots-request@rice.edu and I'll sort through them and summarize. Scott ----------------------------- Date: Thu, 31 Oct 85 16:06:54 est From: mark@markssun.cs.umd.edu (Mark Weiser) Subject: Please for less digestification. This list should NOT be digested. It takes forever for anything to appear because the volume of traffic is so low, and that discourages anyone from sending anything (I know it discourages me) and leads to a cycle of lower and lower activity. We are in it now. Sure, keep a person in the loop to screen out the crazy submissions, but let them go out a day later, one at a time, and lets have some more discussion! -mark ----------------------------- Date: Mon, 4 Nov 85 16:57:52 est From: allegra!phri!roy@seismo.CSS.GOV (Roy Smith) Subject: Mixing Sun-2's & Sun-3's; swap space; ascii terminals I'm looking into getting some Suns. We had originally planned on a 3/180 file server, a few 3/75 and 3/160's, and a lot of 2/50's (10-20). Much to my surprise, Sun says you can't mix Sun-2's and 3's! They can share a cable, but the 2's need a Sun-2 file server; likewise for the 3's. Why? If they all talk NFS and ND, what difference does it make who's at the other end? This may be a moot point; I'm told there will be a software upgrade out by 2/86 to allow mixing. Can somebody give me some hints on configuring the file server's disks(s)? As I understand it, each diskless node has to have a private, dedicated swap partition. To give each node 10 Mbytes of virtual memory (a reasonable figure?) I have to devote the better part of an Eagle to swap. This seems absurd, especially when you consider that most of it will be wasted most of the time. Is it really that hard to design a scheme to let several nodes can share one large swap partion? What about ascii terminals? We want to hang one off each diskless node to take some load off our 11/750 (which will run Mt. Xinu's NFS). Am I kidding myself by thinking the Sun-2 can be doing stuff on the console and have enough cpu left over to run a regular login on the serial port? Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 [For one of our projects here, we regularly hang one or two terminals of a Sun-2. We use the terminals for editing and the console for full screen sorts of things. It works fairly well. As you'd expect, if someone dbx's a 1/2M executable, it gets painful, etc. --dsa] ----------------------------- Date: Tue, 5 Nov 85 14:47:12 est To: sun-spots@rice.ARPA Subject: make 1/4 inch tape stream. I presume there is no way to do this on a sun/2? I have tried dd and tar with no luck. Do the sun/3's finally achieve this milestone? -makr ----------------------------- Date: Tue, 5 Nov 85 18:34:22 -0100 From: David Morton <dave%ecrcvax.UUCP%germany.csnet@CSNET-RELAY.ARPA> Subject: Re: SUN RPC source and NFS > SUN RPC source and NFS > >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 Oh yeah, I'm looking at the whites of their eyes everyday. There office is across the street from us. Try +(49) 89-416008-0 The address is Sun Microsystems GmbH, Arabellastr 30, 8000 Munich 81. Apologies if I sent this to the wrong place - we are having trouble mailing to arpa addresses. Dave Morton Tel. + (49) 89 - 92699 - 139 CSNET: dave%ecrcvax.uucp@germany.csnet UUCP: seismo!mcvax!unido!ecrcvax!dave Dave Morton Tel. + (49) 89 - 92699 - 139 CSNET: dave%ecrcvax.uucp@germany.csnet UUCP: seismo!mcvax!unido!ecrcvax!dave ----------------------------- Date: Sun, 3 Nov 85 22:37:37 cst From: oddjob!kaos!sra@lbl-csam (Scott Anderson) Subject: Re: Bug with long lines and ptys in Sun 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. I'm not sure if this constitutes a "fix", but in 2.0, when this happens, there is a second tool manager menu available labeled "TTY Hung?", with the single action "Flush Input". Selecting this, everything extra is flushed to the screen; nothing that was typed appears to be lost. Scott Anderson ihnp4!oddjob!kaos!sra ----------------------------- Date: Mon, 4 Nov 85 21:17:38 pst From: Greg Mclaughlin <greg%lccr.sfu.cdn%ubc.csnet@CSNET-RELAY.ARPA> Subject: Re: Bug with long lines and ptys in Sun 1.4 Ted, The bug still exists in Sun 2.0 and 2.1 releases (and will likely exist for a lot more releases to come). They have, however, give a solution in 2.0 and 2.1. They now detect when a pty is hung on tty input (this very problem) and give you a menu to clear the input (the menu shows up as a layered menu in the toolstripe --- 2.0 offers dynamic menues, buttons etc. in a manner of speaking). Clearing the input clears up the window with out having to kill it. Greg McLaughlin System Administrator/Analyst Computing Science Instructional Laboratory Simon Fraser University Burnaby, B.C. Canada V5A 1S6 greg%lccr.sfu.cdn@ubc.csnet@csnet-relay.arpa ----------------------------- Date: Sun, 3 Nov 85 22:27:15 cst From: oddjob!kaos!sra@lbl-csam (Scott Anderson) Subject: Re: vi (and emacs and more...) across ethernet Thanks to all who responded to my note about pseudo-terminal sizes. The prize goes to Mark Wallen (wallen@nprdc.arpa), who was the only one who really knew what our problem was: background jobs started off of a pty keep the window sizes from being reset; subsequent rlogins to this pty inherit this size, instead of the correct size. We run a lot of low- priority background simulations, which are often started up via rlogin, so you can imagine the mysterious nature of this bug (one day later, when the job ends, "suddenly" the pty is working again). I decided that the easiest thing to do for all of the users here is to modify tset (which we always use on logins anyway). Using the termcap entries for "co" and "li", the kernel's idea of the terminal size can be reset with the ioctl TIOCSSIZE. I put this in the routine "settabs", which is always called, and which already uses these termcap entries. This doesn't fix the problem with non-standard window sizes, which several people thought I was refering to. However, this could be fixed in the same way if you are running 2.0; just query the window for its size and then set the kernel appropriately. Cal Thixton wrote a program to do this; it is called rset, and it is on the Sun User Group distribution tape. Scott Anderson ihnp4!oddjob!kaos!sra ----------------------------- Date: Mon, 4 Nov 85 12:52:33 est From: andy@LASSPVAX.TN.CORNELL.EDU (Andy Pfiffer) Subject: cms of a panel subwindow We recently acquired a Sun-2/160C and have begun experimenting with the various libraries. Unfortunately, I have reached a point of frustration. HOW DO YOU CHANGE THE COLORMAP SEGMENT FOR A PANEL SUBWINDOW ??!! I have read, hunted, groped, and otherwise searched for an elusive pointer to a pixwin, but Sun Microsystems has thoughtfully decided that a "Panel" is an opaque type. I sure hope that I have overlooked something... I have created the tool with "WIN_DEFAULT_CMS, 1", changed the cms of the tool, created and changed the cms of a graphics subwindow inside the tool, created my panel subwindow, but I find no hint as to where the pointer for the pixin of the panel subwindow is. Please help me. Have I overlooked or misinterpreted something? I'd rather not write my own slider routines, but may be forced to if I can't change the cms of a panel subwindow. Complete source and details can be mailed to any kind soul wishing to help, but I'm hoping for a simple fix. Thanks. -- Andy ========================================================= USENET: {decvax,ihnp4,cmcl2,vax135}!cornell!andy%devvax ARPA: andy%devvax@Cornell.arpa MAIL: Theory Center/265 Olin Hall "What do you mean Cornell University I watch too much Ithaca, NY 14853 TV?" PHONE: (607) 256-8686 ========================================================= ----------------------------- Date: Mon, 4 Nov 85 15:23:11 pst From: fluke!jeff@uw-beaver.arpa Subject: Is your Sun UNIX 2.0 network code flakey? Folks, I've been running Sun UNIX release 2.0 for several months now, and I've begun to wonder whether some of the networking code might be broken. Specifically, I am being victimized by tcp connections which get broken abruptly, and simple library functions (e.g. gethostbyname()) which block for HOURS awaiting a reply from the Yellow Pages. The strange thing is that the system seems otherwise healthy. The vast majority of application programs work just fine. The Yellow Pages are up and running. No unexplained console messages. Servers happily serving to clients. Mostly life is wonderful, except .... I have a program which pushes many megabytes through a tcp connection to a remote process which writes the data to tape. The remote process may run for a minute, or it may run for half an hour, but it ultimately dies a horrid death when a read() from the tcp socket returns errno=ECONNRESET ("Connection reset by peer") while the writing process is zonked with SIGPIPE. Why, I ask? Just exactly who reset that connection? I sure didn't ask for it. (Point of scenic interest: the MTBF is inversely related to the load average on the receiving side, whether it is a Sun or a VAX.) Another example. We run a much-improved version of /usr/lib/lpd which is far more capable than the distributed version (e.g. it understands how to talk to port selectors). It's been running under every Sun UNIX release since that primordial UNISOFT V7 port that ran on 68000's (this was before the 68010...) But will it run under release 2.0? Noooooo. Same hardware, mind you. Same source. Same makefile. But now the daemons wedge in the damndest places. Like gethostbyname(). They can spend HOURS in that one, blocked on a recvfrom(). Meanwhile the Yellow Pages are up and *apparently* healthy. Hmmm... So am I the Only One In The World with problems like this? Anybody else? Wanna commiserate? Lessee, I've got reams of network packet traces to trade, make offer... Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064 {uw-beaver,decvax!microsoft,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff ----------------------------- End of SUN-Spots Digest ***********************