Sun-Spots-Request@Rice.edu (William LeFebvre) (09/26/88)
SUN-SPOTS DIGEST Sunday, 25 September 1988 Volume 6 : Issue 234
Today's Topics:
hotline@sun.com
Booting Ciprico controllers under SunOS 4.0
Sharing roots under SunOS 4.0; one solution
solution to Sun uucp @ 19.2k
Printer filter for SunOS 4.0: devps
pc/sas on the sun386i
Suntools shutting down incorrectly
Sources wanted: sched and dig_clock
screenblank dumps core
.cshrc vs .login
3270 series terminal emulators?
Polling a serial port?
Hardware Flow Control on SunOS 4.0?
Connecting hardware via the SCSI interface?
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: Sun, 25 Sep 88 13:30:02 CDT
From: William LeFebvre <phil@Rice.edu>
Subject: hotline@sun.com
Here is my understand about how the Sun hotline works. Send mail to the
Internet address "hotline@sun.com" (uucp address "sun!hotline") describing
your bug or problem. Your message should include your system serial
number, machine type (3/60, 3/50, etc.), name, address, and phone number.
Here's the catch: only those customers with a support contract (software
or hardware) are *guaranteed* a response. They may handle problems from
non-supported customers, but priority goes to those with support. I've
known about this service for a long time, but I wan't sure if it was for
anyone's use---I thought it was just for customers with support contracts.
(I hope that I have not made a serious gaffe by mentioning this here).
William LeFebvre
------------------------------
Date: Tue, 20 Sep 88 02:08:56 EDT
From: ingr!b11!jim@uunet.uu.net
Subject: Booting Ciprico controllers under SunOS 4.0
I assume everyone knows that Sun has opted not to provide the same
services regarding non-Sun bootable devices under 4.0 (boo, hiss).
Actually it is possible to boot a Ciprico Rimfire 3200, an probably other
devices, under 4.0.
The biggest change in the booting process seems to be the way the
bootblock code locates the "/boot" program. Previously the bootblock code
would find the "/boot" program from the filesystem. Now the "installboot"
program patches the block numbers of the "/boot" file directly into the
"/usr/mdec/bootxx" code before writing it to the bootblock area of the
partition. Thus the current "installboot" can not be used to put the
bootblock on the partition.
The solution that worked for me was to keep the kernel size below 736K
and to use:
"dd if=/usr/mdec/bootrf of=/dev/rrf0a count=15 seek=1 conv=synch"
to put the bootblock code on the partition. The above command is what the
3.4 "installboot" did. Of course I replaced "/boot" from the distribution
with the Ciprico "boot".
I'm not sure why the 736K is important, if the kernel is larger the boot
process seems to overwrite something important and the screen goes into
Swahili mode.
Jim Levie REMTECH Inc Huntsville, Al
Ph. (205) 536-8581 email: uunet!ingr!b11!jim
------------------------------
Date: Sat, 17 Sep 88 23:26:11 EDT
From: Jean-Francois Lamy <lamy@ai.utoronto.ca>
Subject: Sharing roots under SunOS 4.0; one solution
We have a Sun 4 serving 25 clients, all running SunOS 4.0. We have been
using a single root per architecture ever since going to 4.0 with no
difficulty, and since it is actually quite simple to do we thought others
might want to hear about it.
The general idea is to have clients mount an appropriate root read-only,
and give them devices and whatever files need be private as soon as
possible.
Incidentally, under 4.0 a client knows its hostname when it boots, so
there is no need to go through contortions to look it up; the kernel
already knows and `hostname` works just fine even in rc.boot, which can
then be shared.
We give each client a /export/private/`hostname` directory where it has
root access. That directory contains
dev/ we mount that on top of the root /dev
etc/mtab we can't write on the one in the shared root
tmp/ the usual private stuff
var/adm/*
var/preserve
var/spool/cron/*
var/spool/mail
var/tmp
A look at disk space usage shows it oscillates between 170 and 350K per
client when no-one is doing compilations and the like. The space savings
(compared to giving each client its own 2Meg root) do add up when you have
more plenty.
We cooked up a setup_client script that extracts a tarchive of a prototype
"private" and runs MAKEDEV to create the devices in the dev subdirectory
(cpio? never heard of it :-).
The shared root for each architecture is kept as /export/root/`arch`. The
/export/root/sun[234] directories need the following changes to use the
private directory:
mkdir private
etc/mtab -> ../private/etc/mtab
etc/psdatabase -> adm/psdatabase
etc/utmp -> adm/utmp
tmp -> ../private/tmp
Finally, etc/rc.single in the shared roots must be modified to mount the
devices and the rest of the private directory. One must work around the
fact that etc/mtab is in fact in the private directory we are trying to
mount. One solution is to change the beginning of etc/rc.single along the
following lines:
(
# we need /etc/mtab to be private so we can mount / and /usr
mount -n server:/export/private/`hostname` /private > /dev/console 2>&1
# remount / and /usr read-write.
mount -o remount / > /dev/console 2>&1
mount -o remount /usr > /dev/console 2>&1
umount -at nfs
# this just got rid of mtab, so we remount again...
mount -n server:/export/private/`hostname` /private > /dev/console 2>&1
> /etc/mtab
mount -f / > /dev/console 2>&1
mount -f /usr > /dev/console 2>&1
# so private finally shows up in mtab
mount -f server:/export/private/`hostname` /private > /dev/console 2>&1
# we can now give the client its own devices.
mount server:/export/private/`hostname`/dev /dev > /dev/console 2>&1
In /etc/exports we use (e.g.)
/export/root/sun3 -access=client.ai:client2.ai:...
/export/exec/sun3 -access=client.ai:client2.ai:...
/export/swap/client.ai -root=client.ai,access=client.ai
/export/private/client.ai -root=client.ai,access=client.ai
along with all the standard exports.
Presto!
There are obvious disadvantages to this (you can't give a particular
client a different kernel named "vmunix", because there is nothing private
at boot time), but if you have several clients configured identically
making them share their root may worthwhile.
Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
------------------------------
Date: Mon, 19 Sep 88 19:54:06 EDT
From: lai%vedge.UUCP@larry.mcrcim.mcgill.edu (David Lai)
Subject: solution to Sun uucp @ 19.2k
Kent Hauser sun!sundc!tfd!kent writes:
>
>In trying to hook up a TrailBlazer+ modem to my Sun 3/60 (SunOS 3.5), I
>found that Sun's uucico does not support 19200 baud operation. (Fastest
>is 9600). Attempts to use 19.2k result in
>
>ASSERT ERROR (uucico) BAD SPEED (-1)
>
>Is there a way around this problem?
The Sun's uucp is very old and its internal baudrate table only goes up to
9600. In order to make it run at 19200 you need to patch the uucico's
baud rate table. I did this with adb. You'll find a table that's
something like this:
300 7
1200 9
2400 11
4800 12
9600 13
These values come from /usr/include/sys/ttydev.h
to find the table with adb you can do:
adb -w uucico.bak ;work on a backup of uucico, just in case
<b ;set start of data space
.,10000?L 2580 ;search for 9600 (2580 is 9600 in hex)
;it'll print an address, thats where the table is
.-30?D ;go back 30 bytes and print decimal values
;keep hitting return until you see the table
What you'll have to do now is patch out an unused entry in the table with
the 19200 baud entry (we patched out 4800), our table looks like this:
300 7
1200 9
2400 11
19200 14
9600 13
Be careful not to patch values outside the table! Use the W command.
Then check the table over to make sure, then write out the new uucico.
Good luck.
David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)
------------------------------
Date: Sat, 17 Sep 88 19:18:44 PDT
From: John Bossert <bossert@thalatta.com>
Subject: Printer filter for SunOS 4.0: devps
Thalatta Corporation announces the availability of devps for SunOS 4.0 for
the Sun3 and Sun-4 families of computers.
Devps is an alternative to Transcript for UNIX systems. Essentially, it
converts the output of either troff or device-independent troff to
Postscript.
Devps provides:
o Integral support of the Berkeley print spooler
o Full support of pic, tbl, and eqn
o Full support of ditroff special character set
o Support of downloadable PostScript typefaces
o Automatic merging and scaling of Macintosh graphics
o Page selection and reversal programs
o Programs for printing labels, envelopes, and transparencies
o Portrait and Landscape printing
For additional information, contact:
Thalatta Corporation
1607 116th Avenue NE, Suite 102
Bellevue, WA 98004 USA
+1 206 455 9838
software@Thalatta.COM ...!uw-beaver!uw-entropy!thebes!software
------------------------------
Date: Sat, 17 Sep 88 15:40:34 EDT
From: Roger Day <jz130317@unix.cis.pittsburgh.edu>
Subject: pc/sas on the sun386i
For the statisticians in the crowd, an interesting tidbit. We thought it
would be a sure thing that the micro version of SAS would fail to run on
the roadrunner. It had failed to run correctly under Microport UNIX on an
AT&T 6300+, and SAS Institute would make no promises about the SUN 386i.
We tried it, and by golly it actually works, including the display manager
and SAS/Graph graphics using Hercules or EGA emulation sent to the screen
or printer. In fact, it works over a network.
Someday, SAS will be ported to UNIX, just as the cathedral at Chartres was
eventually completed. In the meantime, this is the ticket.
------------------------------
Date: Mon, 19 Sep 88 10:00:38 EDT
From: ufnmr!ufnmr_1!gareth@bikini.cis.ufl.edu (Gareth J. Barker)
Subject: Suntools shutting down incorrectly
Problem:
We have a commercially written application which runs under Suntools and
uses multiple windows, etc. Recently when the application exited
(normally) it left an 'image' of all it's open windows on the screen.
Typing into the windows, or trying to 'click' in them gave no results
(they weren't 'realy there'), and pulling up 'redisplay all' from the root
menu had no effect on them. When Suntools was exited it left the console
in a state in which it refused to accept any commands, but occasionally
complained about a 'buffer overflow'. A remote login showed that
'selection_svc' was still running on the console:
PID TT STAT TIME COMMAND
0 ? D 2:20 swapper
1 ? I 0:39 /etc/init -
<deleted>
163 co I 0:07 selection_svc
366 ? I 0:02 rpc.rquotad
15108 co I 0:02 -csh (csh)
<deleted>
Solution:
A reboot fixed everything (just killing selection_svc might have worked,
but I prefered a clean start).
Question:
Is this likely to have been caused by a bug in our application program, a
glitch in Suntools, something else? Has anyone else seen anything like
it?
Gareth J. Barker,
University of Florida,
Department of Radiology.
INTERNET : ufnmr!gareth@BIKINI.CIS.UFL.EDU
UUCP : ...gatech!uflorida!ufnmr!gareth
------------------------------
Date: 19 Sep 1988 1009-EDT (Monday)
From: Dan Lorenzini <sunrise!batman!gcm!dal@sun.com>
Subject: Sources wanted: sched and dig_clock
I would like to obtain the sources for "sched" and "dig_clock" tools. I
am recompiling things for 4.0 and seem to have lost the sources to these.
I would appreciate someone sending these to me (or the archive-server) or
a pointer to where they are, if they are available on a uucp-reachable
archive. Thanks.
Dan Lorenzini
Greenwich Capital Markets
uunet!philabs!gcm!dal
sun!sunrise!batman!gcm!dal
------------------------------
Date: 18 Sep 88 03:06:29 GMT
From: oliveb!stpstn!aad@ames.arc.nasa.gov (Anthony A. Datri)
Subject: screenblank dumps core
screenblank under 3.2 dumps core if you type "screenblank -d1200" instead
of "screenblank -d 1200"
[[ It sure does! --wnl ]]
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
Date: Sun, 18 Sep 88 11:29:19 EDT
From: csrobe@icase.edu (Charles S. [Chip] Roberson)
Subject: .cshrc vs .login
Could someone explain (or point me to a document that explains) the
rationale for what should go in a .cshrc file vs. a .login file? I've
talked to several people (rather casually) and it seems that just about
everybody has a different opinion. Oviously, certain arrangements do
cause problems which specific commands.
Anyway, if anyone can clarify this for me, i'd really appreciate it.
many thanks,
-chip
Chip Roberson ARPANET: csrobe@icase.arpa
114 Thomas Nelson Lane BITNET: $csrobe@wmmvs.bitnet
Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe
JUST OPENED: csrobe@[128.239.1.30] (cs.wm.edu)
------------------------------
Date: 17 Sep 88 16:08:22 GMT
From: kramer@bionette.ucs.orst.edu (Jack Kramer - CMBL)
Subject: 3270 series terminal emulators?
We have many suns on campus and now a central IBM 4381. Does anyone know
of 3270 series terminal emulators which would allow Suns to use fullscreen
applications on the mainframe?
------------------------------
Date: 16 Sep 88 01:38:49 GMT
From: bambam!hjp@uunet.uu.net (Howard J. Postley)
Subject: Polling a serial port?
I feel like there has got to be a better way to do this, but I can't find
it. I am trying to write a routine that will communicate with a serial
device. The device sends data when one of two things occurs: 1) It is
responding to a command that was send to it by the host; and 2) Notifing
the host of some external stimulus.
This setup is essentially identical to a standard communications program
for, say, terminal emulation with modems. My problem is that when I try to
read the port, the read waits for a character. I just want to see if a
character is available. I have opened the port with both open() and
fopen(), in RAW and CBREAK modes.
What is the correct way to do this, it seems pretty basic. By the way,
this is operating on a Sun 3/60.
Thanks in advance.
Please reply directly to me, I will summarize unless it turns out that I'm
and idiot who can't read a manual for beans :-).
//Howard
[[ You can read the manual, you just don't know where to look. This is
not an uncommon problem when it comes to Unix manuals. Read the pages for
"fcntl" in sections 2 and 5. Pay special attention to "FNDELAY" and
"FASYNC". You might also want to check out the kernel call "select" by
reading "select(2)". --wnl ]]
--
Howard Postley usenet: uunet!bambam!hjp
On Word phone: +1 213 399 7733
snail: 2434 Main St; Santa Monica, CA 90405
------------------------------
Date: 18 Sep 88 19:11:40 GMT
From: emory!km@gatech.edu (Ken Mandelberg)
Subject: Hardware Flow Control on SunOS 4.0?
The rumor was that SunOS 4.0 would support hardware flow control on tty
ports with appropriate hardware. Now that we are running 4.0, this looks
like a bit of a disappointment.
As far as I can tell:
1) Although the zs and mcp ports support the CRTSCTS ioctl on the termio
structure, this is only half flow control. It protects the modem from
overflow from the Sun. There is no corresponding CCTSRTS ioctl.
2) Getty has no way to even turn on this half flow control. There is no
corresponding attribute in gettytab. In fact internally getty is still
running in V7 compatibility mode with stty/gtty. No termio in sight.
In summary it looks like there is only half flow control, and to get that
you need to hack something in the login sequence
(getty/login/.login/.profile).
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {decvax,gatech}!emory!km UUCP
Dept of Math and CS | km@emory NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963
------------------------------
Date: Mon, 19 Sep 88 14:30:29 BST
From: Crawford Macnab <mcvax!stl.stc.co.uk!tjcm@uunet.uu.net>
Subject: Connecting hardware via the SCSI interface?
We are currently assessing the feasability of connecting a piece of
hardware to a Sun using the SCSI Interface. Could anyone who has carried
out such a task please give me any useful hints, pitfalls to avoid etc..
(A skeletondevice driver would be very helpful) We are using a Sun3
running 4.0. Thanks in advance,
Crawford Macnab ( tjcm@stl.stc.co.uk +44-279-29531 Ext 2153 )
------------------------------
End of SUN-Spots Digest
***********************