SUN-Spots Digest, v4n30

Vicky Riffle Sun-Spots-Request at RICE.EDU
Wed Oct 15 03:38:47 AEST 1986


SUN-SPOTS DIGEST           Tuesday, 14 October 1986          Volume 4 : Issue 30
Today's Topics: 
		  Re: How do I use -background in suntools (2)
			     3/75 upgrade question
		Summary: alternate sources for Sun-3 memory expansion
				   SUN 3 rdump
			           6 Meg Sun 2
		     Re: Sharing /usr/spool/mail on NFS (2)
		    Re: NFS between Sun 100's and Sun 3's (2)
			     sun: terminal too dumb
			         ie0: no carrier
	    mods to ttysw to allow boldfacing/underlining/reverse video
			     1/2 inch tape drives?
		   ditroff/troff/postscript previewer for SUNs?
			    Slow NFS synchronization?
			       mailtool questions?
		     Driver for Xylogics 772 controller?
			   8 character login names?
		  Problems with mmdfII on SUN workstations?
------------------------------------------------------------------------
Date: Wed, 1 Oct 86 23:54:21 PDT
From: guy at Sun.com.arpa (Guy Harris)
Subject: Re: How do I use -background in suntools (1)

>    I remember reading in an earlier digest about an undocumented feature
> of suntools for the SUN3 whereby 

>    suntools -background <file>

> caused <file> to appear in the background, rather than the usual grey,
> white or black.

It's now documented:

	-background raster-file-name
		Use the indicated raster file as the image in your
		Root Window.  The raster file can be created with
		screendump(1).  Screen dumps produced on color monitors
		currently do not work as input to this option.  Small
		images are centered on the screen.

>    I haven't been able to get this to work, presumably because my <file>
> has been of the wrong format.  Can someone please tell me the exact
> format required?

According to the "file" command, as run on a file somebody was using as
their screen background:

	rasterfile, 1152x900x1 standard format image

Note: if there are any large dark regions on the image, the cursor can very
easily disappear when placed there; root-window grey may be boring, but it
does contrast fairly well with the cursor....

-----------------------------

Date: Sun, 5 Oct 86 14:57:27 EDT
From: mark at markssun.cs.umd.edu.arpa (Mark Weiser)
Subject: How to use -background (2)

