Roy,

We have thought about the matters you mention.

As you are probably aware, a DBOPEN opens only the root file. It is only when the first DBGET or PUT
or DELETE or UPDATE or FIND (did I leave any out?) is executed that the appropriate dataset(s)
is/are opened. We were hoping that since these three datasets (a detail and its two masters that
have no paths to other details) are being read, we could pull it off.

It seems we cannot do this on datasets. We tried a set of posix commands that someone suggested in a
private note, and it failed.

Thanks for the thoughtful note.

Leonard
--
Leonard S. Berkowitz
Perot Health Care Systems
(Harvard Pilgrim Health Care account)
voice: 617-509-1212
fax: 617-509-1955
pager: 781-226-2431



                      "Roy Brown"
                      <[log in to unmask]        To:       <[log in to unmask]>, <[log in to unmask]>
                      emon.co.uk>                               cc:
                                                                Subject:  Re:      Re: [HP3000-L] PURGELINK ERROR
                      07/03/2003 12:08 PM
                      Please respond to "Roy Brown"






---- Original Message ----
From: "Leonard S. Berkowitz" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, July 03, 2003 1:39 PM
Subject: Re: [HP3000-L] PURGELINK ERROR

> Robert,
>
> Content only. We routinely flip datasets independently of the balance
> of the data base.
>
> We run a process that takes 11-14 hours, on an alternate machine to
> update a detail dataset and its two masters that have no paths to
> other datasets. As it happened on this last run, we knew that the
> datasets would be open for read access (reference) when the round
> trip would occur. We were/are hoping that PURGELINK would help us
> here.
>
> It seems to me that a dataset is a file, albeit  with some special
> attributes. PRIV; linked internally the data (a/k/a pointers); user
> file labels, etc. If the dataset is open for reference (read), why
> should it be different from our PowerHouse dictionary that we can
> replace with a new version while 900 users have it open? Perhaps the
> PRIV file code is getting in the way.

Leaving aside the question of the mechanics of it all (PRIV mode generally
means 'Here Be Dragons', but I'm sure that many of us here regard ourselves
as skilled dragon-tamers, and proceed accordingly), a dataset may indeed be
a file, but it's not a stand-alone file. As indeed you recognise, observing
that you need to consider the 'molecule' of the detail plus its two masters,
and that you cannot get away with changing just the 'atom' of the one detail
set.

But Image would prefer that the smallest 'molecule' anyone works with is the
whole database, and tries to ensure that with PRIV files. Even though you
know that here you can get away with a few short cuts, and go into PRIV mode
yourself, to replace just those three datasets, entire.

And indeed, I've pulled a few similar stunts myself. But only ever on
databases that weren't open at the time. I've always figured you would
*really* have to know what's going on on the root file and in the database
control blocks to make such a dynamic swap safely.

And I don't (though perhaps you do). But I know a man (or two) who will know
though, and the name Alfredo comes to mind. I wonder what he thinks?

Re the Powerhouse dictionary; what's happening here isn't quite the same,
though. This *is* logically one file. But from the issue of the PURGELINK to
the last close on the open file, there are two versions of it. The original,
the file your users have open (and for as long as they have it open) isn't
touched at all by the PURGELINK. It just has its directory links broken, so
no-one new can open it.

The second copy, the new file, is linked in the directory, so anyone who
opens the dictionary after that point gets the new one.

But your running users don't see the new version, and so their use of
Powerhouse isn't modified at all by you installing it. Not until they stop
and restart the process, anyway; they only get the new one when they re-open
for business. (Or when and if Powerhouse does this for them transparently -
depends if it opens the dictionary for the duration, or only as it needs
it). The original file finally goes away when (and only when) the last user
closes it.

The other thing about PURGELINK - can you PURGELINK a file open for writing?
If you think about it, PURGELINK really only makes sense on files open
read-only. I suppose if you had log files running that you didn't really
want, it wouldn't matter that some users were writng to the new one, and
some to the old, unlinked one that was slated to die as the last accessor
closed it, but it would be a pretty restricted use. And that's what $NULL is
for, anyway.

Now think about all this in a database - what's the open here, the base or
the set? If anyone were writing (I know no-one is) there'd be carnage, with
some users updating the old copies of the datasets, and some updating the
new ones. And where would the pointers to other datasets go?

I wonder if, even though you have a database open only for reading (at the
user level), it's really open for writing (at the MPE level), for control
information and such?

--
OE-QuoteFix 1.19.1 doing what it can to render the OExperience bearable.
Sig seps are fixed in the updated OE6, but they won't let me load it :-(

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *