Article 4603 of vmsnet.pdp-11: Path: nntpd.lkg.dec.com!pa.dec.com!decwrl!amd!netcomsv!uucp3.netcom.com!netcomsv!uu3news.netcom.com!ix.netcom.com!howland.reston.ans.net!agate!library.ucla.edu!psgrain!oswego!ub!library.erc.clarkson.edu!rpi!wilsonj From: wilsonj@alum01.its.rpi.edu (John Wilson) Newsgroups: vmsnet.pdp-11 Subject: Re: good tape handling Date: 18 Jul 1995 23:33:23 GMT Organization: Rensselaer Polytechnic Institute Lines: 67 Message-ID: <3uhgc4$pvk@usenet.rpi.edu> References: NNTP-Posting-Host: alum01.its.rpi.edu In article , Johnny Billquist wrote: >Under TOPS-20 this was extended even further, where you had a daemon handling >all tapes and mount requests, and gave a tape to the correct mount request, >so that the operator could mount any tape on any station, and the system saw >to it that that station got assigned to the correct job, and everything >worked without people actually knowing which physical hardware he was using. >The operator could also make the mount reuqest fail, and give an error >message back telling why it failed, which showed up for the user or program >trying to mount a specific tape. > >Much of this is also interconnected to logical names, since these are used to >hide from the program/user the physical device name, instead giving him a >device which fulfills the physical requirements he gave. I don't know if T20 had this, but something in addition to the above that MTS (the Michigan Terminal System, an OS for IBM mainframes) has that probably *could* be slapped on top of any OS is the ability to keep track of tapes that aren't even mounted. There's a system program called "*TAPESHARE" which maintains a database of what tapes exist, who owns them, and what users have what kind of access to them, and what rack number the tape is kept in when not mounted (all the tapes are physically kept in numbered racks in the machine room. Thus a tape can be treated almost like a directory, you can put a lot of crap on one and let selected other users access it. MTS has a very highly structured idea of file permissions, which is emulated by *TAPESHARE; there are several kinds of possible access (i.e. read, write, unlimited, none), and any of them can take arbitrary lists of user IDs, project IDs, or program keys (which by default are based on a program's name, which is very handy if you want a file to be accessible to only certain programs w/o having to give those programs privs), and are applied in a particular order with NONE being last, so you can exclude specific users from a wildcard permission, etc. The command language "RUN" and "FILESTATUS" (i.e., directory listing) commands have special pkeys, as does the debugger, so execute access is just a special case of read access, and it's possible to make files invisible in dir listings which really are accessible. Mount requests are all handled by the operator, which has the disadvantage of requiring a 24-hour staff for the computer... Anyway once the tape is mounted, the OS can recognize and handle ANSI, OS/370, or its own mutated OS/370 label schemes (and the OS can do EBCDIC/ASCII translation on ANSI tapes) or the OS can be told to screw off if you want raw magtape access (there is a user program to handle TAR tapes this way, and I have one for reading DOS-11 tapes). Much as UNIX sees everything as a byte stream, MTS sees everything as card images (even though the card reader and punch hardware are long gone), so tape records fit nicely into this scheme (although MTS's TELNET client is quite a monstrosity!). MTS's equivalent to ioctl() is the $CONTROL command, or equivalently the CONTROL system subroutine, which takes an arbitrary EBCDIC string, so there are commands like "REWIND" and "WTM" (write tape mark) and "FSF=n" for forward space files, etc. (UNIX has these too), and a "SENSE" command for reading back things like the tape density and the name of the next file on the tape. This would look pretty strange stuck into UNIX, but ITS has a concept called a "JOB:" device, where if you try to open a nonexistent device name the system looks in a certain directory for a handler by that name and if it finds it, it starts up a process and loads the handler as its own user-mode job (which then pretends to be a device after opening the "BOJ:" device to talk to the other side of the JOB: device, typical ITS cuteness). Anyway this is a great place to stick all kinds of random thingies that shouldn't be hogging low core (archive files are managed using one of these), and it certainly seems like a good way to provide magtape label handling in a way that's as transparent as possible to the program accessing the files on tape, since there's nothing stopping it from accessing the (note I say "the", UNIX really sucks!) magtape drive for the actual data. John Wilson