Rdb 7.0 and PH 6.10/6.20

[Ravenscroft, Wanda L]

In response to Gordon's message with regard to "What does lock up the
database mean?", I should rephrase that to read it locks up the application
to the point where it takes a long time for the screen to respond when the
user tries to update or find a record.  As I mentioned yesterday, this only
happens about once a month.  Each time it happens, I call the user to find
out the screen they're using when this happens and what kind of mode they
were in (i.e, find, etc).  I unfortunately am not in the same location as
the user so I have to depend on them for accurate information.  If they are
giving me accurate information, they've just logged into the application to
the screen where they would do a find to retrieve a record.  Their cursor is
just sitting at the action block and as of yet they've done nothing to cause
the application to respond as slow as it does.  Once I get that user off,
all the locks clear up and performance of the application is back to normal.
The other thing that's puzzling is when we check the lock of their process
id, it shows them at an event flag, but as I mentioned before, they've only
logged into the application and their cursor is at the action block ready to
do a find or enter.  Another point I should make is that nothing has changed
with the screens with regard to how they're opening the database.  We are
going to be upgrading to VMS 7.1 this weekend so whether or not that will
make a difference, I don't know.

Any ideas are greatly appreciated.

Wanda Ravenscroft
Analyst Programmer
Eveready Battery Co.
St. Louis, MO



-----Original Message-----
From: Kevin Gordon [mailto:Kevin.Gordon@seacontainers.com]
Sent: Thursday, August 05, 1999 6:07 AM
To: powerh-l@lists.swau.edu
Subject: RE: Rdb 7.0 and PH 6.10/6.20


As my name has been bandied around I thought I'd better chip in here. This
has evolved into what I believe are two totally separate issues. The issue
with the change in locking behaviour between PowerHouse 6.00 and 6.10 was
well documented at the time and caused much grief to lots of sites. We never
used the PRE_610_COMMIT parameter, but you may find that defining your
transaction model as OPTIMISTIC in the dictionary helps (SYSTEM screen,
action TRAN, option 1 - needs recompile to take effect). This feature was
introduced in 6.10E to help resolve the mayhem caused by the change in the
default behaviour in between 6.00C and 6.10C.

As far as RDM$BIND_SNAP_QUIET_POINT (yes that is the right name for OpenVMS)
is concerned - that was specifically to do with RMU on-line backups stalling
after upgrading to Rdb 7.0, not general PowerHouse locking problems.
Unfortunately there was not enough information in the original post from
John Webster about the nature of his problems. I can't see that it is
relevant in Wanda Ravenscroft's case (what does "lock up the database"
mean?) because her Rdb version is 6.1.

And as for the hijacking of this thread to talk about Impromptu and
Peoplesoft - please will you start your own! Thank you.

Regards,

Kevin Gordon
Sea Containers, London.


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.