Sun-Spots-Request@Rice.edu (William LeFebvre) (11/10/88)
SUN-SPOTS DIGEST Wednesday, 9 November 1988 Volume 7 : Issue 10 Today's Topics: Re: Remote booting a Sun-3/280 -- failure! Re: emergency bootables Re: TTY Windows in SunView Re: UU[EN|DE]CODE troubles Summary of troff previewers for the Sun GNU-EMACS 18.51 and 386i 386i's MS-DOS emulator and Postscript output not playing with a full deck Sun 4/110, OS4.0 Crashes Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Tue, 1 Nov 88 20:45:39 PST From: pyramid.com!leadsv!hart@cs.utexas.edu (Howard Hart) Subject: Re: Remote booting a Sun-3/280 -- failure! Reference: v6n273 > problem is that when standalone copy is running, we try: > > From: ie(0,80c65,0)minifs > > and it doesn't work. The above instructions were a typo on Sun's part. It should be: From: ie(0,80c65,1)minifs Where 1 is the number of the public partition, which is most likely the same for most systems. There was one more typo a couple of lines down under section B.9. It should read as below for the same reasons (I may be wrong on this but its easy to try out.) : > b ie(0,80c65,1)boot -a The writeup is buried in the README first for OS 3.2, page 3 I saw Greg Wood's response in v6n334 and he's probably right about class A, B and C incompatibilities, but I got exactly the same results on my class C network where the previous stand/copy worked fine but the minifs didn't. Try it and see. Howard C. Hart Lockheed Missiles and Space Co. Orgn 59-53, Bldg 593 Sunnyvale, CA 94086 (408) 743-2253 uucp: sun!sunncal!leadsv!hart ------------------------------ Date: Wed, 2 Nov 88 11:34:20 EST From: frank@morgan.com (Frank Wortner) Subject: Re: emergency bootables Jay Albert <albert@mssun7.msi.cornell.edu> wrote: >As a new SysAdmin, I am nervous about our disks. I would like to be able >to reboot our Sun3/260 server and 4 Sun3/50 clients off of any of them if >one or more fail. > [...] >I have copied our kernel vmunix, as well as diag and boot, into >directories in [3 different disks on the server] >Will they be usable if Doomsday comes, and is there anything else I should >do? It depends on what kind of a Doomsday scenario you are envisioning. Unless you take further steps, those kernel copies will only insulate you from problems resulting from the deletion of those particular files. I.e., if someone says "rm /vmunix", you could still boot, albeit painfully. However, boot, diag and vmunix aren't the only critical files in SunOS (or Un*x). Removing /bin/sh and/or /etc/init will also render a system quite unbootable. There are quite a number of disk/file trashing scenarios that can turn a computer system into a noisy paperweight. We haven't even begun to talk about hardware failures yet. I think you'd be better off with a copy of your entire root disk. It's simpler to set up, and (I believe) more foolproof. Let's say you normally boot from /dev/xy0a. Make another root partition on /dev/xy1a or /dev/xy2a (etc.). Add to that a swap partition on those disks (/dev/xy1b and/or /dev/xy2b). Now create a kernel that can boot and swap on the various partitions, and you're in business. I have such an arrangement myself. While it's not the ultimate, it certainly does work. I've tried it -- happily only as an experiment. In any event, it pays to be able to have more than one recovery plan. You should have at least one copy of the distribution tape handy. If your disk dies, and your extra disk-based copies of the OS are trashed, you will need to start somewhere. Frank P.S. All recovery plans RELY ON BACKUPS. I've found out the hard way. ------------------------------ Date: Wed, 2 Nov 88 15:02:34 CST From: hsc@vuse.vanderbilt.edu (Hsuan Chang) Subject: Re: TTY Windows in SunView Paul R. Jordan writes: > ...Is there a hard limitation on the number of TTY windows in one > application ?... and Ellery Chan replies recently: > The different SunView window objects use up file descriptors, of which > your program has a finite number (probably ~30). There is a handy table > on p.54 of the SunView Programmer's Guide that says: ... I would like to add that Ellery was referring to the old manual for SunOS 3.x. For SunOS 4.x, the file descriptor has been increased to 64. (check manual page 57 of the new SunView Programmer's Guide. - hsc@vuse.vanderbilt.edu Hsuan Chang Image Processing Lab Computer Science Dept Vanderbilt University Box 1679, Station B. Nashville, Tn 37235 ------------------------------ Date: Thu, 3 Nov 88 10:47:48 EST From: dph@jabba.psu.edu (David P. Huenemoerder) Subject: Re: UU[EN|DE]CODE troubles Reference: v7n1 There is a character translation solution that I have come across in the Atari ST networld. It is a version of uuencode (the Dumas version) which puts a character translation table before the "begin" line, which uudecode reads. So if a site uses a funny table, its translation is included and will be properly decoded. This has solved all my troubles in downloading files through an IBM. It also has the additional features of breaking encoded files into user specified sizes and putting an "include <file>" at the end. Uudecode can then essentially "cat" all the encoded files itself while decoding. The table looks something like: table !"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ and the begin ... line follows. This version is backwards compatible with normal encoded files (as long as no characters got munged, but it knows something about valid characters), so you won't need two versions of uu[en|de]code. Sources have been posted. Don't ask me for them. Some places to look are: Bitnet: a file server in Houston: uh-info at uhupvm1 atarinet Internet anonymous ftp: umich (35.195.16.4) ssyx.ucsc.edu (128.114.133.1) I don't know if this has propagated to other computer groups. David Huenemoerder internet: dph@astro.psu.edu ------------------------------ Date: Wed, 2 Nov 88 12:02:04 PST From: ucdavis!csusac!csun!polyslo!gshute@ucbvax.berkeley.edu (Glenn C. Shute) Subject: Summary of troff previewers for the Sun Thanks to everyone for your replys. Here is a summary of troff previewer's for the Sun. =================================================== As we all know by now X11 Release 3 sources include a troff previewer for the Sun in the user contributed section. Many people use suntroff and find the "EXCELLENT" it was made available on Sun User Group (SUG) tape no. 2. ximpv X Imagen previewer - It requires that you use iroff - SLOW xproof Displays ditroff output. Plays some funny games with fonts, but is much faster than ximpv. Both of these can display ditroff graphics, as produced by pic, and picgraph, etc. Neither can handle Postscript. There is supposedly a Postscript previewer, xps.... Elan Computer Group, Inc. sells a package called EROFF which is the AT&T Documenter's WorkBench (DWB), including device independent troff, nroff, tbl, eqn, pic, grap, macros, etc., plus bug fixes and enhancements including bitmap graphics inclusion, and drivers for the HP LaserJet line of printers and PostScript printers (an Imagen driver is also available). Automatic HP Soft Font downloading is done for the LaserJets. Downloadable Adobe PostScript fonts may also be used. DWB and the printer drivers are also available separately. All of this is available on dozens of different UNIX machines and under MS-DOS. Our soft copy screen previewer EVIEW is available for Suns under SunView, many systems under X-Windows V10R4, and support for X11 is in progress. All of DWB 2.0 and EROFF's enhancements are supported by EVIEW. Jeff Lo Elan Computer Group, Inc. 410 Cambridge Avenue, Suite A Palo Alto, CA 94306 (415) 322-2450 ..!{ames,hplabs,uunet}!elan!jlo ========================== Our troff users thank you. Personally I use the texx previewer under X and find very easy to use. I have nothing to compare it to, but it does seem slow. Glenn C. Shute Computer Science Department Cal Poly, SLO. Ca. gshute@polyslo.CalPoly.EDU or {csun,voder,trwind}!polyslo!gshute ------------------------------ Date: Wed, 2 Nov 88 07:55:06 CST From: Jody Winston <shell!jody@gazette.bcm.tmc.edu> Subject: GNU-EMACS 18.51 and 386i On of the "features" of the 386i is a "new and improved" keyboard. The keypad not only has more keys than the Sun-3 style keyboard, but some of the keys generate diferent escape sequences. This can cause problems if you use GNU-EMACS and the terminal file sun.el. The following keys on the 386i do not work: R1-R6, R8, R10, R12, R14, Ins, Del, Enter, +, -, and Num Lock. I fixed the problem in the following manner: [[ Most of this article was a bunch of Gnu emacs functions. The entire text of the artice can be found in the archives under "sun-source" (since it is mostly source) as "386i.gnuemacs.keys". It is 5781 bytes long. It can be retrieved via anonymous FTP from the host "titan.rice.edu" or via the archive server. For more information about the archive server, send a mail message containing the word "help" to the address "archive-server@rice.edu". --wnl ]] These additions allow the complete use of the 386i keypad and displays the status of the num lock on the mode line. ------------------------------ Date: Wed, 2 Nov 88 12:14:15 CST From: Jody Winston <shell!jody@gazette.bcm.tmc.edu> Subject: 386i's MS-DOS emulator and Postscript output The dos2unix command that is supplied with the 386i removes the extra carriage returns and fixes the end of line character in MS-DOS files, but does not remove other control characters that might be found in the file. Several PC products which produce Postscript output have control Ds in the file (^D). If this file is sent to a Postscript printer, the printer complains about the file and refuses to print it. I wrote a small C program that strips off the ^M, ^D, and ^Z in the MS-DOS file so that the file can be printed on a Postscript printer. #include <stdio.h> #define CTLM '\015' #define CTLD '\004' #define CTLZ '\032' #define INPUT 0 #define OUTPUT 1 main(argc, argv) int argc; char *argv[]; { char buffer[10]; register i; while (read(INPUT, buffer, 1) == 1) if ( (buffer[0] != CTLD) && (buffer[0] != CTLM) && (buffer[0] != CTLZ) ) write(OUTPUT, buffer, 1); } To use the program modify your setup.pc like this: # # # DOS DEVICE UNIX DEVICE PATH NAME # LPT1 xlate | lpr Where xlate is the name of the above filter program. Jody Winston jody@shell.uucp ...!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody Shell Development Company, Bellaire Research Center P.O. Box 481, Room 2202 Houston, TX 77001 (Voice: 713 663-2050) ------------------------------ Date: Wed, 2 Nov 88 18:52:10 CST From: thompson@umn-ai.cs.umn.edu (William B. Thompson) Subject: not playing with a full deck The following bug report was submitted directly to Sun, but I think that it may be important enough to forward to Sun-Spots: ____________________ There is a bug in canfieldtool that can cause serious difficuties. Twice now I have been about to win when canfieldtool has lost a card. Once it was a missing an 8 of clubs. Just now it was a missing a 5 of spades. My faith in the reliability of sun software (not to mention my general well being) has been shattered. I expect this grevious problem to be fixed IMMEDIATELY. The manual entry for canfield says: > BUGS > It is impossible to cheat. The entry should be changed to reflect the fact that while the user can't cheat, the program can and does! [[ Yeah! Just like gammontool! :-) --wnl ]] William B. Thompson University of Minnesota ------------------------------ Date: Wed, 2 Nov 88 08:55:32 MST From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory) Subject: Sun 4/110, OS4.0 Crashes I seem to be able to make my 4/110 crash in a number of unexpected ways. This particular machine is running with 20 MB of memory: 4 MB of the 256K SIMMS, and 16 MB of Helios. The system boots off of a CDC Wren-V (702 MB unformatted, ~602 MB formatted). The following are excerpts from /usr/adm/messages [[ I have stripped off the more-or-less redundant information at the front of each line except the first in each case. --wnl ]]: 1. I don't know what caused this one... Oct 22 19:18:17 candygram vmunix: cmdtool: Data fault kernel read fault at addr=0x400ce4, pme=0x70000000 Bus Error Reg 80<INVALID> pid=179, pc=0xf8034600, sp=0xffffec58, psr=0x800cc5, context=3 g1-g7: 800ce6, 4002e1, 4, 0, 0, 0, 0 Begin traceback... sp = ffffec58 Called from f8040ff8, fp=ffffecb8, args=400ce0 f80f8648 86 80 f80ee5e8 0 Called from f8035270, fp=ffffed18, args=ff04cd34 f80f8648 4002e0 80000000 ff04cd34 ff06c980 Called from f80441a8, fp=ffffed78, args=ff04ccec f80f8648 f8037304 0 4002e1 0 Called from f8042a64, fp=ffffedd8, args=ff04cd10 f80f8648 ff052ea8 1 f80f9968 ff0726fc Called from f8034b30, fp=ffffee38, args=ff04cd58 f80f8648 9002e3 86 4 f80f2f20 Called from f80416dc, fp=ffffee98, args=ff04cd58 86 3 0 4002a4 1 Called from f8035578, fp=ffffeef8, args=ff04cd34 f80f2c00 ff06c980 f80f8720 f812d208 f80415a0 Called from f8005544, fp=ffffef58, args=0 4000e0 1000 ff04cd34 f81301e8 0 Called from f776fa00, fp=f7fff050, args=3 4 f7fff02c 4024 4350 1 End traceback... panic: Data fault zs3: silo overflow syncing file systems... [3] 2 [3] [2] [2] done dumping to vp ff078028, offset 164180 2. This on occured while running format on the Wren-V (I was forced to format the disk on a Sun 3 running OS3.5)... Nov 1 10:17:39 candygram vmunix: sw0: swintr: ignoring spurious phase last phase= 0x8 (COMMAND) csr= 0x1405 bcr= 0 tcr= 0x4 cbsr= 0x6d (STATUS) cdr= 0x21 mr= 0x2 bsr= 0x0 target= 0, lun= 0 DMA addr= 0xf02000 count= 1024 (1024) cdb= 8 0 2 60 2 0 Can't invoke init, error 2 panic: icode syncing file systems... done dumping to vp ff053c28, offset 164180 sw0: sw_arb_sel: scsi bus continuously busy sw0: resetting scsi bus last phase= 0x87 (Cmd complete MSG) csr= 0x140d bcr= 0 tcr= 0x0 cbsr= 0x6d (STATUS) cdr= 0x0 mr= 0x0 bsr= 0x0 target= 0, lun= 0 DMA addr= 0xfbe000 count= 8192 (8192) cdb= a 2 c0 bc 10 0 3. This one occured while a tar was running in a shelltool, and GNU EMACS 18.52 emacstool was attempting to save a file. Nov 1 17:29:46 candygram vmunix: BAD TRAP emacs: Memory address alignment addr=0x1 pid=213, pc=0xf8072278, sp=0xffffebb8, psr=0x4000c4, context=0 g1-g7: 0, 4000e4, ffffffff, fffffffc, 44, 0, 0 Begin traceback... sp = ffffebb8 Called from f807240c, fp=ffffec20, args=63747572 14 4 13 63747572 0 Called from f807093c, fp=ffffec80, args=ff147ae8 1d 0 80000000 2 1e Called from f8076db8, fp=ffffece0, args=ff13dc20 ff13dc80 ff13dc80 1e ff13d274 ff147534 Called from f8072b10, fp=ffffed40, args=ff13dc20 5133c38 ffffff 4000e1 f810a018 ff13af6c Called from f802df2c, fp=ffffeda0, args=ff13af6c 1000 ff13af6c 0 f8088bb4 0 Called from f802caa4, fp=ffffee00, args=f8130438 f8130438 8401 4000a3 f8135c10 0 Called from f802ca18, fp=ffffee60, args=ff65b200 f80e8918 9 f8130438 80 20 Called from f80949d0, fp=ffffeec0, args=ffffefe0 f80d8588 f80d8588 1 ffffefb4 ffffefe0 Called from f8005960, fp=ffffef58, args=8000000 1 1000 1 1 8 Called from d0bbc, fp=f7fff2f0, args=0 1 1 f7fff2d0 1 12bc00 End traceback... panic: Memory address alignment syncing file systems... SunOS Release 4.0 (unix.candygram) #2: Mon Aug 29 16:58:40 MDT 1988 Douglas Roberts Los Alamos National Laboratory (505)667-4569 dzzr@lanl.gov ------------------------------ End of SUN-Spots Digest ***********************