In response to the question of how to use -background: pictures must be
in one of the standard pixrect formats, as documents at the back of the 
pixrect programmers guide.  Here follows a little program to convert icon 
format (i.e. human readable ascii) to compact pixrect format (of course, an
icon doesn't make a very good background--too little).
-mark
------begin code
#include <stdio.h>
#include <suntool/icon_load.h>
#include <pixrect/pixrect_hs.h>
#include <sys/file.h>

/* Little program to convert ascii icon-style picture files
   (which really ought to be defined as a type of raster file, but aren't)
   to pr_dump style files.	MDW
*/

struct pixrect *image_pr;

main(argc,argv)
char **argv;
{
	FILE *outfile;
	int fd;
	char error_msg[IL_ERRORMSG_SIZE];
	if (argc < 3) {
		fprintf(stderr, "Usage: %s iconfile pr_file\n",argv[0]);
		exit(1);
	}
	if ((image_pr = icon_load_mpr(argv[1], error_msg)) == NULL) {
		fprintf(stderr, "iconfile: %s", error_msg);
	}

	/* "Why open and then fopen?", I hear you cry.  Well,
	   because try as I might I could not get it to work
	   otherwise, and the pragmatics overrode the intellectual
	   challenge.
        */
	if ((fd = open(argv[2], O_CREAT, 0777)) < 0) {
		fprintf(stderr, "Could not create file '%s'.\n", argv[2]);
		exit(1);
	}
	if ((outfile = fopen(argv[2], "w+")) == NULL) {
		fprintf(stderr, "Could not open file '%s'.\n",argv[2]);
		exit(1);
	}
	if (pr_dump(image_pr, outfile, RMT_NONE, RT_BYTE_ENCODED, 0)) 
		printf("Problem with pr_dump.\n");
	else	printf("Done.\n");
	exit(0);
}
------end code

-----------------------------

Date: Wed, 1 Oct 86 21:58:17 EDT
From: bzs at bu-cs.bu.edu.arpa (Barry Shein)
Subject: 3/75 upgrade question

Mark,

Re: do I just remove the SCSI from the blank board and plug it in the
memory expansion board?

Exactly, just did it a couple of weeks ago on a 3/75 here, exactly
what you said, trivial.

	-Barry Shein, Boston University

-----------------------------

Date: Sun, 5 Oct 86 12:16:30 EDT
From: hull%buffalo.csnet at csnet-relay.arpa (Jon Hull)
Subject: Summary: alternate sources for Sun-3 memory expansion

In response to a request posted on sunspots a few weeks ago, several leads 
were received to vendors that supply memory expansion boards for Sun-3/VME 
systems.  Three vendors were identified and their prices with a University 
discount are listed below.  They all offer a lifetime warranty.

1.  Clearpoint  1-800-CLE-ARPT  (contact: Cathy Holmes)
    4Mb  $3384
    8Mb  $5009
    12Mb $6624

    Rsquared 303-799-9292 (contact: Mike Jones)
    sells memory expansion boards manufactured
    by Clearpoint in the following size/price
    configurations:
       2Mb  $1995
       4Mb  $2495

2.  Helios Systems 408-356-0271  (contact Norb Witt)
    4Mb  $2240
    8Mb  $3600

3.  Sales One  408-947-1266   (contact: Jim Thompson)
    4Mb  $3300
    8Mb  $5500
    12Mb $7700
    16Mb $9900

These prices are current as of October 3, 1986 when these
vendors were polled by telephone.

Thanks to the following people for offering the information
that made gathering this data possible:
Robert Cohn, Jeffrey Edelheit, Russ Rew, Paul Harter,
Rich Baker, and Asad Abidi.

If you have any other information about memory expansion
for suns, please let me know.

Thanks,
Jon Hull

 UUCP   : {cmc12,hao,harpo}!seismo!rochester!rocksvax!sunybcs!hull
          ...{allegra,decvax,watmath}!sunybcs!hull               
 CSNET  :  hull at buffalo                                         
 ARPA   :  hull%buffalo at csnet-relay                         

-----------------------------

Date: Mon, 6 Oct 86 18:54:29 PDT
From: mr-frog at sdcsvax.ucsd.edu.arpa (Dave Pare)
Subject: SUN 3 rdump

Our tape drive resides on a 4.3 BSD vax 11/750, and we were doing dumps
from a sun 3/160 to the vax.

After taking upwards of an hour to dump 40 mb, I got annoyed enough
about "rdump" to do something about it.  Somebody else may have
already done the same thing, but if so, I haven't heard about it!

The transfer rate under the old scheme runs around 11.5kb/sec, which on a
10 megabit/sec ethernet seemed somewhat (!) slow.  After much work, I
determined this was due to a small tcp send/receive buffer size on the
sun I was dumping from.  When I increased the figure to 4k per send/recv
socket, the performance jumped up to 30.9kb/sec.

If you have sources, and feel like mucking with it, change the variables
tcp_sendspace and tcp_recvspace in tcp_usrreq.c to be = 4*1024
(instead of 2*1024).

If you don't have sources, you'll have to adb -w your kernel.  Change the
same variables I mentioned above, and set them to be 4096 each.

You'll need to do the same thing on both your server and your client.
I have no data whatsoever on how this will impact your mbuf consumption,
the speed of your rcp's, or anything of that sort.  However, it will allow
you to get through a 40 meg tape in only 20 minutes...

This does not need to be done on 4.3, however, since they were clever enough
to insert a "SO_SNDBUF" and SO_RCVBUF setsockopt calls which do essentially
the same thing, but on a per-socket basis.  It would be very nice if the
people at sun in their next version of sun 3.X, could incorporate some
of the 4.3 modifications also.

Dave Pare

-----------------------------

Date: Tue, 7 Oct 86 12:55:51 EDT
From: butler at stsci.arpa (Lee Butler)
Subject: 6 Meg Sun 2

I thought I would pass along a little experience we had here.  When we upgraded
our Sun 2/120 to Version 3.0 of the OS we were very disturbed by the slowness 
of the machine and the lack of memory available.  Since Our card cage only had
one extra slot, we couldn't get enough memory in the chasis using Sun memory.
We bought a 4Mb memory board from Helios Systems and that helped a great deal.
I thought I would pass this along, because I only know of 2 sources for such
memory, and Helios treated us very nicely. The prices were alot less than what
Sun would have charged for that much memory, and delivery was prompt (1 week?).

I have no afiliation with Helios other than a customer, and I only represent me.

Lee A. Butler
Space Telescope Science Institute   3700 San Martin Dr.   Baltimore MD 21218
Arpanet: butler at stsci.arpa
 Usenet: {noao,astrovax,cfa,charm,osiris,nrao1,jhunix}!stsci!butler
  Phone: (301) 338-4531

-----------------------------

Date: Sat, 4 Oct 86 11:39:22 CDT
From: oddjob!bose!sra at anl-mcs.arpa (Scott Anderson)
Subject: Re: Sharing /usr/spool/mail on NFS (1)

I was interested to see that no one suggested the implementation of
shared mail that we are using.  In our case, we have a file system
for local software, etc. which all clients mount; /private/spool/mail
is then a link back to a mail directory in this file system (the
spooling directory itself does not need to be made common, as someone
suggested).  Because the mailboxes can't be written by the client
sendmail daemons, we forward all mail from the clients to the server.
This is accomplished by modifying the clients' sendmail.cf files so that
whenever the mail evaluates to local, it gets passed instead to the
server.  There are at least two such places this occurs, and the lines
look like this:

R@                      $#local $:$n                    handle <> form
R$+                     $#local $:$1                    local names

The modified lines are:

R@                      $#ether $@server $:$n at server    forward to user at server
R$+                     $#ether $@server $:$1 at server    forward to user at server 

The server must know who the users are so that the mailboxes have the
correct ownership; we have all users in /etc/passwd, but have a permanent
/etc/nologin file to restrict access (but beware of the "rm -f /etc/nologin"
in /etc/rc!)

One  modification must be made to the server's configuration file to
prevent loops (for example, if someone has a .forward file pointing
to a client), and that is to alias all client names to be local; this
can be done by setting the w class appropriately, e.g.

Fw/etc/hosts.equiv

One might also set up out-going mail to include a "Reply-to:" header
line with the server's name; this will direct all return mail to the
most reliable sun.

One minor problem with this approach is that on-line users do not get
notified by comsat when mail arrives; they can, however, set the csh
"mail" variable, which is usually satisfactory.  Anyone for an "rcomsat"
daemon?

					Scott Anderson
					ihnp4!oddjob!control!sra

-----------------------------

Date: Thu, 9 Oct 86 10:48:17 CDT
From: symcom!maeder at a.cs.uiuc.edu.arpa (Roman E. Maeder)
Subject: Re: Sharing /usr/spool/mail on NFS (2)

We are a new Sun installation here at UIUC. So I missed the original posting
asking about sharing /usr/spool/mail. ( I was busy setting up our news system
then). As our workstations are used in a classroom environment, I had to solve
this problem too, as people would log in on any available machine. All our
machines are equivalent in the sense of a central yp-server and entries in
/etc/hosts.equiv. (The default sun setup has a local mail spool directory
on all machines. You dont see your mail unless you login on the machine
where the mail happens to have been delivered).

Some of the proposed ways of setting up a shared mail directory have their
drawbacks:

- making the kernel modification 'root over the net' is out of the question,
  as it is no problem at all to become root on a workstation. This would
  compromise any security left.

- hacking the source of /bin/mail is not very pleasing too. 

The solution I implemented parallels most of the ideas of 
mcvax!daimi!pederch at seismo.CSS.GOV (Peder Chr. N|rgaard), see
SUN-SPOT DIGEST 4: 29

Only I don't write my own sendmail but use the sendmail configuration
to send all local mail to our mailhost instead of delivering locally.
That's what sendmail.cf is intended to do: to give you flexibility.
As sendmail.cf is considered something of a black art by many, I will
summarize exactly what I did. The description of sendmail in Appendix D
of the "System Administration for The Sun" was of great help.

Assume the following configuration:
- one mail server (happens to be our disk server) named 'symcom'
- some (diskless) clients, named antares, capella, sirius, ...
- all machines 'equivalent' and in one room.
- you want to have mail from wherever you log in.
- all mail wherever it was written should look as if originating
  from 'symcom'.

In the following, lines from the new sendmail.cf will be prefixed with
">", quotations from the original sendmail.subsidiary.cf by "<".
At the end of this note is a complete diff
of my sendmail.cf and of sendmail.subsidiary.cf

1) make /usr/spool/mail to be /usr/symcom/spool/mail, i.e.
   NOT a symbolic link to /private/usr/spool/mail.

   This will already allow anybody to read new mail from any machine, as
   the directory /usr/symcom is a writeable NFS-file system mounted by
   all clients (SUN 3.0 setup).

