netnews@wnuxb.UUCP (Heiby) (04/11/85)
Unix Technical Digest Thu, 11 Apr 85 Volume 1 : Issue 43
Today's Topics:
handling idle user jobs (logins)
Is anybody *USING* ANSI tapes on UNIX (label handling)
minifloppy/cartridge tape driver info request
Needed: some advice on how to make RCS work
Shared Memory
----------------------------------------------------------------------
Date: 8 Apr 85 21:16:34 GMT
From: ables@mcc-db.UUCP (King Ables)
Subject: handling idle user jobs (logins)
[Episode 3: R2-D2 meets the Daleks]
Does anyone out there try to throw away inactive users (4.2)?. And I mean
having something like cron check for idle time >1hr or so. Having
another machine, such as a port contention machine (read: MICOM), do
it is unacceptable. I want my CPU to take care of it itself.
Actually idle users aren't much of a problem on the machine in question,
however, when someone wants to run a benchmark on an up-but-empty machine
(say on a Sunday) and there are some inactive users (from the previous
Friday), it would be nice to have a way to throw them away. I'm even
considering a program a user could run to throw away idle user jobs that
a non-superuser could run so it would only have to happen when someone
needed it to rather than automatically.
Anybody doing anything like either of these ideas right now? Please
respond via mail.
-King
ARPA: ables@mcc
UUCP: {ihnp4,seismo,ctvax}!ut-sally!mcc-db!ables
------------------------------
Date: 11 Apr 85 07:17:14 GMT
From: jf@sal.UUCP (Johan Finnved)
Subject: Is anybody *USING* ANSI tapes on UNIX (label handling)
There has been some talk on the net about protecting people from writing
on wrong tapes. So far it has been assumed the nobody mounts the wrong
tape on a tape drive which is not always correct.
There has also been a package for reading and writing ANSI-tape recently
but without multiple volume handling and without enforcement of
protection.
I think that an implementation of the ANSI standard for Tape Labels and
File Structure for Information Interchange (X3.27-1978) would solve
several problems. Most notably positive tape identification and
continuation of big files on multiple volumes (without having
applications to limit their output).
I think that this could also solve the problem of two users accidently
using the same tape drive.
Possible implementation suggestions:
The driver is helped by a tape managing program which handles labels and
blocks-unblocks data. Data is moved between tapes and files or pipes.
The raw device is not accessible by ordinary users. The driver allows
only one open at a time, and the server does only one open and thus
knows that nobody can interfere with its tapehandling. It starts by
rewinding the tape and checking its volume label in order to make sure
that this user (real uid) has really the right to use this tape. There
has to be IOCTL:s for tape positioning, rewinding ,writing of tapemarks
and for forcing writes after EOT. I think it is most efficient to allow
reads until a few blocks after EOT and writes up to EOT and then let the
first after EOT has been seen return an error (or zero count) and then
have an ioctl that allows you to write a few blocks more to make the
volume finish correctly. The tape managing program is set-uid "tape".
Has anybody assigned IOCTL subfunctions for the above magtape commands ?
Does anybody have ideas on what to put in the fields for Owner
Identifier (in VOL1 lables), Accessibility (In VOL1 and HDR1-EOV1-EOF1
labels) and System Code (in HDR1-EOV1-EOF1 labels) ?
Maybe somebody has already assigned codes in some other system? (VMS?)
Unfortunately the fields seems to be too short for domain type
identifiers (site.subdomain.subdomain.DOMAIN)
Johan Finnved, Objecta, Sweden <jf@sal.UUCP>
------------------------------
Date: 8 Apr 85 16:31:18 GMT
From: dfh@ecsvax.UUCP (David Hinnant)
Subject: minifloppy/cartridge tape driver info request
I'm beginning to write a driver for a mini-cartridge tape drive that
uses a floppy compatible interface (WD1793 floppy controller chip). By
mini-cartridge, I mean the 3M DC 1000 type (real small). The drive,
from Irwin Magnetics, will store 10.35 MB per tape.
I'm interested in communicating with people who have done this in the
past, as I'm not too experienced in extremely low-level device drivers
that deal in counting pulses, etc.
What's the best way to vector to a different driver given that the
interrupt could come from the floppy or the tape? What's the best way
to handle both streaming and start-stop mode? Etc.
As always, I will summarize and post if there is sufficient interest.
David Hinnant
SCI Systems
...decvax!mcnc!rti-sel!scirtp!dfh
------------------------------
Date: 8 Apr 85 14:16:05 GMT
From: cosell@bbn-labs-b.ARPA (Bernie Cosell)
Subject: Needed: some advice on how to make RCS work
I'm about to begin a project that will (rightfully) use RCS to oversee
the sources. My problem is that as I look at the RCS documentation there
are some things that I'm not sure how to make work. Perhaps folk out there
more experienced with RCS could enlighten me a bit:
a) I am still very much tied to hardcopy listings: for large, complicated
programs I just can't get by reading and writing code through a 24 line
window (I can't even get by with the 64 lines on my BitGraph). If you
have a big system all RCS'ed up, how do you keep your listings current?
That is, I usually expect to have a notebook on my shelf with the 'current'
system listings in it. Right now, when I go to mess with something I pull
out the notebook, do an ls -l and compare last-modified dates (which pr
has kindly stamped on each page) with the current files to see which
listings need to be updated. Is there some equivalent 'give me the epoch
of everything' function you can perform when everything is RCS'ed?
I also have to probably modify 'pr' to use something other than the
file's last-modified date for its epoch stamp on the listings, since
as I understand it RCS does not preserve modified times (although it
presumably easily could have done so had its writers so chosen, I
suspect), so when I co a file it'll come out with a different last-modified
date than when it was ci'ed.
b) I don't know how to get 'make' to work. That is, if I want to work on
say one file amdist the many, I can easily 'co' the one file into a 'work'
directory and then edit it, but then what do I do with it? One thing that
probably works (assuming that I do my incremental work on the same machine
that holds the RCS files) is to have a public place that holds one copy
of the current set of sources of everything, so at least there is a set
of sources (and master .o files, presumably) one can hope to access. But now:
is there a way to get a makefile set up so that for .c's and .h's in '.'
it'll use them, but for the ones it can't find it'll use the copies from the
master directory? I guess the loader has to know about that, too:
some .o's will want to come out of the master dir, while others will
want to come out of my working dir.
Much thanks!
/Bernie
ps, replies just to me, cosell@bbn-labs-b.arpa, and I'll summarize back
to anyone else who'd like to hear the answers.... tnx /b
------------------------------
Date: 9 Apr 85 03:25:41 GMT
From: mjs@eagle.UUCP (M.J.Shannon)
Subject: Shared Memory
> > How do you pass a key from one process to
> > another process so that both processes have acess to the
> > same "shmid"?
>
> Message passing?
The "proper" way to do this is to use the ftok() (stdipc(3C)) routine
with a filename that all processes involved agree upon. Yes, it is
difficult to find this routine (due to the name of the manual entry
and the contents of the NAME section, it doesn't appear anywhere
useful in the permuted index), but that's how to do it. Honest --
I've used it!
--
Marty Shannon
UUCP: ihnp4!eagle!mjs
Phone: +1 201 522 6063
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)