Sun-Spots-Request@RICE.EDU (Vicky Riffle) (10/14/86)
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@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@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@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@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@buffalo ARPA : hull%buffalo@csnet-relay ----------------------------- Date: Mon, 6 Oct 86 18:54:29 PDT From: mr-frog@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@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@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@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@server forward to user@server R$+ $#ether $@server $:$1@server forward to user@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@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@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@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@sirius', 'user@sirius.uucp' and 'user@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@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@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@quintus.uucp ...!sun!quintus!harker ----------------------------- Date: Sat, 4 Oct 86 12:00:11 CDT From: oddjob!bose!sra@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@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@uk.ac.edinburgh AI Applications Institute, ARPA: R.Tobin@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@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@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@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@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@amvax.tn.cornell.edu {decvax,ihnp4,cmcl2,vax135}!cornell!amvax!flanagan ----------------------------- Date: Mon, 6 Oct 86 10:45:35 EST From: mckay@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@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@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@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@seismo.arpa ----------------------------- Date: Mon, 6 Oct 86 16:19:03 CDT From: rbbb@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@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@bbna (ARPA) ----------------------------- Date: Tue, 7 Oct 86 14:24:38 EDT From: sean@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@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@hi-multics.ARPA ihnp4!umn-cs!hi-csc!giebelhaus.UUCP ----------------------------- Date: Tue, 14 Oct 86 11:57:17 MET From: jochen%germany.csnet@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@germany.csnet Thanks jochen ----------------------------- Date: 01 Oct 86 16:58:22 PDT (Wed) From: petel%teksce.gws.tek.csnet@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 ***********************