2) sending mail does not work, as /bin/mail which is used to deliver local
   mail is setuid root and a client's root has no privileged access to a
   NFS filesystem.

3) hack the client's sendmail.cf to deliver all LOCAL mail via ethernet to
   the mailhost instead:

3.1 define a new mailer 'etherl' that is used to send local mail to the
    mailhost:

    > Metherl, P=[IPC], F=msDFuCX, S=12, R=22, A=IPC $h

    It does not specify the flag 'M', so no mail header will be generated
    (this will be done in the mailhost). It has rulesets 12 and 22 for
    address postprocessing that differ from the sets 11 and 21 in the
    original 'ether' mailer definition because we don't want to tack
    on the hostname of the sending client to addresses. S12 is empty, btw.

    > S22
    > R$*<@LOCAL>		$@$1		remove ugly LOCAL

3.2 define the relay mailer to be etherl:

    > DMetherl

3.3 In ruleset 0 which finds out which mailer to use, change all instances
    of  '$#local' to '$#$M $@$R' which means to send to mailhost  using 'etherl'
    (the macro $M has been defined in step 3.2)

3.4 hack ruleset 6 which finds out which addresses are really local
    to cope with cases where mail is addressed specifically to one of the
    local machines (as in 'user at sirius').
    Define a class of local machines to comprise all clients:

    > CDantares capella prokyon sirius

    and add the following rules to S6:

    > R$*<@$*$=D>$*		$1<@$2LOCAL>$4		convert local domain
    > R$*<@$*$=D.$U>$*		$1<@$2LOCAL>$4		or full domain name
    > R$*<@$*$=D.uucp>$*	$1<@$2LOCAL>$4		old style

    this handles all cases like 'user at sirius', 'user at sirius.uucp' and
    'user at sirius.<our-domain>'

