Commitment Control and Data Queues
Julian H. Lloyd
OS/400 does not support placing data queues under commitment control
directly from a COBOL, RPG or CL. However, if I read the manuals
correctly (Backup and Recovery - Advanced V3R1 and the System API
Reference V3R1) it should be possible to do this from a C/MI program
using the QTNADDCR API. Two questions:
1) Does anyone have experience of doing this?
2) If so, what should the Commitment Control Exit Program do to
commit/rollback the data queue?
Any thoughts on these topics would be much appreciated.
Julian H Lloyd
steve Poole
Although this is not a technical answer to your question; I wonder if
you had looked at MQSeries/400 to do the queuing you need?
MQSeries would provide you with the ability to place messages on a queue
under commitment control , and then commit or rollback.
MQSeries does loads more of course, but without understanding more
of what you want to do I don't know if MQSeries is a good fit.
If you want to know more pleae email me or add a reply here.
The TEAMIBM Network
Julian, I can't address your first question firsthand (at least from a
product point of view - I wrote much of the code to support this stuff),
but here is one way that the commitment control APIs can be used (this
is applicable to any type of object, not just data queues).
1. Create a journal.
2. Use QTNADDCR to register API resource (IPL processing option = Y,
Qualified journal name = journal created in step 1, Resource protocol =
2, Call for reqacquiring locks during IPL = Y). Identify the data queue
by specifying its qualified name, or a pointer to it, in the Commitment
control exit program information parameter.
3. Before making the first change to the data queue, use some sort of
locking protocol to prevent other users from being able to see
uncommitted changes (depending on the commitment control lock level that
is being used (available via the QTNRCMTI API)).
4. Just before each change is made to the data queue, use the QJOSJRNE
API to send a user entry to the journal created in step 1. (Force
journal entry = 1, Include commit cycle identifier = 1). The entry
should contain enough information to 'undo' the change to the data queue.
5. Use the QTNRMVCR API to remove the resource from commitment control
when you no longer want the data queue under commitment control.
The exit program that you specified when you used QTNADDCR in step 2
will be invoked during the following times:
A. Runtime commit. This means the application performed a commit
operation. At this time your exit program should simply release the
lock acquired in step 3 (the information specified in the Commitment
control exit program information parameter will be passed to the exit
program, allowing it to figure out which data queue to unlock).
B. Runtime rollback. This means the application performed a rollback
operation. At this time your exit program should receive the entries
you sent to the journal on behalf of your data queue in step 4 (the
information specified in the Commitment control exit program information
parameter will be passed to the exit program, allowing it to figure out
which data queue, and it can use the RTVJRNE CL command to find the
changes made to the data queue during the transaction - ask it to return
only journal entries with code U (user entries) and the current commit
cycle identifier (a parameter passed to the exit program)). Then, one
by one, undo each change based on the contents of the entries (starting
with the last entry and continuing to the first). Finally, release the
lock acquired in step 3.
C. Reacquire locks during IPL. This means the system crashed while the
transaction was in doubt (meaning that the system doesn't know whether
to commit or rollback - this can only happen if changes were being made
to remote resources during the same transaction). At this time your
exit program is running in a server job (named QDBSRVnn where nn is a
two digit number), and should reacquire the lock acquired in step 3 (the
information specified in the Commitment control exit program information
parameter will be passed to the exit program, allowing it to figure out
which data queue to lock).
D.Commit during IPL. This means the system crashed during a commit
operation, either just before or after your exit program was called. At
this time your exit program is again running in a server job, and should
make sure that the contents of the data queue are consistent with the
entries that have been written to the journal in step 4 (it is very
unlikely, but possible, that the last change to the data queue was lost
when the system crashed, but the last change would be reflected in the
journal). The data queue does not need to be unlocked because the lock
was lost when the system crashed. You do not need to lock the data
queue before you change it because you are running during IPL before the
application can try to change the object again.
E. Rollback during IPL. This means the system crashed before a commit
operation was performed, or just after a commit operation was started,
but before the system could ensure that all changes made during the
transaction were prepared to be committed. At this time your exit
program is again running in a server job, and should read through the
journal and undo any changes made during the transaction (similar to
step B). The data queue does not need to be unlocked because the lock
was lost when the system crashed. You do not need to lock the data
queue before you change it because you are running during IPL before the
application can try to change the object again.
F. Commit after IPL. This means that step C. has already been
performed, and now the system knows that the transaction should be
committed. At this time your exit program is running in the same
server program as it was in step C. and should take action similar to
step D. and then unlock the data queue.
G. Rollback after IPL. This means that step C. has already been
performed, and now the system knows that the transaction should be
rolled back. At this time your exit program is running in the same
server program as it was in step C. and should take action similar to
step E. and then unlock the data queue.
A journal is not the only way to log changes (you could for example, use
a user space that forces changes to secondary storage) but it does give
a nice audit trail. There are also many options on QTNADDCR that I did
not go into here, but that you should understand before implenting
anything. It would also be a good idea to study the commitment control
chapter in the Backup and Recovery, Advanced book to gain a thorough
understanding of how the system does commitment control.
Randy S. Johnson (3-0620)
XPF Database Transaction Management
Dept HVR, IBM Rochester
Julian H. Lloyd
Many thanks. That's exactly what I needed.
Regards,
JHL
Julian H. Lloyd
Thanks for the suggestion. Actually, the reason I want to be able to use
commitment control with data queues is that I have a program which must
read a data queue and write it to an MQ Series queue, and I want to
treat it as a single logical unit of work.
However, if you have any first-hand experience of using MQ in a large
AS/400 environment, please post a reply, or e-mail me, as I'm just
starting out and have a number of thorny issues that I'd like to air
with someone knowledgable.
Regards,
JHL
steve Poole
Julian, if you have any questions or problems with MQSeries then please
let me know - I'll only be to glad to help. I work on MQSeries in
Development so if I can't answer your question directly then I can find
someone who does.
My email address is stephe...@uk.ibm.com or post a reply here.
Trent Andrews
Julian H. Lloyd wrote:
>
> Thanks for the suggestion. Actually, the reason I want to be able to use
> commitment control with data queues is that I have a program which must
> read a data queue and write it to an MQ Series queue, and I want to
> treat it as a single logical unit of work.
>
A simple solution is to use two data queues for transaction processing.
Place the record to be added in both queues one keyed and one fifo. The
update processor can read the fifo queue to write the data to the
database (or another queue) and take the record off the keyed queue if
the process works. If the process doesn't work you will have left over
records in the keyed queue and can handle your rollback processing
however you need to.
--
Trent Andrews
tand...@onramp.net