usenet@abnjh.UUCP (usenet) (03/06/84)
I really like this one -- >> Yes, it is about time that the stupid method of dealing with end of tape >> on unix disappears. >> I have changed the drivers locally as follows >> On the write which passes the EOT mark, normal status is returned. >> i.e. the block was written out correctly. >> On any future write, EEOT is returned, and the block isn't written. >> Thus, ordinary processes which know nothing about tapes run >> correctly, and there is no problem; however since they call perror >> you get a reasonable error message when they die. >> However, for smart processes, you can do a MTIOCEOT which say's >> that you know you've hit the end of tape, but you'd like >> to write out trailer records. It then lets you do whatever you >> like; even go off the end of the tape. >> On reads, you always get the block, it ignores the end of tape; >> its up to you to verify that correct tape marks were written. >> Anyhow, with this actually fairly trivial change, you can now very >> easily change dump to correctly handle end of tape. >> I have fixes for mt.c and ut.c if anybody wants them; you can of course >> also have the fix to dump. It is backwards compatible with existing UNIX programs, and retains both the flavor of UNIX and the flavor of mainframe systems that (have to) know how to deal with tapes sensibly. I really hope that the USG folks are listening. This one is worth picking up! UNIX grew up on minis, where the attitude toward tapes was "You got a tape? Ok there's the tape drive. Go hang it yourself." But nowadays, most UNIX systems are run by comp centers, and users aren't allowed anywhere near the hardware. Now that we have solved the problem of EOT detection, can anybody think of an equally elegant hack to solve the problem of getting the operator to retrieve the tape you want from the library and put it on a drive and notify you when it is mounted, all without massive use of 'write(1)'. While I'm at it, can anybody suggest a way for me to retain exclusive use of the drive as long as my tape is mounted on it? Ideally, I would like to be able to follow the following script (or something like it): >> hang vol_ser=123456 file=mytape mode=read_write density=1600 The operator is informed to retrieve reel number 123456 from the library, and hang it on a (system specified?) drive with 1600BPI capability, and bugged about it until s/he does it. When the tape is hung (and only then) the hang command returns after verifying that the operator put the ring in (allowing read_write access) and checking the ansi VOL1 label. The filename 'mytape' in my working directory is now (?symbolicly?) linked to the appropriate /dev/rmtxx (or whatever) device and the device has read-write permissions for my userid only. Since tapes have lots of optional features (anybody ever used a seven track tape? with two possible paritys and three possible densities, and n possible ways of mapping 6 bits per frame to 8 bits per character!) the hang command would need a flock of options. Keeping track of the syntax for all those options will be a chore. >> tar xf mytape >> rewind mytape >> tar cf mytape src/* The 'rewind' command does the obvious thing. the 'tar' commands do their usual (not so obvious) things. >> unhang mytape The tape is rewound and unloaded, and the operator is informed to return it to the tape library. The filename 'mytape' is unlinked from the device and the device is returned to 'normal' modes. The *only* way to get the tape rewound with interlock is by using the 'unhang' command (or ?maybe? also an ioctl() for those who insist on doing *everything* themselves?) There should be ioctl() interfaces for the kinds of operations that are unique to tape drives, like rewind, forward/backward space to EOF mark, write EOF mark, etc. and commands that do those ioctls. Now comes the hard part -- If I log off (or the last process with file 'mytape' open exits?? - would this mean that 'hang' would have to be a shell builtin, so my login shell could keep a file descriptor open to 'mytape' -- I dunno, this is getting complicated... anyway, at least when I log off ... but what about background processes... like I said, complicated) the filename 'mytape' should be unlinked from the device and the device permissions reset to 'normal' (whatever that should be -- maybe root only?) Lots of open issues here. What does the net think? Rick Thomas ihnp4!abnjh!usenet or ihnp4!abnji!rbt
woods@hao.UUCP (Greg Woods) (03/07/84)
Regarding keeping exclusive access to a tape drive: we have a program here that does it. It runs as three commands: "all", "deall" and "ft". The "all" command first checks to make sure no one else has allocated the drive, and if not, it chowns all the /dev/mt and /dev/rmt files pertaining to that drive to you, and makes them mode 600 (then no one else can read or write on that drive). "deall" chowns them back to root and makes them mode 000 (so that no one can read or write an unallocated drive). The "ft" command (for Free Tape) was added later because of course some users forget to deallocate. "ft" first checks to see if there are any free drives, and if so, it informs you immediately. If not, it checks to see if any of the allocated drives have not been read or written in the last 15 minutes, and if so, deallocates it and informs you of the now-free drive. This system has been running here since before I came here (over 3 years) and we have never had a problem with it (except for the crappy old DEC tape drives always breaking! :-) GREG -- {ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax} !hao!woods
msc@qubix.UUCP (Mark Callow) (03/08/84)
>> hang vol_ser=123456 file=mytape mode=read_write density=1600
I have no objection to a hang command which requests an operator to
mount a tape. But let's be sensible about the infor the operator
needs. "vol_ser" smacks of big blue and doesn't really seem necessary.
The density field is completely redundant. Any halfway decent tape drive
automatically senses the density of a tape it is to read. The density
you write at is determined (in Unix) by the device you write to.
Some people must love typing.
--
From the Tardis of Mark Callow
msc@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc
usenet@abnjh.UUCP (usenet) (03/09/84)
Greg Woods says: > Regarding keeping exclusive access to a tape drive: we have a program > here that does it. It runs as three commands: "all", "deall" and "ft". The > "all" command first checks to make sure no one else has allocated the drive, > and if not, it chowns all the /dev/mt and /dev/rmt files pertaining to that > drive to you, and makes them mode 600 (then no one else can read or write > on that drive). "deall" chowns them back to root and makes them mode 000 > (so that no one can read or write an unallocated drive). The "ft" command > (for Free Tape) was added later because of course some users forget to > deallocate. "ft" first checks to see if there are any free drives, and if > so, it informs you immediately. If not, it checks to see if any of the > allocated drives have not been read or written in the last 15 minutes, > and if so, deallocates it and informs you of the now-free drive. > This system has been running here since before I came here (over 3 years) > and we have never had a problem with it (except for the crappy old DEC tape > drives always breaking! :-) > I like this alot. particularly the 'ft' command. It solves the problem of freeing the drive at logout time without special kernel hacks. Moreover, it neatly finnesses all the 'open issues' associated with background processes that are still active at logout time. Rick Thomas ihnp4!abnjh!usenet or ihnp4!abnji!rbt
ron%brl-vgr@sri-unix.UUCP (03/12/84)
From: Ron Natalie <ron@brl-vgr> ANSI Labels? Now theres something that isn't compatible with the UNIX spirit. Files are files. Just bytes. Who needs records and labels. -Ron
guy@rlgvax.UUCP (Guy Harris) (03/14/84)
> ANSI Labels? Now theres something that isn't compatible with the UNIX > spirit. Files are files. Just bytes. Who needs records and labels. The same argument could be levelled agains "tar" or "tp" or "cpio"-format tapes. Labels are needed to indicate the name of the file which follows the label. ANSI labelled tapes need not have files divided into records; RT-11 happily writes a stream of bytes (or blocks, if you prefer) after the label. ANSI labelled tapes as a UNIX storage medium should be considered to be the same sort of thing as "tar" or "cpio" tapes; the labels are there for the benefit of the tape reading program, and the structure of the data is the business of the program for whom the files are intended, not the tape reading program. It might be useful, however, to have a program which understands the ANSI *record* format as well; this could be used to transfer files (source-type files, anyway) between various machines, including machines running UNIX. I agree that OS support of labelled tapes might not be useful; however, the cheap answer to the question of "who needs records and labels" is "people who have to read or write tapes which are compatible with systems which use ANSI labelled tapes". UNIX doesn't exist in a vacuum; there *are* other systems out there and UNIX *does* have to deal with them. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
david@varian.UUCP (03/26/84)
Guy Harris (rlgvax!guy) writes: >It might be useful, however, to have a program which understands the >ANSI *record* format as well; this could be used to transfer files (source-type >files, anyway) between various machines, including machines running UNIX. >I agree that OS support of labelled tapes might not be useful; however, the >cheap answer to the question of "who needs records and labels" is "people >who have to read or write tapes which are compatible with systems which >use ANSI labelled tapes". UNIX doesn't exist in a vacuum; there *are* other >systems out there and UNIX *does* have to deal with them. I just wanted to point out that such a program does exist: ansitar was posted to net.sources by uiucuxc!root on Jul 1 23:55:00 1983. This is a program to read and write ANSI labelled tapes on UNIX. We found it immediately useful, as soon after we received the Kermit distribution from Columbia University which was written on a DEC 20 (I believe)in ANSI format. We've made a few minor changes: * * 10/28/83 DRB: new option 'D': read variable length records (D format) * 10/29/83 FGH: 1. wildcard ability added to filenames. * 2. when output filename isn't valid for Unix (as it's perhaps * taken from a foreign tape), this program now just skips that * file rather than exiting the whole job. Perhaps the author wishes to post ansitar again, or I'm willing to post our current version if enough folks are interested. David Brown (415) 945-2199 Varian Instruments 2700 Mitchell Dr. Walnut Creek, Ca. 94598 {zehntel,amd70,fortune}!varian!david