3.5 To prevent sendmail from generating a 'Received:' header, define
    a new mailer flag 'a' and append this to all mailer definitions EXCEPT
    etherl.
    make the header 'Received:' conditional:

    > H?a?Received: $?sfrom $s $.by $j ($v/$V)

4) On the mailhost, similar changes are made to prevent it from sending
   incoming mail addressed to one of the clients to this client.
   Just apply changes 3.4 to sendmail.main.cf
   This mail will then be delivered locally on the mailhost.


Here comes the diff of my sendmail.cf and of sendmail.subsidiary.cf
You shoud of course replace names like symcom, antares, .. by your
own dull host names.

diff /usr/lib/sendmail.subsidiary.cf /private/usr/lib/sendmail.cf
26,28d25
< # local UUCP connections -- not forwarded to mailhost
< CV
< 
33c30
< DMether
---
> DMetherl
38a36,38
> # uucp connection for this particular machine
> CV
> 
52,53c52,53
< DDsun
< CDsun
---
> DDsymcom
> CDsymcom
54a55,58
> # other hosts on the local ethernet, that have no separate identity.
> # deliver locally
> CDantares capella prokyon sirius
> 
56c60
< DUuucp
---
> DUmath.uiuc.edu
149c153
< HReceived: $?sfrom $s $.by $j ($v/$V)
---
> H?a?Received: $?sfrom $s $.by $j ($v/$V)
250c254
< ##### special local conversions
---
> ##### special local conversions all names on local net are local
253a258
> R$*<@$*$=D.uucp>$*	$1<@$2LOCAL>$4			old style
288a294
> # new mailer flag: a generate 'Received' header
290c296
< Mether,	P=[IPC], F=msDFMuCX, S=11, R=21, A=IPC $h
---
> Mether,	P=[IPC], F=msDFMuCXa, S=11, R=21, A=IPC $h
291a298
> 
297a305,311
> # ether for connection to mailhost. Dont append hostname in ruleset 12
> # dont generate message Id
> Metherl, P=[IPC], F=msDFuCX, S=12, R=22, A=IPC $h
> S12
> # None needed.
> S22
> R$*<@LOCAL>		$@$1				remove ugly LOCAL
299a314
> 
338,339c353,354
< Muucp,	P=/usr/bin/uux, F=sDFMhuU, S=13, R=23,
< 	A=uux - -r $h!rmail ($u)
---
> Muucp,	P=/usr/bin/uux, F=sDFMhuUa, S=13, R=23,
> 	A=uux - $h!rmail ($u)
388c403
< R$*<@LOCAL>$*		$1<@$D.$U>$2			host == domain gateway
---
> #R$*<@LOCAL>$*		$1<@$D.$U>$2			host == domain gateway
404a420,422
> # send LOCAL to mailhost, as the net is ONE mail-machine
> R$*<@LOCAL>$*		$#$M    $@$R $:$1
> 
416,417c434,435
< # everything else is a local name
< R$+			$#local $:$1			local names
---
> # everything else is a local name deliver to mailhost
> R$+			$#$M    $@$R $:$1		local names


************ e o d (End Of Diff) ************

Have fun!

Roman E. Maeder
Dept. of Mathematics			UUCP:     ...!uiucuxc!symcom!maeder
Univ. of Illinois at Urbana-Champaign	Internet: maeder at math.uiuc.edu

It is now pitch dark. If you proceed you are likely to be eaten by a grue.

-----------------------------

Date: Tue, 7 Oct 86 14:20:56 PDT
From: quintus.uucp!goedel!harker at sun.com.arpa (Robert Harker)
Subject: Re: NFS between Sun 100's and Sun 3's (1)

The problem you are having with your Sun 100's and your Sun3's sharing files
with the NFS is not related to your older Sun hardware, but with the 3-Com
Ethernet board that Sun OEM'ed.  The problem is that the 3-Com Ethernet board
only has two buffers to store single Ethernet packets.  In the 68010 Sun
hardware this was not a problem because the sending CPU could never send 3
back-to-back Ethernet packets and the receiving CPU was able to process the
packets before both buffers were filled.  The new 68020 Sun3's have more than
enough power to send 3 back-to-back Ethernet packets, and will do so with any
file, directory, or transmission over 2K.  The real solution is to replace
your 3-Com Ethernet board with a Sun Ethernet board which has 256K bytes of on
board memory.  This is the real solution since the 3-Com Ethernet boards will
probably cause problems with future Sun software releases, and Sun has a poor
track record of supporting its older hardware.  You should order the second
Ethernet option instead of the 3-Com upgrade because they are the same price
and you don't have to return your 3-Com Ethernet board.

The second solution is to upgrade the system software of your Sun2 with a 3-Com
to the newest 2.3 Sun software release.  This has many fixes to the different
routines that receive packets over the Ethernet.  In addition you will have to
mount the Sun3 file system on the Sun2 with a read block size of 2K.  If you
mount a file system from the Sun2 on the Sun3 you will have to mount it with a
write block size of 2K.

My Sun2-3Com /etc/fstab file entry looks like this:
Sun3:/Sun3      /Sun3   nfs   rw,hard,noquota,bg,rsize=2048    0 0
And my Sun3 /etc/fstab file entry looks like this:
Sun2-3Com:/Sun2-3Com    /Sun2-3Com   nfs   rw,hard,noquota,bg,wsize=2048    0 0 

