[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ssag::ask_ssag

Title:Ask the Storage Architecture Group
Notice:Check out our web page at http://www-starch.shr.dec.com
Moderator:SSAG::TERZAN
Created:Wed Oct 15 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6756
Total number of notes:25276

6599.0. "TK50 long tape duplication" by SIOG::BROWNE () Fri Apr 18 1997 10:38

    Hi all, 
    	I work in the E.S.C media room in Galway. A customer (Reuters)
    sends in 2 tapes for duplication on TK50. They are tape 1 and tape 2 of
    a save set. Tape 1 causes problems as the tape is already full and when
    mastered and copied again, the copies usually (always) fail at 99% with
    an end of tape error. We have found one TK50 drive out of 60 will
    usually copy the long tape. It will put slightly more data onto the
    tape if this drive is connected to a MVAXII rather than a 3600.  It
    will not copy at all at a block size of 183,966, but will copy at a
    blocksize of 183855 and attached to the MVAX11. The duplication
    software (imps) has a recomendation of not greater than 160000 or a
    master tape not more than 90% full. 
    Recently we tried to overcome the problem by shortening a tape but
    found that if approx 15 feet were removed from the tape it would not
    work at all, it gave an "eot detected while read/write" error. If we
    removed approx 6 feet we noticed that when doing an image backup to the
    tape that the drive NEVER physically goes to the EOT mark. We are not
    too sure why but it looks like there must be a hardware count in the
    drive. Is there any way we can get round this problem? We are willing
    to give anything a try. Any help or pointers would be greatly
    appreciated.
    Thanks and regards,    
    		Noel P Browne.  
    
T.RTitleUserPersonal
Name
DateLines
6599.1TAPE::PETERSFri Apr 18 1997 13:4711

	Yes, the TK50 knows how long a tape is. If you
change the tape length it will fail.

	I suggest you use SaveSet Manager ( SSM ) to make
your duplicate tapes. It knows about savesets and can
copy multi volume backups.


			Steve P.
6599.2SSM may not be full solution.SIOG::BROWNEMon Apr 21 1997 06:4815
    	Thanks for the quick reply.
    	We are investigating the SSM suggestion, we had not been familiar
    with SSM. However we do not se it completely fixing our problem. If it
    does copy the first tape of the backup then each tape will have to be
    done one to one and without the control of copying software (in our
    case imps). There will also be the problem of verifying the copies. One
    scenario may be if SSM could break up the first tape into two tapes and
    then we could master both tapes and then imps could take control. (This
    still leaves us with the problem of having to modify the customers tape
    every time, something we could do without.) You say the TK50 "knows"
    the length of the tape, how does it do this? Is the count on rom? Most
    important (even if irregular) could we modify this? Any idea as to why
    we have one TK50 which is regularly able to copy on more data than the
    other? Again tkanks for any suggestions or help.
    Noel P. 
6599.3Pad blocksSSDEVO::JACKSONJim JacksonMon Apr 21 1997 10:5318
My recollection (from being based adjacent to the TK50 development team in
SHR) is that the TK50 will insert "pad" blocks in an effort to keep the tape
streaming.  If your host is just a little bit slow in getting the data to
the TK50, it will insert the pad blocks, and you will get less data on tape.
If your host can keep up, fewer pad blocks, more data blocks.  If your host
can't keep up, the tape has to reposition, fewer pad blocks, more data
blocks, tape operations take an eternity.

FYI, tapes traditionally do not have a "fixed" capacity.  The problem that
you are describing has plagued tape copy operations for at least 40 years.
You either have to have a master tape that isn't full, or you have to use
something like SSM and deal with it on a case-by-case basis.

The TK50 development team was well scattered even before we sold the group
to Quantum.

	-Jim Jackson
	 former tape devo (but not TK50)