9

A two-part question:

  1. How widespread in legacy systems was the practice of using magnetic tapes as a genuinely random access medium at the OS level by pre-formatting them in a way before the first use, then an application referring to data blocks on tape by number, and the OS automatically issuing the appropriate number of Block Skip Forward or Block Skip Back commands before performing the actual block read or write operation?

Update: That's DECtape, for example.

  1. How widespread, if at all, was the practice of emulating such random access tapes with IBM 9 track tapes, when the original equipment went out of commission but the need for tapes with random access remained?
  • As far DECtapes, they were essential for the computer to work (the OS was on DECtape), so when they broke, they were repared. I can't imagine a situation where one would have considered to replace them with IBM tapes, so I don't think the second question makes a lot of sense. – dirkt Jan 14 '17 at 9:11
  • @dirkt I believe that there could be other DASD tapes besides DECtape. – Leo B. Jan 14 '17 at 9:14
  • On certain types of tape, this isn't possible at all. For example, QIC-24 is a 9-track cartridge tape, but the tracks are serially recorded in serpentine fashion and the drive has a single erase head that erases the full width of the tape (all 9 tracks at once), so it's not possible to erase a single block in the middle of the tape because you will also erase the corresponding blocks on the other 8 parallel tracks. Basically if you want to do this reliably you need a tape drive that was made with this use case in mind. – Ken Gober Jan 14 '17 at 16:15
  • 1
    Two other small systems that used servo-controlled tape mechanisms to access records/files numerically were the HP 98xx and the Philips P2000. I haven't been able to ascertain if they were fully random access though. At the other end of the scale, there were floppy disk systems that didn't offer random access. AMSDOS on the Amstrad CPC computers, although similar to CP/M, didn't have a native API to give random access to disk files. Once you'd opened a file, you could only read it sequentially. – scruss Jan 14 '17 at 23:01
  • 2
    @Leo I didn't want to go into 1/2" 9 track tape because it's complicated. The 2 big issues are the lack of a timing track (and the inability to simulate one on a 9-track drive) and the resulting size of the inter-block gaps needed to prevent adjacent blocks from being accidentally overwritten/erased during a write. Note that because these tape drives were not made specifically for this task, they will have varying tape speeds and varying distances between the erase head and the write head, which complicates things greatly. You might end up wasting 3/4 of the tape just for inter-block gaps. – Ken Gober Jan 16 '17 at 14:51
8

DECtape was used that way; it was wide (0.750 inch?) magnetic tape, on very small reels, so it didn't take forever to find a sector. PDP-8 and PDP-11 systems from Digital Equipment were the likely systems sporting DECtape drives. The tape was fully redundant, took a LOT of wear without losing data, and that made it suitable for such system-program use.

That would be about the late 1970s. As I recall, 1/2" tapes of that era were not used for any such OS functions, because hard disk drives weren't more expensive than a good full-reel tape transport. Nine-track and ANSI labeled standard tapes weren't as suitable for such service.

| improve this answer | |
  • There could be various considerations, not just the price of a physical drive. A hard disk drive could require more ongoing maintenance, as a head failure would ruin the whole disk pack and the heads. – Leo B. Jan 14 '17 at 7:35
  • 1
    You should add that one feature of the encoding of DEC tapes was that a block could be read both forwards and backwards, which made random access a bit faster. Also, at least for OS8, there was a "system" tape on which some memory pages were swapped out if some part of the system had to be swapped in. So random access was essential for the OS. – dirkt Jan 14 '17 at 9:00
  • The recollection I have of ANSI labeled tape (the half-inch tape standard) was that it could detect a tape mark either forward or reverse, but could only read forward (so finding the file named 'readme' would take a lot of search/stop/play cycles). – Whit3rd Jan 14 '17 at 22:10
  • ISTR the later TK50 tape drive from DEC could also do random access. – scruss Jan 14 '17 at 22:54
  • Are you sure about "late 1970's"? I distinctly remember being fascinated by the random access tape on a PDP at Birkbeck College, London University. I used it for some master's degree coursework, so it had to be before 1975 when the degree was awarded. Until then, I had only seen big reel-to-reel tapes that were very much sequential devices. – Patricia Shanahan Jan 22 '17 at 15:27
3

There's another use of tape drives that is "sort-of" random access and floppy-like, besides DECtapes: The Exatron Stringy Floppy and the ZX Microdrive used tapes that consisted of a closed loop in a cartridge, and was used for home computers (TRS-80 resp. Sinclair ZX Spectrum) as a cheaper alternative to floppy disks. The loop was transported much faster then the audio cassettes that were also used for storage, and used higher quality type, so access times and capacity were comparable to a floppy disk.

However, the tape was not pre-formatted, organziation was not by blocks, but by files, and there were no skip commands (the loop was read/written continously). So if you don't restrict your question to that particular way of organzing it, then yes, there were other kinds random access tapes as well. (I still wrote this up as an answer instead of a comment, because it's much too long for a comment).

And of course nobody thought about replacing them with IBM tape drives. :-)

