Ron Tilby <[log in to unmask]> sent me some valuable information that I
believe is important for the whole HP3000 community, because its analysis
clarifies several issues that other users have expressed/experienced. So,
I am posting my comments to HP3000-L and I am sharing them with SigIMAGE's
Executive Committee. Please pay particular attention to my comments
regarding the EOF for a DDX-enabled dataset.
>In the case of dbutil erase altering datasets' EOFs, Adager does offer
>therapy >when it detects a problem.
>
>I was running adager against the erased db precisely because I know you
>religiously check for internal consistency. And if the db looks messed up
>to >you, then the odds are really high that it is in fact messed up.
>
>The attached screen dump shows the db in a good state, the dbutil erase, and
>the problem that adager detects.
Thank you very much for the information. I can already see several places
where I can improve Adager. See my comments in ###### below. I'll
restrict myself to just dataset #8, to save bandwidth. I have also snipped
lots of irrelevant lines (yes, I know that Adager tends to be a bit
verbose...)
:LISTFILE MOPSD1@,2
ACCOUNT= FINTST GROUP= PRPUB
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
MOPSD108 PRIV 512W FB 782 859 1 3440 14 2
^^^^^^^^^^^^^^
###### The dataset is enabled for DDX, so the EOF is not the same as the limit.
###### For DDX datasets, the EOF corresponds to the current capacity and the
###### limit corresponds to the MAXIMUM capacity.
:ADAGER
Database MOPSD1.PRPUB.FINTST. Adager command [EXIT] ? REPORT CAPACITY
Capacity-report output file [THIS TERMINAL] ?
MOPSD1.PRPUB.FINTST has 32 DataSets: FRI, OCT 9, 1998, 1:22 PM
BufferLength 601 Detail
If Jumbo: * High-
-Blocking- Max water
Set# Name & Type Fields Paths Factor Len Capacity Entries %Max Mark
8 DEDUCTION D 24 2 7 512 6013 4080 67.9 5381
Dynamic expansion: 49 (increment) 5474 (current cap.)
###### Adager confirms that, indeed, this is a DDX dataset.
:DBUTIL
HP30391C.07.10 TurboIMAGE/XL: DBUTIL (C) COPYRIGHT HEWLETT-PACKARD COMPANY
1987
>>ERASE MOPSD1
Database Selected => MOPSD1.PRPUB.FINTST
Do you want to continue with ERASE (Y/N)?Y
Database MOPSD1.PRPUB.FINTST has been ERASED.
>>EXIT
END OF PROGRAM
:LISTFILE MOPSD1@,2
ACCOUNT= FINTST GROUP= PRPUB
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
MOPSD108 PRIV 512W FB 859 859 1 3440 14 2
_____________________________________________________________________________
###### Oops! Somehow, DBUTIL/erase has INCREASED the EOF (which
corresponds to
###### "capacity") to be equal to the LIMIT (which corresponds to "MaxCap" for
###### a DDX dataset.
###### This may be a NEW issue not related to the underlying file-system
###### functionality that DBUTIL/erase invokes (and that was the fundamental
###### reason for DBUTIL's problems while erasing).
_____________________________________________________________________________
:ADAGER
Database [NO MORE] ? MOPSD1
IMAGE/SQL Database MOPSD1.PRPUB.FINTST: Consistency checking
DEDUCTION D DdxJumbo@282 Calc/Act EOF: 782 859
###### Adager detects that its calculated EOF should be "782" (to
correspond with
###### the dataset's current capacity) but the actual EOF is "859".
###### Adager then gives a few options, based on "a nail to hang its hat"
which,
###### unfortunately in this case, is not a reliable "nail" and Adager goes
on to
###### suggest therapy on the RootTables (including the dataset's BlockFactor).
###### Adager gives you a little discussion of BlockFactor issues, so you know
###### what is involved, and so on, just in case you are not familiar with the
###### esoteric details.
(Given MediaLength = 73 and MPE RecordSize = 512,
7 is the maximum feasible BlockFactor. NOTE: the bitmap requires
one 16-bit word for every 16 entries in the block.)
You may change BlockFactor
BlockFactor [7] ? 7
###### Adager suggests the CURRENT value as the default, which you wisely
chose.
###### After re-calculating everything, Adager detects that nothing has changed
###### and uses a different module to report the independently-arrived-at
result:
EOF according to root (782) is not equal to the file's EOF: 859
###### This Adager diagnostic is accurate and precise and uses the English
###### language much better than the diagnostic above, which speaks in
jargon such
###### as Calc/Act -- shame on me :-)
BlockFactor: 7
DEDUCTION D
###### So, Adager asks next for a new capacity (because EOF corresponds to the
###### concept of "current capacity").
Capacity [5474] ?
###### You answered with "return", which left the default (current) value
###### unchanged. Adager is not pleased with the current state:
We need to be consistent with the file's EOF: 859
###### Adager's "need" to be consistent with the EOF is misguided, because we
###### know (in hindsight) that the EOF is wrong!
###### This is, in fact, the unreliable "nail" for Adager's hat. I'll improve
###### Adager's intelligence in this regard, so it doubts EVERYTHING --
including
###### the file's EOF, and gives you the option to change everything, including
###### the EOF. In this particular case, the EOF should be 782, as calculated
###### by Adager from the RootFile.
For BlockFactor 7 and Capacity 5474, I get 782
Modify BlockFactor [NO] ?
Modify Capacity [NO] ?
###### Adager, according to your instructions, does not change anything and the
###### dataset continues to be as inconsistent as it was at the beginning.
##############################################################################
In this particular case, having fixed the EOF would have still left garbage
in those parts of the dataset that were not properly "zeroed out". So, the
problem is more fundamental than "just the EOF".
Regardless of the "garbage" problem, though, the main issue is the following:
Why did DBUTIL/Erase fail to honor the EOF for a DDX dataset?
Specifically, the EOF for a DDX dataset must correspond to the dataset's
CURRENT capacity (just as the LIMIT for a DDX dataset must correspond to
the dataset's MAXIMUM capacity). For vanilla (non-DDX datasets), the EOF
and the LIMIT must coincide (and, as expected, the current capacity is the
same as the maximum capacity for non-DDX datasets).
##############################################################################
While we are all examining "the" PP5 problem, we might as well clean up
everything we can in the process. I'll be busy tonight. I wonder how many
other people will do the same...
_______________
| |
| |
| r | Alfredo mailto:[log in to unmask]
| e | http://www.adager.com
| g | F. Alfredo Rego +1 208 726-9100
| a | Manager, R & D Labs Fax +1 208 726-2822
| d | Adager Corporation
| A | Sun Valley, Idaho 83353-3000 U.S.A.
| |
|_______________|
|
