HP3000-L Archives

August 2000, Week 2

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:
Denys Beauchemin <[log in to unmask]>
Reply To:
Date:
Wed, 9 Aug 2000 09:00:53 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (93 lines)
Just for informational purposes, the root file does not carry the entry counts
for the various datasets.  The root file does have the information about the
capacity and expansion values, but not the current entry count.  Actually the
current entry count is not kept anywhere.  The various datasets store the
current number of unused entries.  The current entry count is computed every
time by subtracting the number of unused entries (obtained from the dataset)
from the current capacity (obtained from the root file.)  With the advent of
expandable datasets, more information about capacity is kept in the dataset
labels.

However, if you were to restore a root file that was out of synch with the
datasets, i.e. it carries different capacities that what is actually out there,
you will be in trouble.  Just as if you restored a dataset that had an actual
capacity different that what was recorded in the root file.  To say nothing of
the problems with even the addressing the entries in masters.

As for the pathing issue that Joseph mentions, I am a little confused.

"Thirdly some masters have more than one path. If the master changed because of
the secondary path and you restore the master based on the primary path then
you've got trouble."

Masters do not have secondary or primary paths, details do.  I do not
understand how one would restore a master based on any path.  What would
definitely cause problems is to have a master and one or mode details restored
out of synch.  The master would not have chains to newer detail entries or the
master would have chains to entries that are gone and may have been replaced by
other entries thus yielding interesting chains, to say the least.  You could
also have orphan entries, where a detail entries has no corresponding master
entries.

All in all, not a good thing any way you look at it.

Kind regards,

Denys. . .

Denys Beauchemin
HICOMP
(800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
denys at hicomp.com                             www.hicomp.com


-----Original Message-----
From:   Joseph Rosenblatt [SMTP:[log in to unmask]]
Sent:   Wednesday, August 09, 2000 8:04 AM
To:     [log in to unmask]
Subject:        Re: TURBOSTORE question...

It depends on how you did the backup. If you used the DBSTORE parameter then
the whole DB was stored and you can restore it al with no ill effects. If
you restore just certain datasets you run a number of risks. Firstly your
root file's record count may differ from the dataset's count. Secondly
related masters may not reflect the data of the restored detail dataset.
Thirdly some masters have more than one path. If the master changed because
of the secondary path and you restore the master based on the primary path
then you've got trouble.

For these reasons it has always been my practice to do a DBSTORE even on
partials.

----- Original Message -----
From: "Rich Trapp" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, August 08, 2000 5:14 PM
Subject: [HP3000-L] TURBOSTORE question...


> Gang,
>   Ok, I feel ignorant w/o a box to play with...I guess humility is good
for
> me. (no comments Art!)
>
>   Some of my cohorts are asking if a partial backup will store only the
> datasets that have been modified, or if it will store the entire database.
>
>    We're working on some recovery plans and we're wondering if restoring
the
> latest partial over the latest full will cause the database to be
> inconsistent.  Doesn't seem likely even if only rootfile and datasets that
> have changed are stored...everything should be consistent (right?).
>
> RAT
>
> _______________________________________________________________________
>  Rich Trapp "RAT"
>  Managed Business Solutions   [log in to unmask]   http://www.mbsnav.com
>  Assigned to Design Automation Support at Agilent Technologies
>  Telnet or 970-679-2221 [log in to unmask]  Loveland, CO USA
>
> _______________________________________________________________________
>

ATOM RSS1 RSS2