| improve this answer | |
  • Some comments to the inner working of the microdrives: The tape was actually formatted into blocks (size 512 bytes) rather than files, very much like any sectored medium of that time. The block structure could be maintained because the microdrive circuitry had a white noise detector that could generate an interrupt on the (non-formatted, so noise-generating) gaps between formatted blocks, so the start of a sector passing by the tape head could be signalled to the CPU. Microdrives actually have a map ("sector" 0) that holds the file-to-sector mapping. – tofro Jan 14 '17 at 10:54
  • @tofro: Could you actually replace blocks rather than files? I skimmed through a manual (of the Exatron, not the Microdrive), and had the impression that this was not possible (because of "file mark records" between data blocks, etc.). The Exatron also didn't have a file-to-sector mapping. So maybe the Microdrive was closer to a floppy. – dirkt Jan 14 '17 at 12:03
  • 2
    Yes, microdrives really can replace single 512-byte blocks, so are "fully random-access" (if you accept a worst-case access time of 7s, which is the time for the full length of tape loop to pass the r/w head). The block marks (Sinclair called them "Sector headers") are BTW separated from the actual data blocks by above gaps and only written during a format of the tape and never re-written in normal r/w operations. The MD file system is very close to a floppy one, so deletion or truncation of a file would only mark the affected blocks as "unused" in the map. – tofro Jan 14 '17 at 12:12
  • 1
    By design and in theory, they did have true random access. In practice, ZX Microdrives were somewhat unreliable, so relying on random access wasn't something you could do. The tapes stretched terribly, 'growing' sectors as they did so. It was prudent to format a microdrive cassette several times before first use, as only then was the cartridge capacity vaguely stable. – scruss Jan 14 '17 at 22:51
  • @scruss Disagree - There's no technical difference between "random" and "sequential" access in microdrives (that's a logical thing, nothing to do with the hardware). The hardware does exactly the same in both cases. Microdrives are still in use 35 years after they've been made and work well provided some care is taken - I think that can account for "pretty reliable" - ZX Microdrives were better than their fame. – tofro Jan 15 '17 at 9:02
2

It is very unlikely this was ever done on legacy reel-to-reel tape machines, since the time to wind through a 2,400 foot tape to find the next block of data would have been ridiculously slow.

In commercial computing applications, the standard way to process a large dataset in "random order" was to start by sorting it into the required order. This could be done using sequential reading and writing with several tape drives. For example with three tape drives, you could first copy (unsorted) sections of the data onto several tapes, and then read a block of data from two tape drives, sort it in memory, and write it in sorted order onto a third drive. Repeating that "merge sorting" procedure enough times would sort an arbitrarily long data set.

In principle, the IBM S/360 tape drives could have done this, because they were capable of backspacing over a data block, and then reading or writing with the tape moving forwards. But writing new data in this way could cause problems, since the data blocks on tape could be of variable length, and obviously you could not replace a block by a longer one.

This "backwards reading" was used in some specialized applications - for example in solving systems of equations which were much larger than the available main memory, it was possible to write intermediate results onto a tape, and then read them backwards, while doing more calculations, and writing the final results to a second tape. I used software that worked like that in the 1970s.

There were various special-purpose storage devices that used many short loops of tape to achieve a reasonable random access speed, with much more storage capacity than the available magnetic disks (which often had a capacity of only a few Mb, not a few Tb as now) Once such device was the https://en.wikipedia.org/wiki/IBM_2321_Data_Cell.

Hardware failures on the 2321 and similar mechanical devices could be "entertaining" - the data could literally end up being shredded and scattered around the computer room floor!

Later, the https://en.wikipedia.org/wiki/IBM_3850 was a much larger scale version of the 2321, using tape cartridges storing about 50Mb with a robot device to mount the tapes onto drives and transfer the data to disk for access by the computer. By 1980, the largest model could store about 500Gb - but in a 20-foot-long cabinet, not a 2 inch diameter PC disk drive!

| improve this answer | |
  • Thank you for the information about the IBM 2321 device, but that's beside the point. The rest, unfortunately, is an example of the Straw Man fallacy. – Leo B. Jan 14 '17 at 6:20
  • You're assuming only one usage model, a very impractical one at that. Of course, the block size would be fixed, as it is on contemporary HDDs that don't have any externally visible structure but blocks. Of course, nobody would want to use a tape to search through records stored in arbitrary order in a data structure spanning most of the multi-megabyte tape. – Leo B. Jan 14 '17 at 6:30
  • A typical usage model would be treating a range of blocks as a smallish "virtual disk", creating a file system allowing only contiguous files (like RT-11 did), then seeking to beginning of that block range at the start of a job and working with a particular "virtual disk". – Leo B. Jan 14 '17 at 6:31
1

The Coleco Adam was an early home computer that used a pair of block-addressable cassette tapes as its secondary storage. I helped a friend develop a Forth interpreter for it, but the system was quickly outdated and it went nowhere.

Even at the time, everyone understood that this was a sub-optimal solution to the problem of block-addressability. There was never a "need" for these systems to be emulated; everyone migrated to disks (floppy or hard) as soon as it became feasible.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.