Date: Sun, 13 Apr 1997 01:21:00 GMT
Reply-To: Dave Hrivnak <DHrivnak@MYSELF.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Dave Hrivnak <DHrivnak@MYSELF.COM>
Organization: Preferred Company
Subject: FSEDIT and Locking with RDB
I have found that if one uses SAS/FSEDIT to modify a record in a table and
the FSEDIT session remains open it will stall an overnight backup in RDB.
This effective locks the entire system bringing many headaches the
following morning.
Background: We have a rather large production system that uses SAS and RDB
for part of it's functionality. I have used SAS to maintain some of our
master tables because SAS requires so little code. However, I may have
just found out that with ease of programming comes great danger. If a user
is running FSEDIT and has modified a record (effectively changing access to
read/write) the record retains a lock until FSEDIT finishes. If the person
gets distracted and leaves, that record remains locked. The backup will
encounter the lock and wait for it to be released. Since backup will also
do some locking, one will find most of the database deadlocked. In theory
I should be able to use AF and SCL to lock and unlock selectively but I
would prefer not to do that as the code required jumps about 50 fold. The
other option is to kill suspended SAS jobs. Has anyone has any experience
with FSEDIT and locking? If we can resolve this problem we could greatly
improve our productivity. Locking a system used by 950 users to make and
ship more than 60,000,000 pounds of product a week can not be tolerated.
Any help or guidance would be appreciated.
I KNEW I SHOULD HAVE GONE TO SUGI!!!
--
Dave Hrivnak
The view expressed are mine and mine alone.
|