Sun-Spots Digest, v7n9
William LeFebvre
Sun-Spots-Request at Rice.edu
Wed Nov 9 14:00:19 AEST 1988
SUN-SPOTS DIGEST Tuesday, 8 November 1988 Volume 7 : Issue 9
Today's Topics:
Re: single user while dumping (2)
Re: UUCP, bug or feature
Re: SunOS 4.0 dump
Re: Algebraic Calctool with Trig Functions
Re: detecting the use of fpa in executables
Re: Remote booting a Sun 3/280--failure
little bug in Fig 1.4
calculator tools
Exabyte Drive
NEC-890 PostScript printer for Sun
Callback for getty wanted
Tape mark (EOF) skipping problem with 1/4-inch tapes
Help! with RLL controllers...
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Tue, 1 Nov 88 10:21:50 PST
From: rodgers at maxwell.mmwb.ucsf.edu
Subject: Re: single user while dumping (1)
In v6n279, Jay Albert writes:
> The manuals all seem to say that you "should" be in single-user mode while
> making dumps, especially level 0 dumps. I have made some level 0's while
> in multi-user mode, with a handfull of people on (over several hours).
I wouldn't worry. Many responsibly managed sites do ONLY "live" (i.e.,
multi-user) dumps. The party line (and the word from Sun software
engineers) is that this is perfectly OK, although files active at the time
of the dump may not be retrieveable later by the restore command. This is
why, STRICTLY speaking, one should be in single-user mode for a level 0
dump. What is unclear to me at present is whether such files will or will
not be picked up by subsequent level 1-9 dumps (if, for example, a user is
editing a file during the level 0 dump session, and exits shortly after
the dump ends). We have had to rebuild our disk on several occasions
using such dumps and have never encountered a serious problem. If the
dump is done in the wee hours, the potential file loss is generally a
small price to pay for the convenience of not having to shut down.
R. P. C. Rodgers, M.D. Telephone:
Statistical Mechanics of Biomolecules (415)476-8910 (work)
Department of Pharmaceutical Chemistry (415)664-0560 (home)
University of California, Box 1204 E-mail:
Laurel Heights Campus, Room 102 ARPA: rodgers at cca.ucsf.edu
3333 California St. rodgers at maxwell.mmwb.ucsf.edu
San Francisco CA 94118 BITNET: rodgers at ucsfcca
USA UUCP:
...ucbvax.berkeley.edu!cca.ucsf.edu!rodgers
------------------------------
Date: Tue, 1 Nov 88 22:37:16 EST
From: attcan!utzoo!henry at uunet.uu.net
Subject: Re: single user while dumping (2)
They are better than nothing but not entirely reliable. Dump is taking a
snapshot of the filesystem; it is difficult to get a clear and consistent
snapshot of a moving target. The modern dump programs are safer in this
regard than the old ones, but if you want to be *sure* that your dump is
absolutely clean, it is still smart to run it single-user. We do.
Henry Spencer at U of Toronto Zoology
uunet!attcan!utzoo!henry henry at zoo.toronto.edu
------------------------------
Date: Tue, 1 Nov 88 15:43:46 EST
From: srs!matt at uhura.cc.rochester.edu
Subject: Re: UUCP, bug or feature
You can always "fake" the connection and do anything you want to the modem
by saying the connection is "DIRECT" and using the chat script to first
talk to the modem and dial the modem after setting whatever switches you
may need. Something like (from memory):
site Any DIR 2400 /dev/cua0 "" ATblahblahnumber ogin: uucp ssword: word
This only works for one device, so you have to set up multiple lines for
multiple devices (i.e. L-devices isn't used -- I think).
Anyway, it's what we did for a couple of years. Seems to work fine for
small sites with only one outgoing line...
uucp: {rutgers,ames}!rochester!srs!matt Matt Goheen
internet: matt at srs.uucp OR matt%srs.uucp at harvard.harvard.edu
------------------------------
Date: Wed, 2 Nov 88 12:34:13 EST
From: munnari!yabbie.rmit.oz.au!rcodi at uunet.uu.net (Ian Donaldson)
Subject: Re: SunOS 4.0 dump
Reference: v6n278
> seen the exhilarated articles on sun-spots declaring how wonderful it now
> is and I read the manual page. Great I thought, no more specifying
> ridiculous lengths to fool it into using all the tape. So you can
> understand my disappointment when it failed to work like it promised.
Honestly, this business of dump 'knowing' about tape densities is
rediculous.
You should be able to specify how many bytes (kilo or mega, like dd does
with 'bs') you can bang onto a tape using a given block size. Its trivial
to write a program to determine the numbers for a particular tape and once
you've determined it you keep using the same numbers again for all similar
tapes. You need to back-off a bit from what you do actually fit to cater
for tape variations. eg: I find you can quite often fit 64Mb onto a
DC600A tape, but sometimes it may be 63Mb.
Here's such a program (for block size of 1Mb but you could make that
variable too):
-------
#include <stdio.h>
#include <sys/file.h>
char bigbuf[1024*1024];
main(argc, argv)
char *argv[];
{
int f, count;
if(argc != 2) {
(void) fprintf(stderr, "Wrong! read the source\n");
exit(1);
/*NOTREACHED*/
}
f = open(argv[1], O_WRONLY);
if(f == -1) {
perror(argv[1]);
exit(1);
/*NOTREACHED*/
}
count = 0;
for(;;) {
int i;
i = write(f, bigbuf, sizeof(bigbuf));
if(i != sizeof(bigbuf)) {
perror("write");
(void) printf(
"write error, return code=%d, %d kbytes written ok\n",
i, count / 1024);
exit(1);
/*NOTREACHED*/
}
count += sizeof(bigbuf);
}
}
Trying to work out what dump is doing to the numbers you give it
internally when it tries to calculate how much will fit on a tape is a
pain.
Ian D
------------------------------
Date: Wed, 2 Nov 88 07:40:20 EST
From: Chuck Musciano <chuck at trantor.harris-atd.com>
Subject: Re: Algebraic Calctool with Trig Functions
You need look no farther than the sun-spots archives, and get a copy of
calctool. Calctool supports operator precedence, trig, logs, bitwise
stuff, scientific notation, hex and octal mode, multiple memories, accepts
keystrokes as well as mouse clicks, and lots of other stuff. I like it,
but then again, I wrote it :-)
Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck at trantor.harris-atd.com
------------------------------
Date: Tue, 1 Nov 88 20:48:04 PST
From: pyramid.com!leadsv!hart at cs.utexas.edu (Howard Hart)
Subject: Re: detecting the use of fpa in executables
Reference: v6n273
The simplest way is to just run the executable or the linked object files
on Sun without an fpa. If the code wasn't compiled with the fpa option,
you'll get the following error message almost immediately:
SUN FPA floating point not available -- program requires it
Along the same lines, you might want to tell your vendors to send you
object files and libraries compiled with the -fswitch option. Even though
it is slower, it avoids the hassle of code that's only executable on one
of your Sun architectures (i.e. - code compiled with the fpa option can
only be run on a 3/160/180/260/280 with an fpa, not on a 3/50/60 with a
math coprocessor, which requires use of the -f68881 option, which in turn
won't run on a 3/50 without a coprocessor, ad nauseum....).
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: Tue, 1 Nov 88 20:47:11 PST
From: pyramid.com!leadsv!hart at 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: 1 Nov 88 16:05 +0100
From: Igor Metz <metz at iam.unibe.ch>
Subject: little bug in Fig 1.4
I found a little bug in Fig 1.4, which causes only problems if you use Fig
1.4.FS together with Micah Becks TransFig. Here is the diff:
*** box.c.old Tue Nov 1 15:18:32 1988
--- box.c Tue Nov 1 15:42:29 1988
***************
*** 6,11 ****
--- 6,14 ----
* 1st revision : Aug 1985.
*
* %W% %G%
+ Tue Nov 1 15:40:38 1988 Igor Metz <metz at iam.unibe.ch>
+ Bug in create_boxobject fixed: depth will receive a initial value of 0 now
+
*/
#include <stdio.h>
#include <suntool/tool_hs.h>
***************
*** 104,109 ****
--- 107,113 ----
box->style = cur_line_style;
box->thickness = line_thickness;
box->color = cur_color;
+ box->depth = 0;
box->pen = NULL;
box->area_fill = NULL;
box->style_val = cur_styleval;
------------------------------
Date: Tue, 1 Nov 88 09:56:04 PST
From: rodgers at maxwell.mmwb.ucsf.edu
Subject: calculator tools
In v6n279, Mark Frydenberg writes:
> Does anyone know of a calctool with operator precedence (i.e., 2+3*4+5 =
> 19, NOT 25) and trig functions, logarithms, and other assorted goodies?
The public domain front-end for bc/dc by Dave Hartwell, known as calctool,
satisfies the above requirements. It was supplied on the first Sun User's
Group (SUG) tape (contact: hartwell at lll-lcc.llnl.gov). However, we MUCH
prefer the Reverse Polish-style calctool of Ed Falk, which is very much
like a complete Hewlett-Packard scientific calculator (contact:
falk at sun.com). The other tool of which we are aware, by Rich Burridge, is
algebraic but does NOT follow the above operator precedence rules
(contact:richb%sunk.oz at seismo.css.gov).
R. P. C. Rodgers, M.D. Telephone:
Statistical Mechanics of Biomolecules (415)476-8910 (work)
Department of Pharmaceutical Chemistry (415)664-0560 (home)
University of California, Box 1204 E-mail:
Laurel Heights Campus, Room 102 ARPA: rodgers at cca.ucsf.edu
3333 California St. rodgers at maxwell.mmwb.ucsf.edu
San Francisco CA 94118 BITNET: rodgers at ucsfcca
USA UUCP:
...ucbvax.berkeley.edu!cca.ucsf.edu!rodgers
------------------------------
Date: 1 Nov 88 20:37:30 GMT
From: bmh at cs.unc.edu (Brad Hemminger)
Subject: Exabyte Drive
We are considering buying an Exabyte drive and I would like to hear from
some of you who have them. Specific things I'm interested in finding out
are
1) What supplier did you order unit from and what guarantee and materials
(manuals, driver, etc.) did you receive?
2) what Unix utilities work with Exabyte?
3) How is it error wise? I.e. 10^13 seems a little on the low side to me.
(Especially compared to the VHS Gigastore on our Vax which quotes it's
error rate at 10^23).
4) How much do you find you can actually store on 1 tape; and how does
this relate to the number of files on the tape. E.g. on other helical
scan devices (like the Gigastore) large amounts of potential storage space
is wasted between seperate files on the tape.
Thanks,
Brad Hemminger
Dept of Radiology
bmh at dopey.cs.unc.edu
------------------------------
Date: Wed, 2 Nov 88 11:23:20 EST
From: esmith at brazil.psych.purdue.edu
Subject: NEC-890 PostScript printer for Sun
Mark Lawrence (v6n278) says the NEC-890, a nice and relatively inexpensive
PostScript printer, generates signal levels that are incompatible with the
Sun serial port, so you need a serial-to- parallel conversion box to
connect it. Well, ours work fine with just null-modem cables (pins 2-3
reversed, 7 straight through) on both a 3/50 and a 3/60. With the
Transcript software, printing any job on a PostScript printer involves
getting several messages from the printer (status reports, page counts,
etc.) so if they were not getting through, nothing would work. XON/XOFF
are just characters; if the interface can read other messages from the
printer it can read them. We really like these printers, so don't be put
off from looking at them by worries about interfacing problems.
------------------------------
Date: Tue, 1 Nov 88 15:02:43 EST
From: khai%amara.uucp at umix.cc.umich.edu (S. Khai Mong)
Subject: Callback for getty wanted
Is there a program available PD or otherwise, that would replace getty on
the Sun? Its function would be to monitor for incoming calls, ask for a
user name and then hangup the line and call back the caller from a list of
trusted numbers. After a successful call back, it would open a terminal
session for that user. If it can also handle uucp calls over the same
line, all the better. I am interested in this mainly for security.
--
Sao Khai Mong: Applied Dynamics, 3800 Stone School Road, Ann Arbor, Mi48108
(313) 973-1300 (uunet|umix)!amara!khai khai%amara.uucp at umix.cc.umich.edu
------------------------------
Date: Tue, 1 Nov 1988 15:27:35 EST
From: Bob Hoffman <hoffman at sun2.cs.pittsburgh.edu>
Subject: Tape mark (EOF) skipping problem with 1/4-inch tapes
System: SunOS 4.0 on a Sun 3/160
SCSI 1/4" tape with Emulex controller and Wangtek drive.
The manual page for mtio(4) says:
"A zero byte count is returned when a tape mark
is read, but another read will fetch the first record of the
new tape file."
This used to work reasonably well on SunOS 3.5 and earlier, but I cannot
find the right combination of things to make it work under 4.0. Once a
tape mark is read, read() returns 0 indefinitely.
Test procedure:
1. Make a tape with several files on it.
dd if=bigfile of=/dev/nrst8 bs=126b
dd if=bigfile of=/dev/nrst8 bs=126b
dd if=bigfile of=/dev/nrst8 bs=126b
dd if=bigfile of=/dev/nrst8 bs=126b
dd if=bigfile of=/dev/nrst8 bs=126b
mt -t /dev/nrst8 eof 2
mt -t /dev/rst8 rew
2. Compile and execute this program.
#include <stdio.h>
#define MAXBLKSIZ 64512
char buf[MAXBLKSIZ];
main() {
register int n, blknum, dfd;
int eofcnt = 0;
char *cdrive;
FILE *tape;
cdrive = "/dev/nrst8";
if ((dfd = open(cdrive, 0)) < 0) {
perror(cdrive);
exit();
}
printf("\n BLOCK LENGTH\n\n");
blknum = 0;
do {
n = read(dfd, buf, sizeof buf);
if (n == -1)
perror("Tape Read");
printf("%4d %8d\n", blknum, n);
blknum++;
if (n == 0)
eofcnt++;
} while (eofcnt < 5);
}
3. The output you get will look something like this:
BLOCK LENGTH
0 64512
1 64512
2 64512
3 64512
4 64512
5 64512
6 22528
7 0
8 0
9 0
10 0
11 0
If left to run, read() will return 0 forever. I have tried closing and
reopening the tape after every EOF but that doesn't help. I've tried
issuing an "mt fsf 1" ioctl after every EOF but the result is that only
odd-numbered files are read. Does anyone have any ideas on what might be
wrong?
Many thanks,
---Bob.
Bob Hoffman, N3CVL {allegra, bellcore, cadre, idis, psuvax1}!pitt!hoffman
Pitt Computer Science hoffman at vax.cs.pittsburgh.edu
------------------------------
Date: 1 Nov 88 18:39:16 PST (Tue)
From: daver!mfgfoc!exodus at sun.com (Greg Onufer)
Subject: Help! with RLL controllers...
I just replaced my Adaptec 4000 with an Adaptec 4070 RLL controller
because 1) Stores 1.5 times more on each disk 2) Reads from the disk 1.5
times faster. But for some reason my disk throughput dropped from roughly
125k/sec to 50k/sec. I have a feeling that either the RLL controller is
defective (I doubt it) or that the Sun-2 cannot keep up with the increased
transfer rate. I have tried interleaves of 1,2,3, and 4 with no
improvement in speed. I have tried tweaking the fstune parameters without
much success. I am open to any reasonable ideas!! (Pertinent info:
Sun-2, SunOS 4.0, Adaptec 4070 SCSI->ST506 RLL Controller, 2 Micropolis
1325 75Meg(unf, non-RLL) 112Meg(unf, RLL) drives)
Thanks, Greg Onufer // Focus Semiconductor Systems, Inc. // 408-738-0600
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list