Also if you are running Sun2 diskless clients with 3-Com Ethernet boards from
a Sun3 server there is a new field int the /etc/nd.local file to tell the
Sun3 server that the client can only accept a fixed number of back-to-back
Ethernet packets.  A "2" in this field tells the server that it can only
send two back-to-back Ethernet packets (for the 3Com Ethernet board).
A nd.local entry for a Sun2-3Com client looks like this:
user Sun2-3Com 0 /dev/xy0c 149040 19320 1 2

I hope this solves your problems
RLH
harker at quintus.uucp
...!sun!quintus!harker

-----------------------------

Date: Sat, 4 Oct 86 12:00:11 CDT
From: oddjob!bose!sra at anl-mcs.arpa (Scott Anderson)
Subject: Re:  NFS between Sun 100's and Sun 3's (2)

> I have a Sun 3/160 (Unix 3.0) and a Sun 150U (Unix 2.2), both with disks and
> each a fileserver for other workstations of its own CPU type, that are
> trying to share files via NFS.

If the Sun-1 has the older 3COM board, it must be running Release 2.3
or higher to share NFS file systems with a Sun-3, not 2.2 as suggested
by Sun's documentation (we learned this by hard experience).

					Scott Anderson
					ihnp4!oddjob!control!sra

-----------------------------

Date: Mon, 6 Oct 86 18:18:48 -0100
From: R.Tobin at uk.ac.edinburgh@ucl-cs.arpa (Richard Tobin)
Subject: sun: terminal too dumb

given that cmdtool (understandably) doesn't provide any cursor movement
commands, wouldn't it be a good idea if it set TERM to something other
than 'sun'?  since TERMCAP is not propogated by rlogin (any good reason
why not?), remote machines will attempt to use the standard shelltool
escape sequences, with the expected consequences.

Richard Tobin,                      JANET: R.Tobin at uk.ac.edinburgh             
AI Applications Institute,          ARPA:  R.Tobin at uk.ac.edinburgh@ucl-cs.arpa 
Edinburgh University.               UUCP:  ...!ukc!edinburgh.ac.uk!R.Tobin

-----------------------------

Date: Tue, 7 Oct 86 22:12:38 cdt
From: ables%pp at mcc.com.arpa (King Ables)
Subject: ie0: no carrier

We, too, had this problem, but in our case it was the CPU
board.  It doesn't sound like that's your problem, but if
you have the problem again and what you've done up to now
doesn't help, try swapping two boards and see if the problem
migrates*.

It, of course, can be a bad cable, but that problem would
keep you from getting anything useful done.  In our case, 
it was only an annoyance.  There was no detectible loss
of functionality (Sun also told us not to worry about it
since it wasn't hurting us, but it became too much of an
annoyance!).

We periodically get the NFS server not responding/NFS server ok
pair of messages, but that's just because the server is under
duress as far as I can tell (backups or somebody generating
lots of output).

-King
ARPA: ables at mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucbvax}!ut-sally!im4u!milano!mcc-pp!ables
-------
* "Are you suggesting that CPU boards migrate?!"
  "No, the pidgeons could 'ave it on a line between them!"

-----------------------------

Date:  8 Oct 1986 1735-PDT (Wednesday)
From: trwrb!trwspp!spp2!hull at ucbvax.Berkeley.EDU.arpa (D. L. Hull)
Subject: mods to ttysw to allow boldfacing/underlining/reverse video

I've made some changes to the ttysw package of the suntools library to
allow boldface, underlined, and reverse video text.  If one recompiles
suntools with this new library and updates the termcap entry for "sun,"
these features become available to all programs which run in shelltool
windows.

Underlining and reverse video are done in the obvious ways.  But for
boldfacing, instead of writing each character, then shifting it over and
writing it again (like Sun does if you select Bold_style to be
Offset_xxx in SunView defaults), I put a boldface version of the font
in the upper 128 characters of that font, and the boldface escape
sequence just selects the upper half of the font.  Therefore, if you
put italic characters in the upper half of the font, your boldfacing
will actually appear in italics.

