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 logical transaction.

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 don’t do this, then you won’t be able to roll anything back.

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 doesn’t 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.

Features

Figure 1 below shows a list of valid commands. What’s interesting and a little annoying about the product’s help is that it goes to pains to show you the short version of each command — but using the short version of the command isn’t 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 didn’t 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 hadn’t 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 don’t 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 in INUTIL.

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 it’s a nice generic tool for mass updates of date fields. I wanted to try this on a program that didn’t 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 documentation.

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 don’t know how they are implementing their traps, but this was pretty nifty.

One thing that I wasn’t able to try, which you should try if you consider buying this product, is how it works with database shadowing tools such as Quest’s Netbase and Lund’s own Shadow. I don’t know what, if any, issues might arise from having multiple traps going on with your database calls.

Conclusions

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 logging started.

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 isn’t the most constructive way to use Intact.) I can easily recommend this product for those who are interested in really protecting their data.