Eben writes:
> If the program is run off-hours, there's no problem.  For example, we can
> run a batch of 100 members through the program, change all their values to
> the new correlating ID number, and perhaps it takes an hour.  But if we
> run it during OLTP, someone might do a lookup on that member's claims and
> only find half of them in the system, because the other half has already
> been "changed" to key off the new ID number.  Thus the question, is it
> possible to row-level lock all rows in all datasets that pertain to this
> particular member, change all of them, then commit all transactions

The problem is that dblock does not really "lock" anything at all.  It has
no real affect on anything apart from other dblock calls.  The sole
integration with the rest of Image (that I can think of offhand) is that
DBPUT/UPDATE/DELETE check the lock table to make sure that you have a lock
before doing an update. Otherwise all dblock does is put entries in a table
after making sure there are no conflicting entries already there.  Apart
from the update intrinsics, nothing looks at this table, so DBFIND and DBGET
have no knowledge that Image even has the concept of locking.

So only if *all* your readers call dblock to "lock" the data before reading
it (which means that the dblock call will not return until it can add an
entry to the locks list which does not conflict with other pre-existing
entries) and keep it "locked" until they are done with it can you get away
with this kind of change and be sure that nobody will see a member's data in
mid-change.

This kind of locking is quite rare in MPE applications from my experience,
because it's usually not necessary and it results in relatively poor
throughput.

If you *are* doing this level of locking, then you can lock all the data in
all the datasets in a single database, specifying just the records you need.
But unless all users using dblock *also* lock at the row-level and do it
*exactly* the right way, then all your fancy locking does is turn into
*whole database* locks which will probably slow the system to a crawl (and
may deadlock the database completely, even without MR capability), thus
accomplishing exactly the opposite of what you're trying to achieve.

So the most likely answer is that you're not going to get away with this,
unless the application is already architected from the ground up to support
it.

I assume that your new ID numbers are such that they can't accidentally look
like a valid SSN and so might collide with an existing (not yet migrated)
member's ID.

G.

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