These changes haven't been extensively tested yet, but if you're
interested in getting as set of the diffs (from the Release 3.0 ttysw
source) as soon as I get them in shape, send me e-mail at
{ucbvax|decvax}!trwrb!trwspp!spp2!hull.  Note that these diffs won't do
you any good unless you have a source license.

				       ----------------------------------------
				       David Hull  TRW, Inc.  Redondo Beach, CA
				      ...{ucbvax|decvax}!trwrb!trwspp!spp2!hull

-----------------------------

Date: 06 Oct 86 09:34:20 EDT (Mon)
From: flanagan at amvax.tn.cornell.edu.arpa (Douglas Flanagan)
Subject: 1/2 inch tape drives?

The Lab. of Nuclear studies at Cornell is selling their Vax 11/750
and replacing it with additional SUN 3 equipment. We would like to
move several devices from the Vax to our Sun 3/160, especially the
1/2 inch tape drive. What we need to know is whether the drive we
currently own can be made to work with the 3/160, and if so, what
controller we need to buy. The tape drive is the CDC 92181 Streaming
Tape Unit, model BY3A6-A10. The drive we have was bought from
Emulex. I understand this drive is the same piece of hardware as
a DEC TU80. Our Sun sales rep. is 99% (not 100% mind you) sure that
this drive is the same one Sun sells. He also "thinks" the controller
we want is the Xylogics 472. Can anyone confirm or refute this 
information? I'd love to hear from someone who actually is using
this drive on their Sun 3. Please reply via email. Thank you.

			Douglas Flanagan, Systems Grunt
			233 Newman Lab. of Nuclear Studies
			Cornell U., Ithaca, N.Y. 14853
			(607) 255-3707

		flanagan at amvax.tn.cornell.edu
		{decvax,ihnp4,cmcl2,vax135}!cornell!amvax!flanagan

-----------------------------

Date: Mon, 6 Oct 86 10:45:35 EST
From: mckay at courageous.ecn.purdue.edu.arpa (Dwight D McKay)
Subject: ditroff previewer for SUNs (1)

We've recently installed a cluster of SUN workstations and I was wondering
if there's a public domain ditroff previewer for the SUN.  I've used one
called "proof" on a 5620 and would like one on the SUN but I don't want to
reinvent the wheel if I can help it.  Pointers to ftp'able source, binary
or even commercial ditroff previewers for the SUN would be appreciated.

--Dwight Mckay, ECN Text & Workstation Software Support
[arpanet: mckay at ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay]
[Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561]

-----------------------------

Date: Sat, 11 Oct 86 14:37:55 EDT
From: km%emory.csnet at csnet-relay.arpa (Ken Mandelberg)
Subject: Troff Preview on Sun (2)

What is available in the way of troff/ditroff previewing programs
for the Sun? 

-----------------------------

Date: Mon, 6 Oct 86 12:44:00 +0100
From: enea!suadb!anders at seismo.css.gov.arpa (Anders Bj|rnerstedt)
Subject: PostScript tool (3)

We are in need of a previewer for troff documents.
Since we have a LaserWriter the ideal thing would be some kind
of PostScript tool, i.e. a window under SunWindows which could
generate one page after another from some stream of PostScript.

Has anyone implemented such a thing, or something similar ?

  Anders Bjornerstedt
  Department of Information Processing & Computer Science
  University of Stockholm
  S-106 91  Stockholm
  Sweden

UUCP:	{seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc,unido}!enea!suadb!anders
ARPA: enea!suadb!anders at seismo.arpa

-----------------------------

Date: Mon,  6 Oct 86 16:19:03 CDT
From: rbbb at rice.edu.arpa (David Chase)
Subject: Slow NFS synchronization?

Occasionally I have observed that it takes several minutes for a file's
new size to propagate via NFS from one (very lightly loaded) Sun 3 to
another (very lightly loaded) Sun 3.  Both machines are running "Sun UNIX
4.2 Release 3.0".

