Sun-Spots-Request@Rice.edu (William LeFebvre) (11/07/88)
SUN-SPOTS DIGEST Saturday, 5 November 1988 Volume 7 : Issue 5 Today's Topics: Administrivia: the results of the poll Re: rlogin, csh, ^D Re: Better fix for NSTREAMS Re: Hardware Flow Control with MTI Re: 4.0/nfs bug followup Sunflower memory extension boards for 3/50 Sun and ksh method needed to get shelltool info 386i TeX problems Request for filter to magnify bitmaps 2X Using a Miniscribe 1335 with an Adaptec 4000 in a Sun 3/50? Sun 2, tell me about them NeXT vs. Sun Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Fri, 4 Nov 88 17:08:35 CST From: William LeFebvre <phil@Rice.edu> Subject: Administrivia: the results of the poll Well, I haven't gotten any new votes in a day or two, so I think it is time to declare the polls closed. The results are pretty much in line with what I expected. First, let us review the ballot (I will be referring to the letters and numbers in the totals, so we should redefine their meaning): Choices: A: Moderated and digestified B: Moderated but not digestified C: Unmoderated (and of course undigestified). Demographics: 1: Via Usenet (readnews, rn, notes) 2: Via Internet 3: Via Bitnet (Usenet readers got a slightly different version: I forgot to add the "Bitnet" choice to the demographics. I don't think that will cause any problems). I had to add a fourth choice, because certain people were not content with the first three: D: Unmoderated but digestified. First, the totals, broken down demographically: 1: 406 2: 143 3: 14 ?: 17 (none specified) 580 total votes 17/580 = .029, so this poll has a margin of error of no more than 3%. Looking at the total results (all demographic areas) shows no clear consensus (in all result tables, "Percentage" may not total 100% because of roundoff error): Votes Percentage A: 271 46.7 B: 238 41.0 C: 68 11.7 D: 3 00.5 The undigestify group (regardless of moderation) holds a slight edge: 52.7%. However, looking at the demographic breakdown reveals something very interesting. First, the Usenet readers' vote: Votes Percentage A: 129 31.77 B: 216 53.20 C: 60 14.78 D: 1 00.25 The undigestify group takes a definite edge here: 67.98%. Now let's look at the Internet readers' votes: Votes Percentage A: 120 83.92 B: 17 11.89 C: 4 02.80 D: 2 01.40 This is a very clear statement that the Internet readers want to retain the current format. As for Bitnet, all 14 people voted to keep the current format. Those that did not specify a demographic category voted as follows: Votes Percentage A: 8 47.6 B: 5 29.4 C: 4 23.5 So those votes really wouldn't change any of the results. I think the statement here is pretty clear. Usenet readers want to drop the digesti format for comp.sys.sun, which Internet readers want to keep the current format. A majority of the people are in favor of keeping the list moderated. So, I intend to undigestify the Usenet side of the list. Here is how I propose to do this. I will compose a digest just like I always have. I will choose the articles and the order, reformat and edit them (pruning quotes, removing extraneous header stuff, trimming signature blocks), forming a block of messages. I will run the articles through a program that will post each message individually to comp.sys.sun. Then I will build a digest package out of the block and mail that out to the addresses on the main list. And, hopefully, everyone will get what they want. This should take effect by November 15. Those of you on Usenet who still want to read the digested version of the list may request to be added back to the main list. You will then receive the digests via electronic mail. However, I would encourage you to try reading comp.sys.sun in its undigested form. You may end up liking it better. I would like to thank all those who participated in this survey. If you have any comments on the above proposal, please mail them to me. William LeFebvre <phil@Rice.edu> ------------------------------ Date: Thu, 27 Oct 88 10:41:13 MDT From: caeco!olyis!sol!jlp@cs.utah.edu (Jan L. Peterson) Subject: Re: rlogin, csh, ^D Reference: v6n257 In Sun-spots v6n257, dickson@shire.cs.psu.edu (Scott Dickson) writes: > Intermittently, when using rlogin to connect from one Sun to > another, the shell (/bin/csh) that is opened on the destination > machine will interepret any character that is typed as a > control-D. This leads to the problem of not being able to do > anything in that shell. This occurs when rlogin-ing from a > machine running SunOS 4.0 to another machine running 4.0. It > occurs only on our Sun 3/160's, but not on 3/50's, 3/60's, all of > which are clients of the 3/160. It also does not happen on a Sun > 4/260. This problem is intermittent at best, but when it occurs, > the only solution found so far is to reboot. We have had this problem here as well, between Sun-3/60s and a Sun-3/260 (all running SunOS 4.0). The problem seems to be related to ttys not being freed up when something exits. If you do a w(1), it will list the ttys used and the jobs running on them. Look for a job name of "-". This is a tty that doesn't really have a job attached. If you use the cleartty program (available somewhere, I forget where I got it) to clear that tty (it's probably the highest numbered pseudo tty), your problem will go away. Let me know if this helps. -jan- -- Jan L. Peterson UUCP: { ...!utah-cs!caeco | quad1 }!olyis!jlp Mail: Olympus Software, Inc.; 1333 E 9400 S; Sandy, UT 84093 (USA) Phone: +1 801 572 1610 ------------------------------ Date: Thu, 27 Oct 88 10:47:02 PDT From: auspex!guy@uunet.uu.net (Guy Harris) Subject: Re: Better fix for NSTREAMS 1) It should include "mti.h" as well, for ALM boards (NMCP is for ALM-2). 2) It should probably be 4*NZS (each port has two devices - one for dial-in and one for dial-out) and 33*NMCP (one dial-in, one dial-out per serial port - I assume the "17" is "16" for the serial ports and "1" for the parallel port), as well as 32*NMTI (one dial-in, one dial-out per serial port). Stream heads aren't that expensive, so allocating some extra ones isn't too bad. 3) The other ones are more complicated. The TTY driver tends not to use the big ones at all. 4-byte and 16-byte ones are used for input - 4-byte ones if input is coming in slowly, 16-byte ones if it's coming in faster. 64-byte ones are used for output when OPOST is set; if you do BMF writes when OPOST is clear, I think the stream head code will use BMF ones, and the message blocks just get passed down to the driver without being looked at or modified if OPOST is clear. It's not clear there's a straightforward formula for this. Using NIT would blow any such formula out of the water, anyway. Long term, both stream heads and streams buffers will probably be dynamically allocated. ------------------------------ Date: Thu, 27 Oct 88 13:17:34 PDT From: auspex!guy@uunet.uu.net (Guy Harris) Subject: Re: Hardware Flow Control with MTI >Now for the disclaimer: I've used this on a 3/180, under SunOS 3.0, 3.2, >3.4, and 3.5. I don't know what will happen under 4.0. The same thing that happened under all other releases. This really is *hardware* flow control; it's done by the *hardware*, namely, the Signetics 2661 EPCI chip (I may have the number wrong, I no longer have access to the manual). I don't know that Sun software can make it not work, since you can't tell the chip not to do it. I've never been sure what people are thinking of when they ask for "hardware flow control"; do they mean "flow control done by the hardware, rather than the computer to which the hardware is connected" or do they mean "flow control done out-of-band by RS-232 signals other than TxD and RxD, rather than done in-band with ^S/^Q or ETX/ACK or whatever"? If they mean the former, that's precisely unidirectional RTS/CTS flow control, so it's not surprising that it worked. The 2661 chip won't let you turn that *off*; the Zilog (AMD, really, I think) Z8530 chip used on Sun CPU/SCSI serial ports and MCP/ALM-2 lets you turn it on or off. Prior releases of SunOS generally didn't let you turn it on (turning it on also *requires* that you tie CD high, otherwise the receiver shuts off). The SunOS 4.0 tty driver lets you turn it on. ------------------------------ Date: Fri, 28 Oct 88 07:40:43 EDT From: tim@zorac.dciem.dnd.ca (Tim Pointing) Subject: Re: 4.0/nfs bug followup All this talk of problems mixing 3.x and 4.0 with regard to NFS has got me worrying. I had thought (and had been told so by a Sun sales critter) that there would be no problem in the following configuration: A: 3/50 standalone with QIC tape drive OS3.4 (domain X) B: 3/280 server no tape drive OS3.4 (domain X) C: 3/280 with 1/2" tape drive OS3.4 (domain Y) (while both A and B are in the same domain, A doesn't use B except for exported NFS filesystems and rlogin's) I wish to upgrade A and B to 4.0. C, which I have no control over, is going to remain at 3.4 until some of the unbundled & 3rd party s/w is available for 4.0. Questions: (1) I recall hearing that it is not straight forward to use a 3.x remote tape drive to upgrade to 4.0 (i.e. can I use C's tape drive to upgrade B or should I upgrade A to 4.0 first and then use its tape drive to upgrade B?) (2) Will I have trouble mounting 3.4 filesystems from B on A after A has been upgraded to 4.0? (3) Will I have trouble mounting 3.4 filesystems from C on A and B after A and B have been upgraded to 4.0? Tim Pointing, DCIEM tim@zorac.dciem.dnd.ca / tim@zorac.arpa ------------------------------ Date: Thu, 27 Oct 88 18:40:55 PDT From: ahn@violet.berkeley.edu Subject: Sunflower memory extension boards for 3/50 Sunflower Microsystems introduces SFxMX memory extension boards for Sun 3/50 workstation. The boards can be installed and removed to/from the CPU board without any modification or soldering, and takes less than ten minutes. The model SF4MX provides 4 Mbytes extension for Sun 3/50 and the price start from $2145. For more information, contact: Sunflower Microsystems 1684 Marco Dr. San Jose, Ca 95131 FAX# (408) 452-8442 ------------------------------ Date: 27 Oct 88 08:24:02 EDT (Thu) From: n8emr!lwv@sun.com (Larry W. Virden) Subject: Sun and ksh method needed to get shelltool info [[ Alternate address: "osu-cis!n8emr!lwv%killer.Central@sun.com" ]] I have a set of aliases to talk to the shelltool, but do not know how to write the report aliases/functions properly - here is what I am trying to do: ESC='';export ESC alias -x opentool='echo "$ESC[1t"' alias -x closetool='echo "$ESC[2t"' function reporttool { #stty raw -echo; echo "$ESC[11t\c" >/dev/tty ;resp=`line`;stty -raw echo stty raw -echo; echo "$ESC[11t\c" >/dev/tty ;read -r resp;stty echo -raw #echo "$ESC[11t" >/dev/tty ;resp=`line` mresp="${resp#??}" if [ "$mresp" = "1t" ] ; then echo Open! elif [ "$mresp" = "2t" ] ; then echo Closed! else echo Oh no! fi } This is a small portion of what I am trying to do. The problem is that I cannot seem to figure a good way to get mresp set. Can someone give me some good ideas? I have tried several alternatives, most either require the user to type a carriage return or echo garbage on the screen; what I want to do is to be able to get the status info in a shell variable without the user seeing any noticable effect. Thanks! ------------------------------ Date: Thu, 27 Oct 88 21:39:00 edt From: lorraine@msc2.tn.cornell.edu (Peter Lorraine) Subject: 386i TeX problems Is there anyone out there who has a working TeX previewer or dvi2ps on a Sun 386i? I am not a C wizard and have had lots of problems along these lines. dvitool and texsun both invert letters (well, small letters are inverted.. big ones are split in four and then each part is inverted). The rasters generated from the pk fonts are not suitable for the 386i. Has anyone patched the appropriate routine in texsun? dvi2ps has produced files that yield nothing when spooled to a laser writer. Any help would be greatly appreciated. Peter Lorraine (lorraine@msc2.tn.cornell.edu) ------------------------------ Date: Thu, 27 Oct 88 17:05:31 EDT From: gotham!murphy!borogove!jh@sun.com (John Hanley) Subject: Request for filter to magnify bitmaps 2X Anyone with source for a screendump magnifier? Please send to: hanley@cmcL2.nyu.edu ------------------------------ Date: Fri, 28 Oct 88 09:09:21 EDT From: mike@shogun.cc.umich.edu (Michael Nowak) Subject: Using a Miniscribe 1335 with an Adaptec 4000 in a Sun 3/50? We have a Sun 3/50 with an Adaptec 4000 ACB controller. It used to have a Miniscribe 1325 but the drive became damaged and needed to be replaced. We have a 1335 in the office which we'd like to use as a replacement. The 1335 is supposed to be similar to the 1325 in most respects. When we attach it to the controller and run stand/diag, I first get the response "Bad format on volume" after answering the questions about controller and drive type (I specify 1325. It has the same number of cylinders, heads, etc. as the 1335). When I try to format, the drive makes noises for awhile and then the software responds with "Unit not ready". Has anyone had any experience with this configuration? Doers anyone have information on jumper settings on the Adaptec? Does the drive need to be formatted at a level lower than stand/diag can provide? Any help, via E-mail, will be highly appreciated. -- -- Mike Nowak. ------------------------------ Date: 27 Oct 88 17:59:00 GMT From: ssc-vax!ray3rd@beaver.cs.washington.edu (Ray E Saddler III) Subject: Sun 2, tell me about them I'm interested in finding 'all about the Sun 2' box, specifically, what type of 3rd party software is available, how well do they perform, drawbacks and strengths etc... Please e-mail responses and I'll sumamrize if there is noticable interest. Thank you - Ray Ray E. Saddler III | Path: ..!ssc-vax!ray3rd Boeing Aerospace | From: ray3rd@ssc-vax.UUCP P.O. Box 3999 m.s. 3R-05 | Seattle, Wa. 98124 USA | VoiceNet: (206) 657-2824 ------------------------------ Date: Thu, 27 Oct 88 16:41:19 EDT From: berlin%bu-albert.BU.EDU@bu-it.bu.edu (David Fickes) Subject: NeXT vs. Sun In the recent announcements and reaction to the NeXT computer quite a few comparisons to the current Sun machines have been made. Being a fan of Sun but unable to fairly evaluate the NeXT box on it technical merits, I thought I push out a few thoughts for your reaction. 1) NeXT "features" are available for Suns. (Optical disks etc..) 2) Software for the NeXT is much more "full-featured" in demanding higher functionality as "standard features" for all software. 3) Suns can run MACH and therefore... become "MACH" clones to some degree. What is the running opinion of the NeXT machines in circles that are currently using Suns. It seems to me that the NeXT box has quite a "forward-looking" system... but then I thought of this when I saw my first Sun system. Reactions? [[ Please mail reactions to David. He is willing to summarize and post the responses. --wnl ]] - david David K. Fickes dfickes@bu-albert.bu.edu The Collected Papers of Albert Einstein ...harvard!bu-it!bu-albert!dfickes Boston University berlin@buita.bu.edu 745 Commonwealth Avenue - room 541 617/ 353-9249 Boston, MA 02215 617/ 783-4301 ------------------------------ End of SUN-Spots Digest ***********************