Sun-Spots-Request@Rice.edu (William LeFebvre) (11/03/88)
SUN-SPOTS DIGEST Tuesday, 1 November 1988 Volume 7 : Issue 1 Today's Topics: Administrivia: mail delivery problems, new volume Re: NFS mount mail Re: When will sun have ANSI-ish C compilers Re: A fix for pty/suntools problems Re: Remote booting a Sun-3/280 -- failure! Re: Dist'n format for 386i: disk vs. tape rcmd (_checkhost) confusion over domain names + FIX UUENCODE and BITNET ascii/ ebcdic news reader for sunview, news or x Summary on INR 5.0 Responses malloc problem on sun4 with OS3.2? Silicon Graphics tapes? 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: Tue, 1 Nov 88 17:22:47 CST From: William LeFebvre <phil@Rice.edu> Subject: Administrivia: mail delivery problems, new volume My apologies once again for the multiple copies of recent digests. We had some strange queue file mutations here that caused one digest to be sent out twice instead of two different digests to be sent out once. The only way to make sure that everyone got a copy of the second digest was to send the whole thing again. I decided that I just can't wait for the new year. Volume 7 is starting two months early. Happy new year, everyone! William LeFebvre ------------------------------ Date: Fri, 21 Oct 88 09:58:00 EDT From: Nelson Lerner <ishmael!nelson@ima.ima.isc.com> Subject: Re: NFS mount mail > From: Wayne Folta <folta@tove.umd.edu> > ... > As I remember it, we solved the problem as follows: > 1. All users must be known to the NFS server. For us, this was easy, > since all users were already in the Yellow Pages passwd file. > 2. All users are mail-aliased to reside on the NFS server. That is, > user 'usera' was aliased to 'usera@nfshost' in the Yellow Pages > mail aliases file. > 3. NFS mount the /usr/spool/mail from the NFS server to all the other > hosts. I am interested in doing a similar scheme, but it has been pointed out to me that there is a file locking problem between the server and the client where mail is read. Apparently an NFS lock is not used so that in the event that someone reading mail happened to quit at the same time that the server delivered mail, the new mail would be lost. Granted the probability of this happening is low, but the chance exists nonetheless. Any comments or suggestions? Nelson Lerner nelson@inmet.inmet.com Intermetrics, Inc. uunet!inmet!nelson ------------------------------ Date: Tue, 25 Oct 88 22:52:00 EDT From: Bennett Todd <bet@bent.mc.duke.edu> Subject: Re: When will sun have ANSI-ish C compilers Never, perhaps? Given gcc, the state of Sun's C compiler suddenly seems unimportant. Indeed, given the encouraging signs of progress that continue to come from FSF, I'm not even bothered by SunOS 4.0 (as I expect to keep running 3.5 until I can boot GNU). I also think it worth noting that at least one (potential) competitor has picked up the GNU tools as the primary supported OS components. -Bennett ------------------------------ Date: Wed, 26 Oct 88 03:55:40 +0100 From: Wilhelm Koehler <ZTUBOWK@TUI62.BITNET> Subject: Re: A fix for pty/suntools problems Recently there was a fix: > From: Len Evens <len%rufus.math.nwu.edu@eecs.nwu.edu> > ... > The following problem has been reported: > > all input on pty0 is converted to ^D's after a suntools has exited. > > This happens on our 3/50's and 3/60's. I don't really want to try it > > on one of our larger file servers. Applying Len's push/pop-fix didn't change anything (So far on any of our Sun 3/50, 3/280, SunOS 4.0_Export). With a closer look I found another "filec" Problem: After removing the "set filec" from ".cshrc" it was possible to enter commands by finishing them with "^J". Allways without any echo. At last "\ps -tp0" pointed out there was still a process hanging around on /dev/ttyp0, killing that and re-rlogin did the job. Bytheway I noticed the problem on any Pseudo-tty and the problem/process had nothing to do with suntools. Wilhelm Koehler Tel.: +49 30 314 24785 TU Berlin FB-20 Sekr. FR 5-6 UUCP: ...!pyramid!tub!wk Franklinstr. 28/29 BITNET: wk@db0tui62.BITNET D 1000 Berlin (West) 10 ------------------------------ Date: Wed, 26 Oct 88 09:46:10 -0700 From: Joseph Kwan <rabbit@psivax.psi.siemens.com> Subject: Re: Remote booting a Sun-3/280 -- failure! Reference: v6n273 You're on the right track (that ND requests are being sent by the client to the server). nd must be set up on the server side with the public disk partition specified in /etc/nd.local. You need something along the lines of: clear version 1 user 0 0 /dev/xy0h 0 -1 -1 user 0 1 /dev/xy0f 0 size -1 ... son in the /etc/nd.local. The 3rd line (user 0 0) specifies the file system that is available via ND. I load and store copies of "copy", "diag" and "minifs" on /dev/xy0h so that I can boot diag or copy from any diskless/tapeless machine. Joseph Kwan Systems Analyst -- Pacesetter Systems, Inc. A Siemens Company uucp: {csun, scgvaxd, hoptoad, sdcrdcf, uunet}!psivax!rabbit domain: rabbit@psivax.psi.siemens.com ------------------------------ Date: Tue, 25 Oct 88 20:29:54 CDT From: Jacob Gore <gore@eecs.nwu.edu> Subject: Re: Dist'n format for 386i: disk vs. tape >If you're accustomed [...] to being able to load >software off a remote tape drive, be careful on the 386i where this >capability is apparently not available for the standard "Application" and >"Developer's" distribution kits. >[describes a seemingly tedious solution involving copying the tape to > floppies] We were bit by the same problem too. Our sales rep was just as surprised... Anyway, here's how we worked around it: We brought down a 3/50, disconnected its shoebox, connected the shoebox to the 386i, read the tape, then moved the shoebox back. It did not take much time at all to move the shoebox. Too bad we had spent many hours by then trying to read the tape over the network... Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore ------------------------------ Date: Tue, 25 Oct 88 17:02:47 EDT From: ehrlich@shire.cs.psu.edu (Dan Ehrlich) Subject: rcmd (_checkhost) confusion over domain names + FIX Machine Type: Sun 4/260S O/S Version: SunOS 4.0 Organization: Computer Science Department, The Pennsylvania State University 333 Whitmore Laboratory, University Park, PA 16802 Phone Number: +1 814 865 9723 Description: After changing over to using the resolver based gethostby* functions rlogin's, rsh's, et al, started to fail mysteriously. This was traced to some seriously bogus code in the internal routine _checkhost defined in rcmd.c. If the originating host identifies itself with a fully qualified name, i.e. gondor.cs.psu.edu, and only the unqualified name, i.e. gondor, was in either .rhosts or /etc/hosts.equiv, the login on the target machine would fail with a SEGV. We were unable to determine the cause of the SEGV (might be an optimixer bug), but uncovered the following in _checkhost(): 1) gethostname() was being called with sizeof(ldomain), where ldomain is a (char *). It should be MAXHOSTNAMELEN instead. 2) _checkhost() assumes that gethostname() returns a fully-qualified hostname, which is probably not true on SunOS 4.0. getdomainname() should be called. Repeat-By: Find a host that has is hostname set to be fully qualified, or set it to be so. Put the unqualified hostname in .rhosts on the target machine. Try to rlogin to the target machine. Fix: Apply the following patch to lib/libc/rcmd.c and recompile and install libc and friends. (BTW - This still works with YP, although I can't imagine why one would want to use YP for hostname resolution. :-) *** /tmp/geta11455 Tue Oct 25 16:43:38 1988 --- /tmp/getb11455 Tue Oct 25 16:43:38 1988 *************** *** 359,378 **** if (nodomain) return(0); if (!domainp) { ! if (gethostname(ldomain, sizeof(ldomain)) == -1) { ! domainp = (char *)1; ! return(0); ! } ! ldomain[MAXHOSTNAMELEN] = NULL; ! if ((domainp = index(ldomain, '.')) == (char *)NULL) { ! nodomain = 1; ! return(0); ! } ! domainp++; ! cp = domainp; ! while (*cp) { ! *cp = isupper(*cp) ? tolower(*cp) : *cp; ! cp++; } } return(!strcmp(domainp, rhost + len +1)); --- 359,383 ---- if (nodomain) return(0); if (!domainp) { ! if (getdomainname(ldomain, MAXHOSTNAMELEN) == 0 && ! ldomain[0] != '\0') { ! domainp = ldomain; ! } else { ! if (gethostname(ldomain, MAXHOSTNAMELEN) == -1) { ! domainp = (char *)1; ! return(0); ! } ! ldomain[MAXHOSTNAMELEN] = NULL; ! if ((domainp = index(ldomain, '.')) == (char *)NULL) { ! nodomain = 1; ! return(0); ! } ! domainp++; ! cp = domainp; ! while (*cp) { ! *cp = isupper(*cp) ? tolower(*cp) : *cp; ! cp++; ! } } } return(!strcmp(domainp, rhost + len +1)); ------------------------------ Date: Tue, 25 Oct 88 18:16:33 CDT From: WAPJAS@CARLETON.BITNET Subject: UUENCODE and BITNET After seeing Chuck Musciano's message on encoding ASCII files I felt it appropriate to mention our experience in this area. Our BITNET connection runs on Honeywell DPS-8 hardware that uses the ASCII character set. Using the vendor supplied ASCII-EBCDIC tables, we had a lot of character translation problems. I picked up an EBCDIC-ASCII translation table from Columbia University and we modified our mail software to use that table. Since then we have had NO PROBLEMS with character translation. If I send a test message containing all printable ASCII characters from an Internet site through BITNET to our site, all characters, including the caret ('^') come through correctly. We have no problems receiving UUENCODEd files through BITNET. The only way to solve ASCII-EBCDIC translation problems is for everyone to use the same translation table. As our problems were eliminated by using the table originating from Columbia, I can only assume that all gateways into BITNET are using the same table. We don't have problems with BITNET folding lines or expanding tabs. These actions should only be possible at the point where a message enters or leaves BITNET. Regards.. John Stewart <WAPJAS@CARLETON.BITNET> ------------------------------ Date: 24 Oct 88 22:28:00 EDT From: Walter Roberson <WCSWR@CARLETON.BITNET> Subject: ascii/ ebcdic We used to be plagued with Ascii/ EBCDIC transliteration problems. We are an ascii-based system whose only mail connection is via an EBCDIC-based system. I would have blaimed that connection, if 'twere not for the fact that some of the mail came through without trouble. It seemed to depend on the source of the mail, and seemed to be fairly consistant with any one originating site, but independant of any routing transfer that I knew about. That is, the fault seemed to be with some obscure pass-through non-gateway site. Most annoying. I haven't seen any problems lately, though: perhaps that site fixed the problem... or perhaps that path to us doesn't get exercised very often nowadays. Earlier this year, I was doing some ascii-based graphics on an EBCDIC machine with an IBM 7171 protocol convertor between it and me. In the process I discovered what might be an important contributing factor to this entire situation: namely, that some of the ASCII/ EBCDIC translation tables published by IBM are incorrect. I don't know of any non-IBM systems (excluding clones of IBM mainframes) which use EBCDIC, so if IBM itself gets the tables wrong, then the mis-information could easily get perpetuated. What I found was this, from the VS FORTRAN Version 1 Release 4.1, Library and Language Reference Manual (pg 365-370) -- which I found agreed with some of the other IBM tables I examined: EBCDIC char claimed actual code desc. code (char) code (char) -------- ----- ----------- ----------- 4A cent 91 () none 4F or 33 (!) 124 (:) 5A exclaim. 93 (|) 33 (!) 6A vert bar 124 (:) none AD none none 91 () BD none none 93 (|) D0 none none 125 (}) D1 r. curly 125 (}) none Notes: EBCDIC values shown in Hex; ASCII in decimal. 4F is the Logical OR symbol, the broken bar. 6A is the Vertical Line... not the Long Vertical Bar D0 vs D1: the claimed code for right curly bracket is D1, but it actually appears in position D0. Now, some of these positioning questions could be due to minor differences in protocol convertors. EBCDIC has no curly or square brackets, so their positioning in the table could be arbitrary -- except that one would normally expect an IBM protocol convertor to be consistant with IBM standards on this point. However, there is one telling entry shown above which *proves* that the IBM tables are incorrect: the ascii exclaimation mark definitely does NOT show up at ascii position 93 !!! We never had any trouble with the up-arrow, incidently: EBCDIC 5F, logical NOT, is claimed to show up at ASCII 94, which is the up-arrow, which is not mentioned in the table. Thus, up-arrow was always translated to NOT as it went into EBCDIC, and got translated back again coming out. The lesson I learned out of this whole thing: don't trust IBM manuals! Oh yes: while I remember: a suggestion on how to distribute the new uu{en:de}code in the first place: Encode any doubtful characters needed by the program, as multi-character sequences rooted in 'safe' characters. Then, provide a small script which translates the coded-sequences into their expected values. 'tr' could be used to do the octal to ascii conversion that will be needed to avoid prompting the user to type in a left square bracket, or whatever. If the code was written in a slightly ugly manner, with things like _LSB written everywhere a left square bracket was needed, then most of the sensitive things can be removed to #define's, which can, in turn, be included via #include on the file output from 'tr'. Walter Roberson <WCSWR@CARLETON.BITNET> "CMS did this to me!" ------------------------------ Date: Tue, 25 Oct 88 20:24:54 EDT From: tower@bu-it.bu.edu (Leonard H. Tower Jr.) Subject: news reader for sunview, news or x xrn exists for X10. They plan an X11 version. Further info from: xrn-users-request@eros.berkeley.edu enjoy -len ------------------------------ Date: Mon, 24 Oct 88 08:43:23 PDT From: geoffb@ale.ind.trw.com (G. Geoffrey Baehr) Subject: Summary on INR 5.0 Responses In regards to my posting concerning INR 5.0 dropping certain sized packets, here is a response summary: nowicki@Sun.COM (Bill Nowicki): Are you getting any error messages about "giant packets" on the end systems (as opposed to routers)? There was a bug in the Lance hardware that had a work-around in SunOS 4.0. If the last buffer in the chain happened to have a count of zero, the Lance would send 4096 bytes instead. -- WIN Robert_Schwartzkopf <bobs%rcc@rand.org>: We had exactly the same problem you're having with the inr here at RAND, although I believe the packet size that caused ours to wedge was 292 bytes. Someone from sun told us he thought the problem was related to a deficiency in the Lance ethernet chip and recommended running inr on a machine that did not have the Lance ethernet (anything but a 3/50 or 3/60). We eventually tried that a few weeks ago and haven't had any problems since. He also told us that the problem would be coded around in Sunlink 6.0 and/or SunOS 4.1, I don't believe either of these are available yet so I haven't checked. Bob Schwartzkopf (bobs@rand.org) Geoffrey Baehr ------------------------------ Date: Tue, 25 Oct 88 17:41:15 pdt From: chinson@medivax.UUCP (Chinson Yi) Subject: malloc problem on sun4 with OS3.2? I remember reading something about problem with malloc() on sun 4. Can someone please send me any old report on this problem. Thanks Chinson Yi ------------------------------ Date: 25 Oct 88 17:40:59 GMT From: elroy!grian!liz@ames.arc.nasa.gov (Liz Allen-Mitchell) Subject: Silicon Graphics tapes? We have some software on a cartridge tape that was written on a Silicon Graphics Workstation running UN*X. We would like to read it on a Sun 3/60. Has anyone tried to do this? Any information would be much appreciated. Thanks! - Liz Allen-Mitchell liz@grian.cps.altadena.ca.us ames!elroy!grian!liz ------------------------------ End of SUN-Spots Digest ***********************