I observe this behavior in two ways; dvitool chokes trying to read near
the end of a .dvi file written on another machine and "ls -l" reports
different sizes for the file on different machines.  However, an "od" of
the file on different machines reports identical information.  The
difference in the file's reported size persisted for at least three
minutes, through several invocations of "ls -l" on both machines, two
"od"s, and a "cp" on the remote machine.  After a while, the two machines
agreed on the file's size.  I have tried to recreate this problem, but it
does not appear on demand.  However, when it last happened to me I had a
window into each machine and I was able to look at everything very
carefully, so I am sure that it did in fact happen.

Has anyone seen similar behavior?  Is there a sleazy workaround that I
can add to dvitool that will force a machine to update its cached
information?

David

-----------------------------

Date: Tue, 7 Oct 86 10:50:07 EDT
From: primerd!bobsun!bob at eddie.mit.edu.arpa (Bob Pellegrino)
Subject: mailtool questions?

Our mail has been down for a couple weeks due to faulty installation of
rev 3.0, so forgive me if any of these questions have been answered already.

Is there any way to configure the mailtool defaults so that you don't get
all that header information with every mail message. (simply eliminating
all those "Received From:" lines would be fine.)  I used to be able to
toggle long/short header from the mail reader in Gosling's/Unipress Emacs.

Has anyone else noticed that the mailtool icon doesn't always change to the
"New Mail" form when it should?  I find I can't rely on it at all.  Sometimes
the flag will go up when someone sends me one message, and other times I'll
come back after a day's worth of messages have accumulated and the icon 
doesn't show that I have any new mail.  What am I doing wrong?

Finally, since I have missed a digest or two where these questions may have
been answered, where can I find the archives?

Thanks for your help,

Bob Pellegrino
Prime Computer

decvax!genrad!mit-eddie!primerd!bobsun!bob (UUCP)

pellegrino at bbna (ARPA)

-----------------------------

Date: Tue, 7 Oct 86 14:24:38 EDT
From: sean at cadre.dsl.pittsburgh.edu.arpa (Sean McLinden)
Subject: Driver for Xylogics 772 controller?

Is anyone aware of SunOS (Release 3 or better) driver for the Xylogics
772 VME Tape Controller. Xylogics has one that is partially finished but
Sun seems to be in no hurry to move toward true VME based peripherals and
Sun Consulting would probably cost an arm and a leg.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh

-----------------------------

Date: Wed, 8 Oct 86 15:10:41 cdt
From: hi-csc!giebelhaus at umn-cs.arpa (Timothy Giebelhaus)
Subject: 8 character login names?

You can see that my login name is "giebelhaus".  If I attempt to
"rlogin -l giebel" onto the sun, it fails.  It looks like it passes
both the name I want to log in under and the name I am logged in
under.  The name I am logged in under is too long so it fails.
Does anyone have a fix for this?  Of course, what I would really
like is to have longer names on the Sun, but I'll settle for it
not tossing out remote long names.

Giebelhaus at hi-multics.ARPA
ihnp4!umn-cs!hi-csc!giebelhaus.UUCP

-----------------------------

Date: Tue, 14 Oct 86 11:57:17 MET
From: jochen%germany.csnet at csnet-relay.arpa (Jochen Grobholz)
Subject: Problems with mmdfII on SUN workstations?

I have problems to install the mmdfII-software on a sun-workstation.
The first bug was a nil-pointer in the file ap_util.c, but this bug I
had removed. Now I get the error message ,,Problem in do_an_address [EOF]''
when put a name in the field ,,To''. During the address check the program
made a mistake. Do anyone have experience with this problem, please
write to
           jochen at germany.csnet
Thanks
        jochen

-----------------------------

Date: 01 Oct 86 16:58:22 PDT (Wed)
From: petel%teksce.gws.tek.csnet at csnet-relay.arpa (Pete Lancashire)
Subject: Cipher 920 Tape?

I'm looking for anyone who has put a Cipher 920 9Track tape transport
on a SUN 3/160 with a Xylogics 472 Pertec controller.

Pete Lancashire   uucp: ...!tektronix!tekgen!teksce!petel

-----------------------------

End of SUN-Spots Digest
***********************



More information about the Mod.computers.sun mailing list