HP3000-L Archives

August 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Leonard Berkowitz <[log in to unmask]>
Reply To:
Leonard Berkowitz <[log in to unmask]>
Date:
Mon, 9 Aug 1999 12:50:14 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
What risks do we face in the following situation and how can we avoid or minimize
them?

Our TurboImage maintenance, primarily capacity changes, but occasionally structural
changes, obviously requires exclusive access to the data base. Our data bases are
accessed via HP3000 applications as well as connections via Allbase DBEs. In some
cases, the Allbase access is from a remote system or a PC using HPDARPA and ODBC.

We can control the access via HP3000 applications very easily as LISTF database,8
provides a session or a job that we can "dispense with". We are not concerned that if
we abort a user or a job that there will be any corruption of TurboImage data bases.

It's the access via Allbase that concerns us. It would seem that we can rely on the
same resiliency that protects TurboImage data bases (when we abort a job or a session
on the HP3000) when we "abort" access via HPDARPA and ODBC.

What risks do we face by aborting the ODBCLNSE (via ABORTJOB) and HPDARPA (via
ANSTOP)? Before aborting ODBCLNSE, we clear out sessions via DBCSHELL, but there is
always the chance -- granted it's small -- of a new session sneaking in between the
end of DBCSHELL and issuing the ABORTJOB on ODBCLNSE.

     1) If the remote user is reading a TurboImage data base?
     2) If the remote user is updating a TurboImage data base?
     3) If the remote user is reading a native Allbase table?
     4) If the remote user is updating a native Allbase table?

ATOM RSS1 RSS2