Review by Shawn Gordon
While ensuring data integrity in your
database may not be the most interesting or glamorous topic of
discussion, it will save your bacon if you have planned ahead. Very
few shops that I have had experience with take the time to code their
applications so that they can cleanly recover from an incomplete
A logical transaction could be thought of
as a customer ordering a part from you. You would reduce inventory,
create a purchase order, create a billing record, etc. Each of these
physical transactions make up a logical transaction. If your program
were to die for some reason, such as a disk crash or power outage, in
the middle of the logical transaction, you would have incomplete data
in your database.
Intact D/R (which I will refer to as just
Intact from now on) allows you to set up a safety net for rolling
back logical transactions. It also has some interesting uses for
testing an application and removing the data afterward.
How does it work?
Intact makes use of IMAGE logging in
conjunction with its own intercept to keep track of transactions and
allow rollback of those transactions. The intercept for Intact has to
be run at logon time for each process. This can be set up as a logon
UDC to make sure everyone is running through the trap. If you
dont do this, then you wont be able to roll anything
You can configure the software so that
Intact rolls back to the DBOPEN, say in the case of a long batch
update job. Rollback to DBBEGIN, if the application calls DBBEGIN,
and DBEND is never encountered before the termination of the program.
Then the activity from the DBBEGIN will be rolled back.
There doesnt appear to be the same
size limitation that exists in your standard DBBEGIN..DBEND construct
for automatic rollback through the transaction manager. That limit,
last I heard, was around a meg and a half of data.
Figure 1 below shows a list of valid
commands. Whats interesting and a little annoying about the
products help is that it goes to pains to show you the short
version of each command but using the short version of the
command isnt valid inside the help facility.
Basically you configure databases for
Intact to stay aware of when you enable the traps. In conjunction
with that, you can configure database specific messages that will
display when that particular database has a process go into a
rollback state. You can also display global messages that will
display to the console whenever a database has a process activate the
Intact rollback. After you go through these simple setup issues, you
can make use of the other features.
As I mentioned earlier, you can have
Intact rollback to the DBOPEN for a process, which would be pretty
much everything the program has done, or you can have it rollback
around a logical transaction that is bracketed with DBBEGIN..DBEND.
They have also implemented a DBUNDO intrinsic that you can call
manually to roll out transactions. Imagine something like a
maintenance screen where the user goes Oh no, I didnt
mean to save that. You could set up a rollback key they could
press to automatically undo the transaction.
Now the DBBEGIN..DBEND..DBUNDO stuff
sounds pretty similar to the DBXBEGIN..DBXEND..DBXUNDO that was
implemented a short time back. You have more external control over
the rollback, and much more extensive reporting with Intact, with
less work on your part (as far as I can tell). The manual goes on at
length to describe the various scenarios in which you can apply
Intact. This is helpful, because it brought up a number of scenarios
that I hadnt thought of yet.
Installation and Documentation
Installation is very easy and went
smoothly. The software is strictly 3000-based, so we just restore,
stream a job, and are done. The documentation starts off as a
discussion on the various uses of Intact and how Intact works, and
the various types of rollback and reporting options. The manual then
turns into a description of each of the INUTIL commands.
The biggest problem with the manual is
that there is no getting started guide. Intact requires
that you have IMAGE logging enabled, and if you dont already,
that can be rather confusing to set up. There is also nothing that
tells you a standard sequence of events for setting up your database
I spoke with Lund about these
documentation problems, and they agreed that it would be a good idea
to put in the information. So that little issue should be solved by
the time you read this.
The Test Drive
My first step was to pick or create a
database to put Intact on. I figured I would just use my own DataWarp
product to do the data transformations, because its a nice
generic tool for mass updates of date fields. I wanted to try this on
a program that didnt have DBBEGIN..DBEND, and then have it roll
back to the DBOPEN.
The first challenge was in figuring out
how to turn logging on for my sample database. A quick call to Lund
solved that problem (and prompted them to agree to add instructions
to the manual). So I tried changing some data and aborting the
session in the middle of it. Strangely, I had no results. I tried
this a few times with the same lack of results.
A little later I happened to be browsing
through the files that were restored and noticed the UDC file. This
is where I discovered the LOGON.INTACTIX.LPS program that has to run
BEFORE your process starts accessing the database, to enable the
traps. I was never able to find any reference to this in the
Once I solved all the setup problems,
things went very smoothly. It was pretty cool seeing this stuff just
automatically rollback when the session got aborted. If you look at
Figure 2, you will see the
process where the session was executing, and I aborted it and Intact
took over and rolled everything back before they let the session
finish aborting. I dont know how they are implementing their
traps, but this was pretty nifty.
One thing that I wasnt able to try,
which you should try if you consider buying this product, is how it
works with database shadowing tools such as Quests Netbase and
Lunds own Shadow. I dont know what, if any, issues might
arise from having multiple traps going on with your database
The documentation is the weakest part of
this product. I had to stumble around for a while before I found out
that there was a logon UDC that initiated the traps for the product.
If you read on through into the Shadow portion of the installation
instructions, you could probably figure out how to get the IMAGE
Aside from that, Intact works, and it
works well. If you choose to just make minimal use of it for certain
critical batch processes, you could just put the trap at the
beginning of your job and not have to change your programs at all. If
you want to make more elaborate use of it, then you would probably
want to add DBBEGIN/DBEND to your programs around the logical
transactions (which you should do anyway).
There are some interesting side benefits
to the ability to reverse transactions, such as using it as a testing
facility and not having to worry about the details of pulling the
data back out again. (Of course, if you are testing a huge amount of
data, then this probably isnt the most constructive way to use
Intact.) I can easily recommend this product for those who are
interested in really protecting their data.
Shawn Gordon, whose S.M. Gordon &
Associates firm supplies HP 3000 utilities, has worked with 3000s