rtape: is "drive" the best way to construct the sim. tape filename?

[Bikeman]

I used ITS :DUMP to test rtape and I wonder about the "fidelity" and "practicality" of the mapping of RTAPE requests to simulated tape files (especially in wrt to the "database" maintained by ITS that tracks which files were written to which tapes):

This is my current understanding, please correct me if I'm wrong (I guess some of the following points must be wrong as there was some guessing involved). Based mainly on https://github.com/PDP-10/its/blob/master/doc/info/dump.info and https://gunkies.org/wiki/Chaos_RTAPE_protocol

• When using DUMP to request the mounting of tape (for reading and/or writing), rtape will use the "name of drive" field in the request to construct a filename, and then it will use this file as a SIMH-format tape for the following operations
• No other information is used to construct this filename
• DUMP will ask the user for a "Tape no" in addition to the drive name,
• this "tape no" seems to be the "Reel" field that is parsed by RTAPE in the mount request (???)
• In the real (vintage) world,
• .....a "drive name" corresponded to a physical tape drive machine
• .....a tape number corresponded to one (or perhaps a sequence??) of tape reels
• .....there seems to be a concept of a reel number in ITS's DUMP as well but I have no idea what that is
• .....a request to mount tape no N in drive named D would be transmitted to the remote site where, if necessary, personnel or perhaps later some machinery would make sure that tape N is taken from a tape library (rack) and inserted into drive D
• ITS's DUMP is caching, in it's own file system, when files get dumped to a tape (locally or remotely).
• .....Let's say I have a file "HBE;nampic mw", then I can later lookup with :DUMP , _find on which tape(s) this file was backed up to (in full, incremental, or any other way of :DUMPing)
• .....But :DUMP _find will tell me the tape number, not the drive name (!) as far as I can see. This makes sense in a way, you want to know the piece of media, not the device that was used to back up a file.

So if all this is true, than in order to be able to use the feature that ITS :DUMP keeps track of which tape no files were written to, wouldn't it be better to include the fileno (is this the "reel" field in the RTAPE protocol???) to construct a filename for storage by rtape. .E.g. if ITS'S :DUMP _list would tell me that file can be found on tape 4077 , I would then that file nr when reading the file back with :DUMP and rtape could pick the correct file which could be named, say, somedrive.tapeno.tape

Hope this makes some sense. So long story short: I'd suggest (and volunteer to do) to optionlly (via command line switch) include the "reel" field in the mount request to the filename that is used to pick the filename used to store the simulated tape.

[bictorv]

I sympathize with the issue of tape filenames. I'd like to (1) have a ".tap" file type, (2) be able to separate tape files from different remote hosts either by filename (e.g. "drive.hostname.tap") or even directories (put all tapes for a host in a subdir "host/"). But (2) should be elective, since it would make it harder to share tapes between hosts (you'd need to e.g. make links).

If you check the (non-quiet) output from rtape (or read the DUMP sources after the OPEN1 label), you can see the "reel" provided by DUMP is the string "ITS". So to incorporate the "tape no", you need to change DUMP, not rtape.

Changing what is logged in MACRO TAPES (e.g. what remote host and drive) might be more work and involve backwards compatibility?

[larsbrinkhoff]

The tape number is used by ITS to keep track of tapes. There is a database that says which tape number has which files. I don't know if DUMP sends this number in the RTAPE request; does it?

Sometimes you'll see the word reel. I'm not sure but my vague understanding is that a "logical backup tape" may consist of several "physical tapes" and then the latter are reels.

I'm prone to avoid complexity. Having the user type the file name is very simple and direct. The user should probably name a backup tape number 1234 something like "tape_1234.tap". My auto backup program does this.

[larsbrinkhoff]

I'd rather not change DUMP with respect to RTAPE information or MACRO TAPES.

[Bikeman]

you can see the "reel" provided by DUMP is the string "ITS".

Upps...that sinks my idea pretty much. Not sure how the "removable media" aspect of tapes was handled in the vintage world over RTAPE then, but that's the way it is (was).

Changing DUMP is definitely not my intention!!

Still more flexibility with the filename might be useful. I wonder if, as a minimalist solution, one should be able to specify an optional printf-format string on the rtape commandline that would be used to build the filename like
sprintf(tapename_buf,len,tapename_fmt,host,drive,reel) and the default would simply be "%.0s%s%.0s" which would be equivalent to "just the drive name" and e.g. "%.0s%s%.0s.tap" would add a ".tap" extension...etc. Checks/sanitizing for forbidden characters would then need to be done on all strings that contribute to the filename and sent by the clients, of course.

[larsbrinkhoff]

Sure, such a feature could be added, activated by an option.

The default can be to use the "drive name" verbatim, where the user gets what they type; no more and no less. That's very transparent.