Gavin is correct, I should have clarified the term "lock"
when I used it.  I also agree that there is probably no
reason not to enable DSEM, but "absolutely no downside" is
probably not an altogether valid statement either since there
will be a slight amount of overhead to manage the multiple
semaphores.  If your database structure is such that you
end up locking/unlocking all of these new semaphores for
every update action instead of just one, you "may" see some
impact. I like Gavins idea of 'enable/disable/default'.  It
would easily allow you to disable this feature if you found
that it didn't help you, while allowing new features to be
introduced at a setting beneficial to the majority of users.

Regards,
Michael L Gueterman
Easy Does It Technologies
Allaire Alliance Partner
email: [log in to unmask]
http://www.editcorp.com
voice: (888) 858-EDIT -or- (509) 943-5108
fax:   (509) 946-1170
--

> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of Gavin Scott
> Sent: Thursday, August 20, 1998 10:38 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] "SUB-DATABASES"
>
>
> Michael writes:
> >   I haven't looked at the Communicator article yet, but could
> > it possibly be talking about the use of the 'DSEM' setting in
> > DBUTIL?  If so, then what this means is that within any Image
> > database, all datasets that are logically related (via set paths)
> > are considered an atomic unit when placing a lock on the
> > associated master dataset.
>
> The term "lock" in this case doee not mean the kind of locks
> applied with
> DBLOCK.  It refers to the internal Image semaphores (the
> "SEM" in DSEM)
> which are used internally to control access to Image's own
> data structures.
>
> Image used to have one semaphore for the whole database and there were
> certain operations which required locking this briefly.  This probably
> wasn't a very big issue for single CPU systems, since the
> semaphore wasn't
> held all that long, but for very busy systems and especially
> for multi-CPU
> boxes, the DSEM option can get you more throughput.
>
> The question about whether there is any downside to turning
> on "DSEM" was
> asked at SigImage at HP World and I believe the answer was essentially
> that there is absolutely no downside to turning DSEM on,
> unless there are
> bugs in it that haven't been discovered yet.  The only reason
> it defaults
> to off is probably Image's historically conservative approach
> to enabling
> new functionality.  Perhaps a future Image release will always enable
> this functionality.
>
> This points out a problem with new features like this.  They
> generally have
> a flag in the root file only indicating whether the feature
> is enabled or
> disabled.  I suggest that there should be a third option
> called "default"
> which means that Image should do what it thinks is best.
> This way a new
> feature can be introduced and for a while the default action
> would be to
> disable the feature, then later the default could be changed
> to enable the
> feature for all databases.  A user could at any time change
> the flag from
> "default" to "enabled" or "disabled", giving complete control over the
> feature.  DBUTIL SHOW would indicate which features were set
> to "default"
> and what the default value actually was for that Image version.  This
> would allow HP to start out conservatively, then once the new
> feature has
> proven to be safe, all databases (except those that
> specifically disable
> the feature) would automatically start taking advantage of it when the
> user upgraded to a new release.
>
> G.
>