In <199512082019.PAA06835@gateway> Ron Nadeau <[log in to unmask]>
writes:
>
>How does security 3000 treat such things as a user in the middle of
updating
>a database,with no keys being pressed is it smart enough to gracefully
close
>the database or do you exclude those people with write access from the
>logoff program
 
The answer is somewhat of a "yes and no".  LOGOFF doesn't look for
keypresses -- that would be rather wasteful of CPU resources -- but
instead looks for CPU activity on behalf of the user.  So, "a user in
the middle of updating the database" wouldn't be logged off in the
first place since (presumably) the CPU is busy updating the database
for the user.  However, if the application allows the user to (1) open
a dataset & retrieve data, (2) make partial changes to the data, (3)
prompts the user for more/different data, and at which point (4) the
user goes out to lunch without "finishing the logical transaction",
then yes (possibly) the data will be corrupted.
 
This is the same situation as a dialed-in user on a modem losing the
connection "in the middle of updating a database" or a user at their
terminal when the system manager types ABORTJOB #S123.  (which is, in
actuality, what LOGOFF does)  Since the abortjob/loss of carrier is an
external event to updating the database, the system doesn't know how to
"gracefully" finish the transaction.  ("gracefully" meaning leaving the
database in a logically correct state)  If you are using SQL or similar
access, then you should be surrounding logical transactions with "START
WORK" and "COMMIT WORK" clauses.  Losing a session "in the middle" of a
transaction at that point would be "gracefully" rolled back.
 
Physically, logging off, being logged off, pressing [BREAK] and typing
:ABORT, and anything similar will "gracefully" close all files, but in
this case, "gracefully" simply means that the files are physically not
corrupt, but could still be "logically corrupt".
 
An example to make this clearer:
 
   Detail set 1 has a pseudo-key value -- it's chained to an
auto-master, and the program makes sure there are no "duplicate"
values.
 
   Detail set 2 has the same pseudo-key, and the program ensures that
the user can never enter data into dataset 2 without there being a
similar entry in data set 1.
 
   Now, the user changes the "key" value, so the program dutifully goes
through data set 1, changes the key field (probably by a delete/put
pair unless critical item updating is allowed), then goes on to data
set 2 to perform the same change.
 
   During the change, the system manager (not LOGOFF since it would see
CPU activity for this user) manages to type an ABORTJOB command at
precisely the instant the program has finished DBPUTing the first set,
but hasn't DBDELETEd/put the second set.  The operating system "closes"
the data base, but the data is in a "logically" inconsistent state --
data set 2 now contains a key value that doesn't exist in data set 1.
 
 
--
Tom Emerson
[log in to unmask] (here)
[log in to unmask] (preferred)