HP3000-L Archives

November 2005, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Thu, 3 Nov 2005 15:02:37 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
Re:

> The problem with that is that STORE to Disc ALWAYS creates disc files 
> with a 32K blocksize, the user cannot control this at all.  This 
> means that TAPECOPY is useless unless one first creates the STORE 
> file on a tape device with a buffer size less than 32 kb and 
> maxbuffer not set.

Good point.  AFAIK, the original TAPECOPY was probably written to
go "tape to disk", and then "disk to tape" was added.

I just tested it, and found it worked fine ... because (perhaps by chance?),
no records were written that were greater than the max TAPECOPY can handle.

If any such records had been seen, you'd get a message like:

        Note: %ld maxbuf (%d) records read\n", max_cnt, MAX_REC_CHARS);
        ...that may imply that some records were larger
        than TapeCopy could handle, and that some data
        was lost.  Run TapeCopy with no PARM/INFO for
        information about this possible problem.

TAPECOPY handles up to 32760 bytes per tape record.

I just tried storing a bunch of files (using an uncompressed STORE-to-disk),
and the largest STORE-to-disk record found was 29280 bytes.

-- 
Stan Sieler
work:     www.allegro.com
personal: www.sieler.com/wanted/index.html  

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2