HP3000-L Archives

March 2001, Week 3

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:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Fri, 16 Mar 2001 21:43:56 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
Tracy writes:
> It's one of the reasons I set my plain
> text files to 128 bytes wide, unnumbered.
> Rather than that wasteful 80 or 72.

While I believe Image still does its own blocking internally (it has never
used the MPE file system record blocking), MPE/XL and MPE/iX no longer store
records "blocked", so there is no such thing as an "inefficient" blocking
factor for an ordinary "flat" file.  All records are stored contiguously
with no slack between "blocks".

If you :STORE a file with the ;TRANSPORT option in order to create a tape
for an MPE/V system, the STORE program will actually restructure the file
into blocked form so that it looks the way things used to back on MPE/V.
Otherwise you can pick any number you like for the blocking factor for flat
files and it won't affect how the file is stored.

So an 80 or 72 byte wide fixed file is much *more* efficient than a 128 byte
record length, assuming you're not using all those 128 bytes for something.
The 128 byte file will take EOF*128 bytes of disk space whereas an 80 byte
file will only need EOF*80 bytes of storage (rounded up to the size of the
extent(s) that have been allocated to the file and a 4096 byte "page"
boundary).

G.

ATOM RSS1 RSS2