Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/22/88)
SUN-SPOTS DIGEST Saturday, 21 May 1988 Volume 6 : Issue 95 Today's Topics: Re: Suns lose track of the console (2) Re: SLIP on Sun-OS 4.0 - don't hold your breath Re: apl for suns rlogin window size bug silly behaviour of dbx(tool) Fixing Client Boot Failures File system reorganization under 4.0 Shared memory references? PSImail for Suns? Dual-porting on Xy451? /tmp on a NFS server? text: table is full? Query on 386 machines 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: Wed, 18 May 88 14:21:00 EDT From: mcgrew@topaz.rutgers.edu (Charles) Subject: Re: Suns lose track of the console (1) Reference: v6n89 Robert Drzyzgula writes: > Does anyone know why Suns lose track of thier console? ... The > Sun will not respond to any terminal input, *even break*! We've seen this problem on our suns from time to time (though we run a hacked 3.2). What happens is the getty becomes disassiated with the 'a' port somehow, so input from the terminal goes nowhere. Coming in over the network and killing the getty (so a new one spawns) clears the problem. Charles ------------------------------ Date: Wed, 18 May 88 11:52:15 PDT From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu> Subject: Re: Suns lose track of the console (2) Reference: v6n89 I ran in to a similar-sounding problem several releases back. The solution turned out to be very simple: delete /dev/kbd, /dev/mouse, and /dev/fb. These are the devices that control the keyboard, mouse, and frame buffer on a workstation. If you're using a terminal for your console, you don't have any of these; by deleting them, you avoid certain SunOS bugs that cause them to be used when they shouldn't be... That might solve your problem. -Brent Brent Chapman Capital Market Technology, Inc. Senior Programmer/Analyst 1995 University Ave., Suite 390 brent@capmkt.com Berkeley, CA 94704 {lll-tis,uunet}!capmkt!brent Phone: 415/540-6400 ------------------------------ Date: Wed, 18 May 88 12:07:39 PDT From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu> Subject: Re: SLIP on Sun-OS 4.0 - don't hold your breath Reference: v6n89 Ted Nolan (ted@braggvax.arpa) writes: # Well, I suspect there will be a SLIP for 4.0 shortly after it goes out the # door. I say this because we have just gotten PCNFS 3.0 and it supports # SLIP. Sun has included dialup SLIP for the Sun as part of the server # utilities disk, and I can't see them saying that they won't provide it for # SunOS 4.0 given it's now officially part of one of their products. I'm not so sure of this. In the "Sun Unbundled Software Availability" table that was a part of the "When Should I Upgrade to SunOS 4.0?" letter that I (and presumably all other support contract primary contacts) got, PC-NFS 3.0 (which I received as an upgrade last week) is available in a binary-compatible form for SunOS 4.0 right now, _but_ there is a footnote that says "Availability of PC-NFS support for serial lines [SLIP] under SunOS 4.0 to be announced at a later date.". There is no date listed for "full functionality under 4.0" for PC-NFS 3.0. There is something labelled simply "PC-NFS" (do they mean a version newer than 3.0?) that the chart says will never run under SunOS 3.x, and which has a "full functionality under 4.0" date of "TBA". In other words, Sun has _not_ committed itself to supporting SLIP under SunOS 4.0. They have said they would announce the _availability_ of it later; they might very well announce that it won't be available. I certainly hope not. In any case, who wants to buy PC-NFS just to get SLIP for UNIX to UNIX use? I'm curious about several things: How many people/organizations/whatever _use_ SLIP on their Suns? For how many machines? Over dialup lines? How many _would_ use SLIP if it were a part of the SunOS release? For how many machines? Over dialup lines? How many would pay for SLIP as an unbundled product from Sun? How much would you pay? -Brent Brent Chapman Capital Market Technology, Inc. Senior Programmer/Analyst 1995 University Ave., Suite 390 brent@capmkt.com Berkeley, CA 94704 {lll-tis,uunet}!capmkt!brent Phone: 415/540-6400 ------------------------------ Date: Thu, 19 May 88 09:15:37 EDT From: ted@braggvax.arpa Subject: Re: apl for suns There is a version of APL on the 4.2 and 4.3BSD distribution tapes. It's for PDPs and vaxen, but I suspect it would run on Suns with some work. I'm not sure about the legal status, but I suspect you don't need a Unix src liscense. Ted Nolan ted@braggvax.arpa Here's the contact information from the README: Title: APL Authors: John D. Bruner Lawrence Livermore Laboratory P.O. Box 808, L-276 Livermore, CA 94550 (415) 422-0758 Prof. Anthony P. Reeves Cornell University, Phillips Hall Ithaca, NY 14853 (607) 256-4296 Description: This is Purdue/EE's APL, which runs on both PDP-11's and VAX-11/780's. This APL originally was written by Ken Thompson at Bell. It went to Yale for a while, and came to Purdue via a Chicago distribution in (I think) 1976. Jim Besemer (now with Tektronix in Oregon) made many of the extensions to the original V6 PDP-11 version, including quad I/O functions, the state indicator, internal label processing, and a number of primitive functions. I began support of APL when Jim left in 1978 and have been handling it since then. The driving force behind all of the development and maintenance of APL at Purdue has been my major professor, Dr. Anthony P. Reeves. Please forward bugs/comments/suggestions to Dr. Reeves or to me (UUCP site "pur-ee", login names "reeves" and "bruner"). ------------------------------ Date: Thu, 19 May 88 11:43:11 CDT From: William LeFebvre <phil@rice.edu> Subject: rlogin window size bug I have noticed this bug on release 3.2 and 3.5. I currently have no way to check 3.5.1. Sun has been notified of this bug (I sent the message at least, but I haven't gotten an acknowledgement yet). Problem: In a SunView shelltool, an rlogin session does not correctly propagate window widths in excess of 127 columns. Repeat-by: When running suntools, start up a shelltool. rlogin to your favorite host (you can even rlogin to yourself). Type "stty everything" and look at the number of columns. Move the window all the way to the left. Stretch the window all the way to the right (making it as wide as the screen will allow). Type "stty everything" again. The number will be completely unreasonable: something above 65000. At this point, termcap will start returning "0" for the "co" capability. This renders some termcap/curses based programs useless. Conjecture: It is a fact that the tty driver under SunOS stores the width and length in full-sized ints. Look at "struct ttysize". I suspect (based on the definition of a "struct winsize") that rlogin propagates this information in an unsigned short. If this is true, it could be that the receiving end forgot it was unsigned. Suggested-fix: Requires source that I don't have access to. Submitted-by: William LeFebvre Department of Computer Science Rice University <phil@Rice.edu> ------------------------------ Date: Thu, 19 May 88 05:15 EDT From: DAVIS@scrvx2.sdr.slb.com Subject: silly behaviour of dbx(tool) The following was reported by a user here. I'd like to know if anyone else has any comments or ideas before I make a fool of myself with our local sun office.... Of course, `void' is a keyword in C, but then our user was debugging Fortran :-) In the program below dbx (tool) gets void as a static real of dimension [3,101] instead of being a real variable [2,100]. integer i,j parameter (i = 100) real*4 vg(0:i,2), void(0:i,2) do 10 j=1,i vg(j,1)=10 vg(j,2)=20 void(j,1)=11 void(j,2)=22 10 continue end If I try to print void then I get "syntax error". The variable vg is handled correctly. The problem seems to be the name of the variable 'void'. If I change it to svoid as below, integer i,j parameter (i = 100) real*4 vg(0:i,2), svoid(0:i,2) do 10 j=1,i vg(j,1)=10 vg(j,2)=20 svoid(j,1)=11 svoid(j,2)=22 10 continue end In this case if I ask whatis svoid then I get the correct answer and can print the contents of the array. The bug seems to be associated with the variable name void. In this second case if I ask whatis void then the answer is fortran print decl the same answer if I ask what is real, complex or char. ------------------------------ Date: Wed, 18 May 88 11:16:17 EDT From: umix!lokkur!scs@rutgers.edu (Steve Simmons) Subject: Fixing Client Boot Failures We have an irregular failure with clients hanging during the boot process. It's not clear *why* they fail, but fixing it is easy. The cause is always the device files getting scrambled. The fix: Mount the client partition on the server. Remove all of the entries in /dev except MAKEDEV. In the client /dev, give the command MAKEDEV std pty0 pty1 pty2 win[I forget]. This will rebuild the entire /dev directory for you. The client will then (usually) come up fine. On less frequent occasions the entire client root partition is scrambled. These things usually happen in bunches -- 3 to 10 in a cluster. Then things will be fine for months. We make no changes to the nd.local files, and are running 8-9 clients per server under 3.4. It's been happening since 3.0, tho. Anyone seen similar problems? Steve Simmons UNIX Systems Mgr, Schlumberger CAD/CAM scs@applga.uucp ------------------------------ Date: Tue, 17 May 88 09:57:54 BST From: Ian Phillipps <mcvax!camcon!igp@uunet.uu.net> Subject: File system reorganization under 4.0 Reference: v6n77 > Many readers of this list may have heard of the upcoming release of a > major SUN operating system titled 4.0 -- but many may not have heard about > the many fundamental changes in Unix that are coming along with it. > Also, /bin no longer exists! Its contents live in /usr/bin. Also, > /lib no longer exists. Its contents have been moved to /usr/lib. IS THIS A SPOOF? What about all those scripts that start "#!/bin/csh" What about all the shell scripts and makefiles which call up /bin/sh explicitly? Broken, every one! [[ Not necessarily... --wnl ]] > Executables from /etc are in /usr/etc. Also, /usr is to be mounted > read-only. Now you ARE joking. Aren't you? Where do user files go? > Executables from the root directory reside in /single. > Comments anyone? I can see a few symbolic links appearing if this is really true. [[ According to earlier discussion in Sun-Spots, /bin will be a symlink to /usr/bin, and similarly for /lib. --wnl ]] UUCP: ...!ukc!camcon!igp | Cambridge Consultants Ltd | Ian Phillipps or: igp@camcon.uucp | Science Park, Milton Road |----------------- Phone: +44 223 358855 | Cambridge CB4 4DW, England | ------------------------------ Date: Wed, 18 May 88 17:45:54 edt From: mlijews@nswc-wo.arpa Subject: Shared memory references? Does anyone have some good references for using the System V shared memory stuff. I am contemplating a project which could make good use of these goodies and would appreciate any references you could give, be they programs you've written, books or articles. Thanks. Mike Lijewski (mlijews@nswc-wo.arpa) Applied Math Branch NSWC Silver Spring, MD 20903 ------------------------------ Date: Thu, 19 May 88 05:08 EDT From: DAVIS@scrvx2.sdr.slb.com Subject: PSImail for Suns? I have heard rumours that someone has written a version of DEC's PSI (packet switch interface) mailer for Suns. Does anyone now anything about this ? We are connected to an internal net composed chiefly of VAXen, and currently have to run all our mail out through an Exos/PMDF gateway on one of our own VAXen. To be able to send and recieve PSI mail (as all of our net traffic is that comes from elsewhere) directly on the Suns would be wonderful, and we could then concentrate on using the OSI and X25/X29 software we already have... ------------------------------ Date: Thu, 19 May 88 15:03:13 +0300 From: leonid@TAURUS.BITNET Subject: Dual-porting on Xy451? Has anyone out there tried to connect dual ported SMD disks (e.g. 2361) to two different 451's on two SUNs ? Sun people claim this is impossible on the device driver level, but it seems something worth a try. [ I known BSD file system doesn't support dual-porting, but mounting read only a dual-ported filesystem works find on BSB ] Leonid ------------------------------ Date: Thu, 19 May 88 09:49:21 EDT From: Peter Marshall <peter@hadrian.uwo.ca> Subject: /tmp on a NFS server? We have a pair of SUN 3/60s each with a 144MB SCSI drive. We have the file systems cross mounted (/usr/src/usr.local on one machine, /usr/ucb on the other etc.) to save space and still give each machine local paging and swapping space. We made a change recently to one of the machines by making /tmp (in the "a" partition) a link to /usr/tmp where /usr was mounted from the other machine. Suddenly after an hour of use or so I started getting messages from commandtool windows about problems with the disk structure with a diagnosis that it was probably full. The only way to continue was to turn off scrolling in the window. Periodically mailtool would hang up in a disk wait state. We tried a number of things to correct this problem (like increasing the amount of free space on the disks) but the problem persisted. When we hit upon putting /tmp back on the local disk everything worked just fine again. (The timing relationship between moving /tmp and the problems with the screen programs was not as obvious at the time!) Has anyone else seen symptoms like this? Is there something about /tmp files that means that they cannot wait for an NFS server to fire up before giving up? Is this going to be a problem with (future) diskless clients that we might add (that will not use ND)? We currently get a fair number (4 or 5 times a day) of NFS server hadrian not responding still trying NFS server hadrian ok messages, often when "hadrian" is doing very little. There is very little pause between the messages. Is this normal or related to the above problem? Peter Marshall, Data Com. Manager, NSC 220, CCS, Univ. of Western Ontario 519-661-2151 peter@hadrian.uwo.ca peter@julian.uucp pm@uwovax.bitnet ------------------------------ Date: Thu, 19 May 88 10:48:04 EDT From: ufnmr!ufnmr_1!gareth@bikini (Gareth J. Barker) Subject: text: table is full? Can someone please tell me what the 'text' in the 'text: table is full' message is. Is the size of the table definable in the kernel configuration files, and what trade-offs are involved in increasing it?? Thanks for any help, Gareth J. Barker, University of Florida, Department of Radiology. BITNET : GJBARKER@UFFSC.BITNET INTERNET : ufnmr!gareth@BIKINI.CIS.UFL.EDU UUCP : ...gatech!uflorida!ufnmr!gareth ------------------------------ Date: Thu, 19 May 88 14:31 +1000 From: Robert Smart <munnari!ditmelb.oz.au!SMART@uunet.uu.net> Subject: Query on 386 machines Do the new Sun 386 machines support the sunlink protocols? For sunlink X.25 this requires that the serial ports be capable of handling synchronous communications. Bob Smart, CSIRO Division of Information Technology, Australia ------------------------------ End of SUN-Spots Digest ***********************