From KENM@U.WASHINGTON.EDU Mon May 23 13:49:57 PDT 1994
>From @UWAVM.U.WASHINGTON.EDU:KENM@U.WASHINGTON.EDU  Mon May 23 13:49:56 1994
Received: from mx2.u.washington.edu by wells.u.washington.edu
	(5.65/UW-NDC Revision: 2.29 ) id AA17503; Mon, 23 May 94 13:49:56 -0700
Received: from uwavm.u.washington.edu by mx2.u.washington.edu
	(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA22551;
	Mon, 23 May 94 13:49:50 -0700
Message-Id: <9405232049.AA22551@mx2.u.washington.edu>
Received: from UWAVM.U.WASHINGTON.EDU by UWAVM.U.WASHINGTON.EDU
   (IBM VM SMTP V2R1) with BSMTP id 0700; Mon, 23 May 94 12:32:02 PDT
Received: from U.WASHINGTON.EDU (KENM) by UWAVM.U.WASHINGTON.EDU (Mailer R2.10
 ptf008) with BSMTP id 1556; Mon, 23 May 94 12:26:31 PDT
Date:         Mon, 23 May 94 12:24:19 PDT
Sender: KENM@UWAVM.U.WASHINGTON.EDU
From: KENM@U.WASHINGTON.EDU
Subject:      05/23: mead*, tscan
To: Listserv List <CHANGE-L@U.WASHINGTON.EDU>


The addition of the (real) 3480 drives to mead has caused a problem
for tscan. Tscan determines the sizes of tape blocks by executing a
read() call specifying a number of bytes that is equal to or larger
than the largest possible block size. For the STK drives, the largest
block is 262143 bytes, but a read() can be issued for any number
of bytes.

For the real 3480s, however, an error is returned if a read() requests
more than 65535 bytes.

I propose to make two changes to tscan:

1)Have it, on initialization, 'auto-range' to determine the largest
  acceptable block size, between zero and a default maximum (262143
  until we get some drives w/ larger blocks).

2)Add a 'MaxBlock' command to override the default.


I plan to make the change as soon it's ready, hopefully this week,
since the current tscan is not useful with the IBM drives.

In the interim, you can circumvent the problem by
  a)for the IBM drives only, run ~kenm/ttscan/tscan, which has
    a hardcoded max of 65535.
  b)use tms to change your tape from a 3480 to a 3490 (so it
    will be mounted on the stk drives).
.