Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
On Thu, Oct 18, 2018 at 7:23 AM Paul Koning via cctalk < cctalk@classiccmp.org> wrote: > > > > On Oct 18, 2018, at 4:31 AM, Christian Corti via cctalk < > cctalk@classiccmp.org> wrote: > > > > On Wed, 17 Oct 2018, Clem Cole wrote: > >> As Paul W pointed out correctly, the TK50 and its children in the DLT* > >> family all used a fixed format 512 byte *blocks on the tape*.This > > > > And that is wrong. The TK50 clearly uses variable block sizes. For > example, have a look at a RSX11 or VMS tape: ... > > Different point. You're talking about the host programming interface; > Clem was talking about the physical representation of the data on the > tape. Clearly it's easy to accept random-length blocks from the host and > translate them to a sequence of 512 byte blocks on the media. SIMH is an > example of how that is done: it stores tape images as a count field plus > data, laid down in a disk file that internally consists of a sequence of > fixed length (512 bytes, traditionally) sectors. > Although they may be on the tape in some funky way, there's a higher layer in the protocol stack that imposes block length, and if that's not properly honored, the tapes written for Ultrix won't work when read back. You can't write weird block lengths and expect the applications that read it downstream to work. I have a vague memory of lecturing one of the hydrologists I worked for in college on this point when they were sloppy with their reading / writing of a TK50 with their water flow data on it... The code fix, which I wound up doing, was easier than explaining this concept to the hydrologist who, while he knew finite difference code better than I ever learned, had trouble understanding record boundaries In the end, though, we got a larger disk so we could stage / unstage multiple runs of data at once and then used VMS' BACKUP to save them to tape... The TK50's were a *LOT* faster when the only job on the system was BACKUP since they could stream and none of the other OS activity could get in the way... Warner
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
> On Oct 18, 2018, at 4:31 AM, Christian Corti via cctalk > wrote: > > On Wed, 17 Oct 2018, Clem Cole wrote: >> As Paul W pointed out correctly, the TK50 and its children in the DLT* >> family all used a fixed format 512 byte *blocks on the tape*.This > > And that is wrong. The TK50 clearly uses variable block sizes. For example, > have a look at a RSX11 or VMS tape: ... Different point. You're talking about the host programming interface; Clem was talking about the physical representation of the data on the tape. Clearly it's easy to accept random-length blocks from the host and translate them to a sequence of 512 byte blocks on the media. SIMH is an example of how that is done: it stores tape images as a count field plus data, laid down in a disk file that internally consists of a sequence of fixed length (512 bytes, traditionally) sectors. paul
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
On Wed, 17 Oct 2018, Clem Cole wrote: As Paul W pointed out correctly, the TK50 and its children in the DLT* family all used a fixed format 512 byte *blocks on the tape*.This And that is wrong. The TK50 clearly uses variable block sizes. For example, have a look at a RSX11 or VMS tape: # mtdump AQ-RAE30-01.tap Processing input file AQ-RAE30-01.tap Processing tape file 1 Obj 1, position 0, record 1, length = 80 (0x50) Obj 2, position 88, record 2, length = 80 (0x50) Obj 3, position 176, record 3, length = 80 (0x50) Obj 4, position 264, record 4, length = 80 (0x50) Obj 5, position 352, record 5, length = 80 (0x50) Obj 6, position 440, end of tape file 1 Processing tape file 2 Obj 7, position 444, record 1, length = 2048 (0x800) Obj 8, position 2500, record 2, length = 2048 (0x800) Obj 9, position 4556, record 3, length = 2048 (0x800) Obj 10, position 6612, end of tape file 2 Processing tape file 3 Obj 11, position 6616, record 1, length = 80 (0x50) [...] Processing tape file 5 Obj 21, position 7328, record 1, length = 9216 (0x2400) [...] Processing tape file 8 Obj 363, position 3061188, record 1, length = 2048 (0x800) [...] Processing tape file 62 Obj 2370, position 19735716, record 1, length = 32256 (0x7E00) [...] Christian
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
I took most of this off line, but I'll try to close down the discussion, so we can get back to TUHS history. Please be careful of your wording as it is easy to get confused particularly if you never used the original 1/2" tape system you might not understand the actual terms. The term for reading Read and Write I/O Sizes in a user program are different than tape block sizes (or as they were originally referred LRECL - Logical Record Length). As I said to Paul K, I sadly know way more about the minutia of tapes that I really should admit [I broke in during the 60s using 7-track tapes on the IBM Mainframes which really date me and I remember the 5-track tapes on one of the systems, but I never personally used it]. On Wed, Oct 17, 2018 at 2:14 AM emanuel stiebler wrote: > Longer blocks, too (2k or so) which would make any buffering issues more > severe. > *Your user program read/wrote with 2K or more using DMA reads or writes but it wrote 512 byte 'blocks.'* As Paul W pointed out correctly, the TK50 and its children in the DLT* family all used a fixed format 512 byte *blocks on the tape*.This cannot be changed. The tape format is handled by the tape controller microcode and all of the blocks on all the streamers (DLT, 1/4, 1/2", 4mm and 8mm) that I know about were fixed at 512 byte, although the OS could write multiple (N) blocks at a time to the tape controller which will will write as N blocks on the tape. This was different from 1/2" parallel 7 and 9-track tape which was actually had variable size 'blocks' in the writes and the tape format. Since the terminalogy was defined (by IBM) for 5/7/9 track drives, we still use that terminology. The trick is that streamer** format write* (which is bit seral): <512 bytes of serial data [blk1]><512 bytes of serial data[blk2]>.<512 bytes of serial data>[blkn] The key is that there are no inter-record gaps (IRG) between the and < frames when recording on a streamer. BTW: they usually use a serpitine scheme - starting with the center of the tape and moving outwards in a circular pattern - IIRC down on tape end and up on tape start -- but that's fuzzy in my memory and I'm at work so I can not look in any of the controller books have at home. If you lose the bit stream on input (data under run), the tape controller backs up the tape and when it starts to write again, it goes over the last block trailer and start its new write at the end of it. For instance the original 1/4" QIC format wrote 4 passes, then later when the recording head got better, it wrote 9 passes and then even more, but in the newer formats (and withe better media) the head was smaller. Also remember that EOT is handled different in the streamer formats from 1/2" 7/9 track and IIRC EOT can even differ between the different streamer formats. If you look at 1/2" parallel 7/9-track (which is where the terms and basic concepts originate) 9-track has a 'inter-record gap' between the last block's trailer and the next block's header. When IBM originally defined that 7 and 9 track formats (whch ANSI later codified), these gaps are defined so that the there is time to start and stop the motors (somewhere, I have a very old IBM document from the late 60s that describes this very well using IBM terms like LRECL and DASD - direct access storage device ;-) The key difference from a streamer tape is that the IBM LRECL or logicial record size, could (and did) vary ***. But to try to keep the amount of wasted space (*i.e.* least amount of inter-record gaps), different programs use different 'block size' and some formats (like ANSI labeled tapes) the block size (LRECL) can vary within the tape itself. Also, I don't think I ever knew why, but for some reason IBM's tape utilites tended to like LRECL 10240 and 20480. Since many of us UNIX folks came from IBM and Multics, we also used the same sizes (*i.e.* 20b or 10240 8 bit bytes) - it was reasonably efficent (we got 150M per traditional 2400" 1/2 tape at 6250 BPI - you could get 1/3 more space when 3M created a 3600" that fit in the original 1/2" reel) . Thus the on-tape format of 1/2" (which is parallel encoding and one pass over the tape): .. [if the last last 'file' on the tape a second] Note: LRECL BYTES of BLK1 did not have to be the same as much less Thus concept (and term) of 'tape blocks' was born. Also note be careful the term 'file' has specific meaning to a tape. DEC started to use the term 'save set' to disamiguated it BTW. A tape 'file' N tape blocks, followed by an a EOT mark.Thus, two adjacent tape marks actually delinated end of recorded data in the tape. Thus in 7/9 track formats when a new file is written the last is backed up over and data frame writing starts over writing the second after the last So ... what this all means is that from the OS side, you start a DMA on X blocks and then let the tape controller read or write it. No matter the number of
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
> On Oct 17, 2018, at 10:50 AM, Ethan Dicks via cctalk > wrote: > > On Wed, Oct 17, 2018 at 8:15 AM emanuel stiebler via cctalk > wrote: >> there were >> TK50Z as an external drive, on "SCSI" > > I have one - for a MicroVAX 2000. I rarely used it. > >> TK50 on QBUS with an TQK50 controller which really didn't stream to often > > We had one in the 1980s. You are right. It didn't. I wonder if that was a VAX-specific issue. It streamed fine on J-11 based PDP11 systems running RSTS. While most VAXen have faster CPUs than PDP-11s, that doesn't necessarily carry over to I/O. paul
Re: TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
On Wed, Oct 17, 2018 at 8:15 AM emanuel stiebler via cctalk wrote: > there were > TK50Z as an external drive, on "SCSI" I have one - for a MicroVAX 2000. I rarely used it. > TK50 on QBUS with an TQK50 controller which really didn't stream to often We had one in the 1980s. You are right. It didn't. > TK50 on QBUS with an TQK70 controller, which doubled the memory of the > TQK50, which was capable of streaming ... Ooh! That works? I might have to nab a TQK70 for that MicroVAX II I have (the one we had at work in the 1980s. I got it when the company folded). Mostly, really just need to image any tapes I have more than write new tapes, presuming the media hasn't degraded too much in the past 30 years. -ethan
TK50, was: Re: [TUHS] Ultrix Tape: Block Size?
On 2018-10-16 20:37, Paul Koning via cctalk wrote: > > >> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk >> wrote: >> >> DEC Tape II was the serial driven TU58. >> The TK50 was CompacTape or something like that. It was the predecessor of a >> number of square tapes... >> >> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape >> >> Bill > I used DLT on RSTS systems, with a Qbus interface. Those were modest speed > hosts and buses, but I never remember data late or overrun issues, and we > drove those tapes quite hard in full time streaming mode for backup and > software distribution. Longer blocks, too (2k or so) which would make any > buffering issues more severe. Just few words here, as I'm not sure anymore we are talking about the same thing ... there were TK50Z as an external drive, on "SCSI" TZ30 internal drive, on "SCSI", using TK50 tapes TK50 on QBUS with an TQK50 controller which really didn't stream to often TK50 on QBUS with an TQK70 controller, which doubled the memory of the TQK50, which was capable of streaming ...
