Sun-Spots Digest, v7n1
William LeFebvre
Sun-Spots-Request at Rice.edu
Thu Nov 3 14:18:45 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at ima.ima.isc.com>
Subject: Re: NFS mount mail
> From: Wayne Folta <folta at 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 at 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 at inmet.inmet.com
Intermetrics, Inc. uunet!inmet!nelson
------------------------------
Date: Tue, 25 Oct 88 22:52:00 EDT
From: Bennett Todd <bet at 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 at TUI62.BITNET>
Subject: Re: A fix for pty/suntools problems
Recently there was a fix:
> From: Len Evens <len%rufus.math.nwu.edu at 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 at db0tui62.BITNET D 1000 Berlin (West) 10
------------------------------
Date: Wed, 26 Oct 88 09:46:10 -0700
From: Joseph Kwan <rabbit at 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 at psivax.psi.siemens.com
------------------------------
Date: Tue, 25 Oct 88 20:29:54 CDT
From: Jacob Gore <gore at 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 at EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
------------------------------
Date: Tue, 25 Oct 88 17:02:47 EDT
From: ehrlich at 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 at 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 at CARLETON.BITNET>
------------------------------
Date: 24 Oct 88 22:28:00 EDT
From: Walter Roberson <WCSWR at 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 at CARLETON.BITNET> "CMS did this to me!"
------------------------------
Date: Tue, 25 Oct 88 20:24:54 EDT
From: tower at 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 at eros.berkeley.edu
enjoy -len
------------------------------
Date: Mon, 24 Oct 88 08:43:23 PDT
From: geoffb at 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 at 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 at 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 at rand.org)
Geoffrey Baehr
------------------------------
Date: Tue, 25 Oct 88 17:41:15 pdt
From: chinson at 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 at 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 at grian.cps.altadena.ca.us
ames!elroy!grian!liz
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list