Eben asks:
> I've been challenged by one of my coworkers with regard to transaction
> rollback, row-level locking, and checkpoints in IMAGE and COBOL.
>
> Question:  Would appreciate it if the IMAGE gurus out there would provide
> feedback concerning the time and effort required to accomplish all the
> above in COBOL.  The concepts are simple, but is the implementation worth
> the effort?  We could simply run this particular program during off-
> hours.  Running it during the hours where online OLTP is being performed
> is not recommended unless these "serious" IMAGE functions are incorporated
> into the program.

Well, what do you want to get out of it?

Transaction Management in the form of the DBX functions is easy enough to
add to a program, and is useful even if only one program is modified, but
DBX transactions are seriously limited in size so you can't have the entire
program run be a single transaction unless it's not doing very much.

Image lacks transaction isolation, so the only way to get some of the
benefits of transactions is for all users (including readers) to do strong
locking on everything, so that nobody sees the results of a partial
transaction (which might get rolled back).

Row-level (a.k.a. item or "predicate") locking is only useful if all the
programs accessing the data are modified to *correctly* implement this style
of locking.  Row-level locking in the presence of set-level locking
generally just turns the row-locks into whole set locks (or worse).

I'm not sure what you mean by "checkpoints".  Again, DBX transactions are
size-limited such that partially-committing transactions wouldn't generally
be useful.

Tell us more about the problem.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *