Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site abnjh.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!abnjh!usenet From: usenet@abnjh.UUCP (usenet) Newsgroups: net.unix,net.unix-wizards Subject: Re: Alex Whites solution to end of tape recognition in UNIX Message-ID: <490@abnjh.UUCP> Date: Tue, 6-Mar-84 11:37:36 EST Article-I.D.: abnjh.490 Posted: Tue Mar 6 11:37:36 1984 Date-Received: Wed, 7-Mar-84 07:38:37 EST References: <1762@rlgvax.UUCP>, <7175@watmath.UUCP> Organization: ATTIS, NJ Lines: 90 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