Wirt asks:

> Jumbo datasets are going to go away on their own as soon as a flat 64-bit file
> space is put into MPE. Because Jumbos were never represented as anything more

Well...perhaps not immediately :)

Why?

  1) ability to create sets > 4GB that will work on older releases;

  2) caution/distrust of Large Files

  3) time ... to change the jumbo code in IMAGE to use Large Files
     *or* jumbo datasets!

But...I agree...the multiple-file implementation of jumbo was a stopgap...
we argued for implementing large files directly in MPE, but recognized that
it would take much longer, and that the multiple-file implementation would
be solving users problems much, much earlier.

> However, putting the b-tree files into the HFS filespace was the one great
> thing I regretted about the way b-trees were implemented. That's a lot more

Awww.

If that's all, then I'm happy!

...particularly since it's a good idea :)

> likely to be seen as permanent structure (although it shouldn't be; this stuff
> is still called SOFTware). Nonetheless, I want to know: "Who's idea was it to
> use HFS file extensions anyway?"

Mine, IIRC.

We already had 200+ possible two letter extensions allocated (TC, GB, 199 sets),
*plus* a number unknown-to-me for some TPI products (<root>1A, <root>1B, ...,
up to (?) <root>9Z>)
Sure...there are 1296 combinations to choose from, and we've used only
about 400 or so of them.   But...do you really want to remember things
like "AA" is B-Tree for 01, "AB" for 02", "AI" for 09, "BA" for 10, etc.?
Besides...what about the users with files that already matched those
extensions?

A secondary consideration was that the name should show up near the dataset
in a LISTFILE ... because the data in it is conceptually tied to the dataset!

A third consideration is that this use of HFS filenames is a tool to help
users start thinking about using HFS filenames ... they're quite useful :)


Yes, there are drawbacks to using HFS filenames ... like "STORE BASE@" ...
but then again, what that really exposes is the *real* drawback: a backup
product that's not sufficiently aware of IMAGE databases :)



--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html