Unix-Wizards-Request@BRL.ARPA (Mike Muuss) (07/22/85)
UNIX-WIZARDS Digest Sun, 21 Jul 1985 V1#112
Today's Topics:
Re: disk-block integrity after system crashes
Re: Idle time logout mechanism (daemon)
DECNET <-> UNIX info needed
Re: Xenix panic (easy to do) Comment and an alternate method.
Re: need porting help
need porting help
libcore.a ??
Re: Re: Ethernet for IBM machines
DEC bootstrap card query
Re: monitoring ttys
Re: History lessons
Re: mailwatch script wanted
Re: Xenix Crash? Trivial...
Re: instability in Berkeley versus AT&T releases
Re: Killing processes that are sleeping with -ve priority
Re: a file called 0
-----------------------------------------------------------------
From: rpw3@redwood.UUCP (Rob Warnock)
Subject: Re: disk-block integrity after system crashes
Date: 17 Jul 85 08:44:01 GMT
To: unix-wizards@brl-tgr.arpa
Just how bad can a power failure be? Well, how about wiping out
the formatting (and therefore the data, to say the least) on several
(even "many") cylinders on the disk? (Under Unix, might as well just
reformat and hope your backup tapes are healty!)
This can happen even if the disk drive has power-fail protection,
if the drive is in an "expansion box" and powered by a separate
power supply. As the power to the disk controller (in the main box)
goes down, so does the power to the drive cable terminating resistors
(which are normally pulled to +5 volts). This can, if you are unlucky,
cause the "WRITE ENABLE L" signal to drop below the TTL threshold and
start writing on the disk BEFORE the power to the disk (in the expansion
box) drops enough to shut off the write amps in the disk. It all depends
on the relative "hold-up" time of the two power supplies in the two boxes.
Conversely, if you have TWO disks on the same controller sharing a bussed
"control" cable, if the expansion box power drops first, you can wipe the
data & formatting on the disk in the main box.
One of the nice things about large DEC systems is that they have a power-
fail line which is bussed between all of the expansion boxes (if the
installer hooked them up correctly) and which causes ALL the boxes to
panic and protect themselves if ANY of the boxes loses power. (Of course,
if you are having troubles with power supplies, this bussed line makes it
hard to figure out which box is causing the problem, so sometimes it gets
unhooked for debugging and never gets put back...)
It is possible (and not too expensive) to protect disks fairly well from
this sort of thing, but a lot of the current low-cost "desktop" computers
don't bother. (*sigh*)
Rob Warnock
Systems Architecture Consultant
UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD: (415)572-2607
USPS: 510 Trinidad Lane, Foster City, CA 94404
-----------------------------
From: chuqui@nsc.UUCP (Chuq Von Rospach)
Subject: Re: Idle time logout mechanism (daemon)
Date: 20 Jul 85 07:50:28 GMT
To: unix-wizards@brl-tgr.arpa
In article <11650@brl-tgr.ARPA> Crispin@SUMEX-AIM.ARPA (Mark Crispin) writes:
>
> The best way to make users clever enough to defeat fascist
>daemons is create such a daemon. It sounds to me like you have
>You do not need tobad communication with your user community.
Well, here my problem is that I have three modems that are used by a wide
variety of people in various places that get called to meetings, that get
interrupted by the phone, and are generally trying to do 5 or 10 things at
once. Occasionally they forget to log off or hang up their modem, and I
lost one of those modems from use until I track it down and unplug it. None
of this is fascist, just trying to free up forgotten resources because we
have a large (and growing) community of users that need the modems. I need
a daemon mainly to help people that sometimes forget in all honesty
remember again.
--
:From the carousel of the autumn carnival: Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA
Your fifteen minutes are up. Please step aside!
-----------------------------
From: system@asuvax.UUCP (Marc Lesure)
Subject: DECNET <-> UNIX info needed
Date: 17 Jul 85 15:56:55 GMT
To: unix-wizards@brl-tgr.arpa
I need information on connecting 4.2 Unix ethernet to VAX/VMS DECNET. All
help would be greatly welcomed. Thanks -
-------------------------------------------------
Marc Lesure
UUCP: ...!ucbvax!arizona!asuvax!lesure
CSNET: lesure@asu
ARPA: lesure%asu@csnet-relay
-----------------------------
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Subject: Re: Xenix panic (easy to do) Comment and an alternate method.
Date: 19 Jul 85 10:41:54 GMT
To: unix-wizards@brl-tgr.arpa
In article <1535@dalcs.UUCP> forceten@dalcs.UUCP (ForceTen Enterprises) writes:
>
> On the AT, a simpler means of instantly halting my machine
>without so much as a panic (power cycle to reboot)
>
> $ cat > /dev/monochrome
>
> I use an AT w 1 Meg memory, Paradise Systems Multidisplay Card.
>Has anyone encountered this on a system with a standard IBM colour adaptor?
My machine has an IBM monochrome board and a Paradise Systems Multidisplay
Card configured as color only (take too much current to run in my PC!).
Memory is 1152k and two serial + two parallel ports. Default monitor
is monochrome.
cat > /dev/monochrome
elicits a "can't create" message, even if superuser.
cat > /dev/color
works as expected, accepting keyboard input until ^D, at which time
it all scrolls out on the color monitor. In fact, I often redirect
output to the color monitor, sort of a hardware version of windows
but with only one virtual terminal.
There are some strangenesses with the Paradise board if I try to run
Xenix with the displays in any other configuration that the one described.
--
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131
Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect)
Home of Professional-YAM, the most powerful COMM program for the IBM PC
-----------------------------
From: quent@isucs1.UUCP
Subject: Re: need porting help
Date: 12 Jul 85 19:37:03 GMT
Sender: notes@isucs1.UUCP
Nf-ID: #R:isucs1:17700009:isucs1:17700011:000:106
Nf-From: isucs1!quent Jul 12 14:11:00 1985
To: unix-wizards@brl-tgr.arpa
I'll answer this one myself... we decided not to port it since we don't
want to spend two years doing it!
-----------------------------
From: quent@isucs1.UUCP
Subject: need porting help
Date: 12 Jul 85 19:36:45 GMT
Sender: notes@isucs1.UUCP
Nf-ID: #N:isucs1:17700009:000:244
Nf-From: isucs1!quent Jun 28 14:57:00 1985
To: unix-wizards@brl-tgr.arpa
We are attempting to port Franz lisp from our 4.2/VAX 11/780 to a Convergent
Technologies 68010 based system which is running something that looks like
V5 unix. I would like to hear from people who have experience with this
sort of torture.
-----------------------------
From: quent@isucs1.UUCP
Subject: libcore.a ??
Date: 12 Jul 85 19:37:18 GMT
Sender: notes@isucs1.UUCP
Nf-ID: #N:isucs1:17700010:000:163
Nf-From: isucs1!quent Jun 28 15:01:00 1985
To: unix-wizards@brl-tgr.arpa
While looking at the makefile for Franz lisp I ran into a reference to
"/usr/lib/libcore.a". There is no trace of such a file on our system;
any hints out there?
-----------------------------
From: jbn@wdl1.UUCP
Subject: Re: Re: Ethernet for IBM machines
Date: 17 Jul 85 23:11:11 GMT
Sender: notes@wdl1.UUCP
Nf-ID: #R:brl-tgr:-1154800:wdl1:64000004:000:296
Nf-From: wdl1!jbn Jul 17 12:50:00 1985
To: unix-wizards@brl-tgr.arpa
The package he is referring to is ``VM Interface Program for TCP/IP'',
IBM Program 5798-DRG, price $17,000. Contact your IBM rep for further details.
We've looked at the product, but haven't actually purchased one pending the
conversion of our IBM mainframe from MVS to VM.
John Nagle
-----------------------------
From: jbn@wdl1.UUCP
Subject: DEC bootstrap card query
Date: 17 Jul 85 23:11:28 GMT
Sender: notes@wdl1.UUCP
Nf-ID: #N:wdl1:64000005:000:219
Nf-From: wdl1!jbn Jul 17 13:06:00 1985
To: unix-wizards@brl-tgr.arpa
I need to know the switch settings needed to make a DEC 9812 bootstrap
board cause an automatic boot from an RL02 on power-up, but don't have the
right manual. Anybody have the right book handy?
John Nagle
-----------------------------
From: jack@boring.UUCP
Subject: Re: monitoring ttys
Date: 20 Jul 85 22:05:52 GMT
Apparently-To: rnews@mcvax.LOCAL
To: unix-wizards@brl-tgr.arpa
Problem: looking over peoples shoulder electronically.
I think you shouldn't try to solve this with kernel mods. It's
fairly easy to write a program that copies input to/from a pseudo
tty, and makes a copy to another terminal or file on the way.
This way, you just tell the user to execute
watchme /dev/console
or something like that, and you'll be able to follow
everything he does.
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.
-----------------------------
From: davy@pur-ee.UUCP (Curry)
Subject: Re: History lessons
Date: 19 Jul 85 04:13:14 GMT
To: unix-wizards@brl-tgr.arpa
In article <92@cithep.UucP> tim@cithep.UucP (Tim Smith ) writes:
>> I have it from a reliable source (Ritchie) that in the original Unix file
>> system, the directory structure was an arbitrary graph. It was changed
>> to a tree because of the hair involved in consistency checking. As late
>> as v6, ln command allowed root to link directories, and across file
>> systems. This may have been a Purdue hack, though.
>
>Root can still link directories, as far as the kernel is concerned. As for
>linking across file systems, this must be a Purdue hack, since it is not
>possible on ordinary v6,v7,TS 1.?, SIII, and SV for very fundamental reasons.
>How did they change the file system to allow this?
I'm not sure who started this rumor, but it's incorrect. Purdue never
hacked in stuff to allow you to link across file systems. So far as I
know, we never did much else to the file system either, with the small
exception of gracefully handling what happens when the file system runs
out of space.
Of course Purdue did hack in lots of other stuff, but that's a different
story all together.
--Dave Curry
-----------------------------
From: jerryp@tektools.UUCP (Jerry Peek)
Subject: Re: mailwatch script wanted
Date: 19 Jul 85 15:09:58 GMT
To: unix-wizards@brl-tgr.arpa
[Doesn't this sort of thing belong in net.unix?]
In article <411@sdcc12.UUCP> wa371@sdcc12.UUCP (Bernd) writes:
> Does anyone have a suggestion for a shell script for my .login
> file, which will announce immediately upon login whether I have mail
> or not, without putting me into the mail program if I don't want
> to be.
> It should run under the 4.2 c-shell.
Try this single line:
if (! -z /usr/spool/mail/wa371) echo You have mail.
Instead of hardcoding your login name (wa371), you could use $user instead.
--Jerry Peek, UNIX Training Instructor, Tektronix, Inc.
US Mail: MS 74-222, P.O. Box 500, Beaverton, OR 97077
uucp: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp
CS,ARPAnet: jerryp%tektools@tektronix.csnet
Phone: 503/627-1603
-----------------------------
From: tang@mulga.OZ (Antony Tang)
Subject: Re: Xenix Crash? Trivial...
Date: 21 Jul 85 02:34:53 GMT
To: unix-wizards@brl-tgr.arpa
In article <518@aicchi.UUCP> ignatz@aicchi.UUCP (Ihnat) writes:
>Gosh, you have to go into a program? I just discovered tonight, while
>'adb'ing a stripped object (DON'T ask why I would want to do it--object
>licensees have to do many things a respectable source licensee wouldn't
>*dream* of), that I can trash the kernel by simply trying to single-step
>through a system call!
>
In the manual of XENIX 1.0 for the AT, it read : "System calls cannot
be single-stepped"
-----------------------------
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Subject: Re: instability in Berkeley versus AT&T releases
Date: 21 Jul 85 04:42:22 GMT
To: unix-wizards@brl-tgr.arpa
> There are also plenty of examples where AT&T adds a BSD feature,
> but changes the command or system call name or syntax. Isn't that
> referred to as the NIH (Not Invented Here) syndrome? When will AT&T
> (and DEC for that matter) realize that UC Berkeley is NOT a competitor?
There may be some "NIH" syndrome at work, but you should also appreciate
that BSD software is not necessarily up to commercial standards, so it
might need some adaptation before being supported by a commercial outfit.
Unfortunately, AT&T has been picking up some of the WORST features from
BSD. cat -v, ls -[a-z][A-Z], yuck.
-----------------------------
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Subject: Re: Killing processes that are sleeping with -ve priority
Date: 21 Jul 85 05:08:00 GMT
To: unix-wizards@brl-tgr.arpa
> Occasionally I will run into a process that is sleeping with
> a negative priority.
Fix your device driver to timeout after a reasonable period.
-----------------------------
From: larry@kitty.UUCP (Larry Lippman)
Subject: Re: a file called 0
Date: 20 Jul 85 23:22:23 GMT
To: unix-wizards@brl-tgr.arpa
> Has anyone out there found a mysterious file called "0" appearing
> every once in a while when vi is used? It seems to be a result of
> quiting vi. It has nothing in it. If this happened every time I would
> find it less curious, but it is very rare and I cannot figure it out.
> Does anyone have any answers on this. (it is possible that this
> is not vi related) My system is a Mostek Matrix Vmebus computer with
> a Unisoft 68k sysV port. Thanks in advance...
> Erik James Freed
> Aurora Systems
> San Francisco, CA
> {dual,ptsfa}!aum!freed
We use 68010 VME-bus systems made by Ironics Inc. (IV-1600S) which
run Unisoft System V. We almost exclusively use vi and have never experienced
the problem. Could you be more explicit? How do you quit vi (':q!', 'ZZ',
':q', etc.)? Have you set any ex options? Are you running in 'open mode'?
What is in the file '0'?
Larry Lippman
Recognition Research Corp.
Clarence, New York
{bbncca,decvax,dual,rocksanne,watmath}!sunybcs!kitty!larry
{rice,shell}!baylor!kitty!larry
TELEPHONE: 716/741-9185
TELEX (WUI): 69-71461 ANSWERBACK: elgecomclr
-----------------------------
End of UNIX-WIZARDS Digest
**************************peter@baylor.UUCP (Peter da Silva) (07/24/85)
> There may be some "NIH" syndrome at work, but you should also appreciate > that BSD software is not necessarily up to commercial standards, so it > might need some adaptation before being supported by a commercial outfit. There's no commercial reason for changing the name of Mail to mailx, or TURNING OFF the use of '.' as well as '~.' to terminate a message, or rehacking the terminal driver so V7 programs no longer work, and so on. Like it or no, at the time Bell came out with System III, THE standard system in the real world was V7. There is no good excuse for making SIII incompatible with V7. Or for makeing SV incompatible with SIII. -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
henry@utzoo.UUCP (Henry Spencer) (07/26/85)
> There's no commercial reason for changing the name of Mail to mailx... Actually, yes there is: a stupider naming convention has seldom been seen on Earth. Making case difference significant like that was a really silly idea, and it is to AT&T's credit that they bit the bullet and fixed it. Your other specific comments I largely agree with. > There is no good excuse for making SIII incompatible with V7. Similarly, there is no good excuse for making 4.2 incompatible with almost everything which preceded it. Which it is. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
wcs@ho95e.UUCP (x0705) (07/27/85)
> > There may be some "NIH" syndrome at work, but you should also appreciate > > that BSD software is not necessarily up to commercial standards, so it > > might need some adaptation before being supported by a commercial outfit. > > There's no commercial reason for changing the name of Mail to mailx, or > TURNING OFF the use of '.' as well as '~.' to terminate a message, or > rehacking the terminal driver so V7 > programs no longer work, and so on. Like it or no, at the time Bell came > out with System III, THE standard system in the real world was V7. There > is no good excuse for making SIII incompatible with V7. Or for > makeing SV incompatible with SIII. > Peter da Silva (the mad Australian) ## Disclaimer line so I can flame at you without implying my employer's ## participation in these flames. ---- Well, I don't know why they changed the name, but the ~. versus . is a settable option under Mail* - include the line set dot in your .mailrc file, and alias Mail=mailx if you really care about the name. ---- As for the terminal driver, some of us *like* the System III based drivers better than the V7/4.1/4.2BSD versions. The driver changes were made for a lot of good reasons, and with at least some thought about the pain they'd cause. As for System V being incompatible with System III, upward compatible is always non-downward-compatible. What is there that used to work under System III that's broken now? If you want to flame about how changing things is, look at the change from 4.1BSD to 4.2BSD! *( on our exptools systems, Mail is the most current release of mail, while mailx is the officially distributed version) -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
peter@kitty.UUCP (Peter DaSilva) (08/01/85)
> If you want to flame about how changing things is, look at > the change from 4.1BSD to 4.2BSD! I have never used 4.1, but apart from directory entries, I have nothing to complain about in porting vanilla V7 stuff to 4.2. Since 4.1 is a V7 derivative, I can hardly see that the 4.1 -> 4.2 change could have created any major incompatibilities. The SIII system I used was a Unisoft port. It didn't require you to diddle with MIN and TIME to set CBREAK mode. If you don't you get 4 character granularity in reads, and they time out after 2.8 seconds. This broke several programs I was trying to maintain on a system that was converted from SIII to SV. I still haven't gotten Xmodem to work reliably again (though I must admit I haven't spent a great deal of time working on it lately). Can you say "incomptibility"? The 4.2 method of handling timouts is much better, since it ADDS a function, instead of CHANGING an existing one.
guy@sun.uucp (Guy Harris) (08/08/85)
> The SIII system I used was a Unisoft port. It didn't require you to diddle > with MIN and TIME to set CBREAK mode. If you don't you get 4 character > granularity in reads, and they time out after 2.8 seconds. How is it going to "require" you to do this? 1000V for 5 seconds through the seat of your chair? Assuming you mean "go into a mode where you get each character as typed" by "set CBREAK mode" (to do this on the S3/S5 tty driver, you actually clear ICANON mode), you *are* required to diddle with MIN and TIME on *all* S3/S5 systems if you want proper results. (Pop quiz, for people who think they're experts on how the S3/S5 driver works: 1) Why should the "4 character granularity" be no surprise if MIN isn't set? 2) Why should the 2.8 second timeout be a *big* surprise, unless the user doesn't like to use the traditional UNIX quit character as a quit character? Also note that, unless UniSoft broke the tty driver rather badly (which I consider to be largely outside the realm of possibility), the read "timeout" isn't really a timeout; the clock doesn't start running until the first character comes in. > This broke several programs I was trying to maintain on a system that > was converted from SIII to SV. I still haven't gotten Xmodem to work > reliably again The programs were broken already. If you turn off ICANON you *must* also set MIN and TIME to some other values - MIN of 1 and TIME of 0 will emulate V7's CBREAK mode exactly - if you want reliable results. If you didn't do so, go fix your code. > The 4.2 method of handling timouts is much better, since it ADDS a > function, instead of CHANGING an existing one. What "4.2 method of handling timeouts"? If you mean using "alarm"/"setitimer", that's in S3/S5 ("alarm", that is; only 4.2BSD has "setitimer", alas); it's been there since before V6. If you mean the timeout in "select", that's a timeout, not a silo drain clock like TIME in S3/S5 (as was pointed out before). Guy Harris
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/09/85)
My USG 3.0 manual doesn't seem to document MIN & TIME. Were they nonetheless implemented in the tty handler?
peter@baylor.UUCP (Peter da Silva) (08/12/85)
> My USG 3.0 manual doesn't seem to document MIN & TIME. > Were they nonetheless implemented in the tty handler? Look in the administrator's section. They're well hidden. -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
mats@dual.UUCP (Mats Wichmann) (08/14/85)
> My USG 3.0 manual doesn't seem to document MIN & TIME. > Were they nonetheless implemented in the tty handler? *MY* copy, labelled UNIX User'S Manual, Release 3.0, June 1980, has exactly the same wording under tty(4) as my V.2 manual, under termio(7)...the phrase beginning If ICANON is set, canonical processing is enabled. .... The SVID is still the only thing that comes close to describing it completely, however. Mats Wichmann Dual Systems ...{ucbvax,ihnp4,cbosgd,decwrl,fortune}!dual!mats "Luxury. Comfort. Style. And at prices jou can afford!"