HP3000-L Archives

July 2000, Week 4

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:
Jeff Woods <[log in to unmask]>
Reply To:
Jeff Woods <[log in to unmask]>
Date:
Thu, 27 Jul 2000 20:21:31 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
At  04:23 PM 7/27/00, H Campbell <[log in to unmask]> wrote:
>I need a program that will read a dat tape and report on the number of
>blocks read and the size of each block.  If it makes any difference,
>the tape was written with FCOPY.  We are running MPE 6.0
>Can anyone point me to such a beast?  Thanks.

Umm...  Well, I think FCOPY can do that.  ;)

What file equation was used when FCOPY created the tape?  That will
determine the block size.  I presume that the tape is unlabeled as opposed
to an ANSI or IBM labelled tape.

All the blocks will have fixed sizes.  If you set up a file equation with a
fixed block size (might as well use 32768 bytes [16384K halfwords] which
IIRC is the maximum block size "mere mortal" code can use with a DDS tape
on MPE) and one record per block (e.g., "file t;dev=tape;rec=-32768,f,1,1")
and then "fcopy from=*t;to=$null" the number of records read is the number
of blocks.  (Note that the EOF that FCOPY reports is the number of
records/blocks since the first record is number 0.)

I have on several occasions used FCOPY with ";hex;char" and various
permutations of file equations (and in some cases ";deblock=" parameter) to
look at the data from a tape and determine the record structure (fixed,
variable or whatever), record size(s), block size and blocking factor but
it's something that's aided greatly by some notion of what the content of
the tape is expected to be and has been something of a trial and error
process.  In general, if one can see patterns in the data then that can
provide clues as to where records start and end and such things.

IIRC (It's been a while.) using a block size on the file equation larger
than the tape was written will work and the extra space in the blocks will
be nulls (binary zero) whereas reading with a block size smaller than the
tape was written will cause the data past the end of each block read to be
skipped.

--
Jeff Woods
[log in to unmask] (preferred)
[log in to unmask] (work)
[log in to unmask]
[log in to unmask] (deprecated)
[log in to unmask] (deprecated)


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

ATOM RSS1 RSS2