What else do you get then? I can see from the IBM 2400 manual here:- http://bitsavers.trailing-edge.com/pdf/ibm/24xx/A22-6862-4_2400_Series_Magn… that write checking is accomplished by reading. There really isn't anything else you can do when a write fails... .. well you can retry the write... Not on Vacuum Column drives. The columns provide enough mechanical buffering to start and stop within the Inter Record Gap.

Some drives will back up, get up to speed, read the end of the previous block, switch from write to read when the irg goes by. The size of the irg can vary upwards from a minimum spec, at least in drives that try to stream, as they will keep the tape running for a moment in hopes that data will arrive to be written. De

On 06/10/2015 03:39 AM, Johnny Billquist wrote: My recollection is that the 0.6" gap was for 800 BPI, and that they went to a 0.3" gap for 1600 and 6250. Yes, other than some super-low end drives like Kennedy digital incremental and some Pertec drives, most drives were read after write. This required completely independent read and write hardware. I got a Pertec key to tape system surplus, and created a mostly software interface with very minimal hardware to read and write tapes on my S-100 Z-80 system. It would write, back up and re-read the block to verify. My recollection was there was only one data head, so it HAD to back up to read the data. My interface and the Z-80 was maxed out doing one or the other, so that was fine. Usually, it would just rewrite over the bad record. Only if the bad record remained after several retries and a cleaner cycle, would it do the extended gap, to move the record to a new (and hopefully better spot on the tape). All tape systems I know of wrote essentially identical gaps whether doing start/stop or streaming. Speed of transfer goes way up if you can avoid the start/stop, but it made no difference in capacity of a tape. The record gaps are set by ANSI standards for data interchangeability. I wrote a disk dump/restore program for our PDP-11 a long time ago. I discovered there was a 10 us "reinstruct window" in the Datum controller, so if you could just get a new write or read operation loaded into the controller within that time, it would stream the drive. No way to do that with interrupts, but with double buffering and doing everything by polling, it was just barely possible to make it in time. It required error-free media, but if you had that, you could dump or restore a 40 MB Calcomp disk to 45 IPM Pertec mag tape in under ten minutes, including rewind. It was a total block for block copy, not a file by file copy, so the tape was pretty useless except for restoring again to a disk pack. Jon

On 08/03/2015 03:40 PM, Al Kossow wrote: The system I had was, I'm pretty sure, made by Pertec. I still have the manuals for it, and curiously they don't list ANY manufacturer in the title block. It was a really small thing, about 19 inches wide and 12 inches tall, with a fairly stock spring-arm 9 track drive with 7" tape reels. I couldn't find the listing on eBay. Jon

On 08/03/2015 09:06 PM, Al Kossow wrote: Instruction set? This was not a computer. It was an all hard-wired-logic key to tape system. It could be set to enter data to tape, verify data by retyping it, and it would beep if a record did not match, or allow you to view the tape contents on a panel of lights, one bulb per EBCDIC character. The thing had a core memory buffer to hold one 80-character record, only keeping 6 bits per character. I ripped out all the key to tape logic, fortunately, it was designed with a mag tape sort of interface at a particular card slot, so I left the 3 boards or so that managed the tape drive, and then supplied the rest of the interface with a few one-shots and some 8-bit wide registers, and a bunch of timing loops. I used this mostly to back up my S-100 hard drive. OK, I verified it was indeed made by Pertec. The title block of the drawings doesn't have anything real obvious, but there is a bunch of legal boilerplate advising the restrictions on use of the drawings, and the last words are "prior written permission of Pertec". Jon

This hypothetical interface + matching software would be intended for archiving old tapes and/or making new copies from archived file (i.e., to make new boot media for bringup of an old computer). Key features would include preservation of block sizes (even if varying arbitrarily) and file marks. I'm not sure if there's already a good file format for that, and I have a dim memory of previously reading a lament about common archival methods failing to preserve blocking. This thing would have some sort of ad-hoc interface(s) (USB? Ethernet? Standalone with an SD card for storage? Pneumatic?), specifically to avoid being flavored by any particular operating system's idea of what a tape drive ought to look like. Is there any other sort of metadata that should be included? Any wish lists for features or file format details? I'm just brainstorming, and this isn't guaranteed to ever see the light of day, of course. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

Cool! I will look them up. Being able to use the images in a simulator without any further translation is a plus. I will look that up, too. And that is precisely why I'm thinking of an ad-hoc interface rather than just plugging a SCSI drive into a UNIX box. Chuck's comment about his USB to Pertec project woke up my own dormant Pertec interface project idea in my cluttered head. Hmm, this might be as simple as a BeagleBone Black board with an LCD board (both of which I already have), and a custom board with a cheap FPGA and the Pertec electrical interface. Yeah, I could probably implement the interface just fine in software using a fast microcontroller with lots of GPIOs. But FPGAs are what I know best. "When your only tool is a hammer, every problem ends up looking like broken pottery." -- Me -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

On 6/10/15 8:40 AM, Dennis Boone wrote: I need to figure out why this program also doesn't deal with tape errors well. If you get an error, it will go into an endless loop creating -1 byte records.

On 6/10/15 11:25 AM, Dennis Boone wrote: The current spec is 'undefined'. Bob extended it in Simh but behavior on read errors was never specified. John Bordynuik extended it in other ways in the tapes read by JBI, Inc., but I never found out what those extensions were. As was discussed on the Simh list, there is a bunch of information, like drive type and how it handles bad blocks, that should be in the tape image, but currently is not. I would think an error that returns no data would be a single error mark, but one with returned data should be two to handle the read reverse case.

On Wed, Jun 10, 2015 at 9:40 AM, Dennis Boone <drb at msu.edu> wrote: Nothing using standard SCSI commands, unfortunately. Might be some vendor-unique stuff.

On 8/3/15 11:00 PM, Chuck Guzis wrote: It would to be nice to look at. I was back at cartridge tape recovery this weekend so SCSI is the only method I have right now for reading carts.

On 08/04/2015 09:54 AM, Chuck Guzis wrote: Scratch that--it helps if what you're working with is actually a .tar file. Nevermind. It's not even 10:30AM and it's already been a long day... --Chuck

On 08/04/2015 06:17 PM, jwsmobile wrote: I know the feeling from my short time with X3J3 (Fortran (was supposed to be 88, but became 90)). The reps from DEC and IBM both threw a hissy fit and threatened to withdraw if the committee didn't ratify their particular extensions. It was not a nice experience. It's really odd that the raw Pertec-style interface, even with its various vendor extensions, is still more robust and versatile than the SCSI version. On the other hand, the SCSI standard (X3T10?) does a pretty good job of generalizing tape robots. Wasn't Exabyte the only vendor of 8mm tape backup? I've seen other brands but they all seemed to have Exabyte internals. 4mm DLT is/was remarkably robust, particularly when you consider the mechanical intricacies. I was really surprised to see the medium extended to DAT-320. Apparently, there's yet another generation in the works. On the other hand, the consumer-level tape backups are really terrible; Travan, DC-2100, etc. The worst of the bunch was the Datasonix Pereos that used a (wait for it!) 2mm tiny tape cartridge that one had to order --Chuck

On 6/10/15 8:15 AM, Mark J. Blair wrote: It also has the advantage that you can return the CRC/checksum and partially read blocks. Most SCSI tape drives don't return the data if the read doesn't succeed. Some drives have a seismic mode for dealing with oil exploration tapes which returns anything read, but it has it's own set of problems (it will happily return garbage if the density doesn't match)

On 06/10/2015 09:12 AM, Mark J. Blair wrote: Acceptable? I don't know about that. Otherwise, it depends on the drive. Some will allow a density change only at load point. Not that unusual--the EOT marker is mostly intended as a warning when writing. Long-record tapes frequently write past the EOT. On the old CDC vacuum-column (60x, 65x) drives, I'd sometimes add an extra BOT marker or two on a reel and start a new "logical tape" there. You just hit the "LOAD" button again while the tape was already loaded and it would space down to the next BOT marker. I don't know if anyone else's drives did that, though. I had my pet deadstart tapes with several different versions of a system on them. Half-inch tape comes from a more polite, gentler era. Although, on the 7-track drives, you could toggle the parity, which would confuse the heck out of someone trying to read the tape. --Chuck

On 06/10/2015 09:40 AM, Al Kossow wrote: Just stick another BOT marker somewhere within the label area, take the drive offline and hit LOAD, setting your new density accordingly. AFAIK, no drive pays attention to the BOT status while reading. --Chuck

than the read and that my No idea. I suspect most drives will only change density at BOT a I seem to recall ALL applications put data after the EOT marker, should they fill the tape. So on a write you get an EOT reached status, BUT to get this you must have written past the EOT marker. If its non-labelled tape you write a tape mark, rewind and unload the tape and ask for another. It is up to the application program to know there is more data. Typically on a mainframe you wrote labelled tapes, so you needed to write a Tape Mark and the End of Volume Label and any other labels needed, then another tape mark, then unload and ask for the next reel. This usually goes after the EOT marker. For labelled tapes the label tells you if there is another tape in set. I don't believe you can do that. IBM Mainframe copy protection usually involved using the serial number of the Mainframe. Total PITA when doing Disaster recovery checks....

That _would_ be really nice. As others have indicated, portability of such a tape would be poor. I'll add two thoughts to the other answers: 1. The specs say there's supposed to be quite a bit of tape (10 feet, I want to say) after the EOT reflector. 2. It was not unheard of for broken applications to run a tape clear off the source reel. The drive reports the passage of an EOT marker. Few systems enforce any behavior in this regard. If you keep going, you keep going. At least until the tail comes off the source reel. De

On 06/10/2015 12:36 PM, Johnny Billquist wrote: ...and some errors are correctable by the formatter (and so indicated on the interface). I see no way to indicate that in the SIMH tape proposal. Earlier, I discussed how I've begun appending metadata to tape image files after the EOM indicator. Thus far, no simulator chokes on it. I really need to extend it. Right now it just indicates date, device information, notes from the person doing the reading and error messages during reading and file structure; e.g. 536 x 10240 bytes Filemark at block 537 3 x 80 bytes... Okay for now; save for a photo of the tape. Basically, anything known before and during reading of the tape and writing of the image. --Chuck

On 06/10/2015 02:07 PM, Dennis Boone wrote: Well, it could be, but if it were my show, I'd greatly extend the file format to accommodate not only the occurrence of a tape error, but also the "type" of error. Some formatters will raise the error flag during the transmission of a single frame in error. It might be useful to have some way to notate that--assuming that a controller is capable of recording such an event. In my case, it's mostly reading tapes and providing the data to customers. So blocked EBCDIC record files have already been unblocked with EBCDIC->ASCII translation. The .TAP file is provided as a reference in case of my getting something really wrong. If it's a UNIX(R)-type unlabeled tape, I extract the data between filemarks and assign a name of 0001, 0002 and so forth. --Chuck

On 06/10/2015 05:06 AM, wulfman wrote: Mainframe/vacuum column drives were pretty darned reliable. I have memories of tossing about a half-dozen tapes into my big Samsonite briefcase and hopping a plane to travel cross-country routinely. I don't think I ever gave a thought to the reliability of the tapes. All in all, I think I had more problems with disk drives than with tapes. After all, didn't the IRS keep its taxpayer records on many many reels of half-inch tape for decades? Anent Pertec IFs: You have to understand that the Pertec interface is extremely simple-minded from a bygone day There are minor differences between manufacturers in the amount of information and features afforded by a given formatter, but generally, they do adhere to a common model. One thing that I've never cared for on *nix tapes is that the implementors never enforced any sort of standard tape label records. That can be very frustrating if the physical labels have dried out and gotten lost or if they're cryptic (e.g. "Joe's archive"). The label records on, say, an IBM SL tape can tell you a great deal about the tape contents. Even CDC on their NOS 9-track tapes tended to include ANSI labels before lapsing into the gobbledy-gook that was 6-bit display code and 60 bit words. Perhaps some UNIX(R) installations implemented an ANSI labeling scheme, but to be sure, AT&T didn't use any on their distribution tapes. --Chuck