| Author |
Message
|
| vamsi |
 Posted: Fri Apr 19, 2002 8:12 am Post subject: |
 |
|
Newbie
Joined: 17 Apr 2002
Posts: 4
|
There is a cobol program whose input is from a MQ
Every message read from the queue is being inserted into a DB2 table
For every 50 messages read the program COMMITS both the DB2 table and MQ
so as to keep both in sync.
The problem is the program ran with the MQ having 100 records.
After reading 75 records the pgm has faced a critical error of not having space on one of the output file and it abended.
Db2 rolled back to the last commit and the number of insertions were 50.
But the MQ had already read 75 records and the table is not in sync with the MQ
How can the 25 messages after the last commit be recovered into the MQ.
The read on the MQ is done with MQGET function and SYNCPOINTNO option.
and a commit is peformed for every 50 records.
Can anybody let me know what the problem is.
If there is any autocommit after every MQGET how can we determine that.
The program is on the mainframe
Thanking you
Vamsi
|
|
| Back to top |
|
 |
| EddieA |
| Posted: Fri Apr 19, 2002 10:43 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Quote:
The read on the MQ is done with MQGET function and SYNCPOINTNO option.
If you really meant the 'MQGMO_NO_SYNCPOINT' option, then you are telling MQSeries NOT to Syncpoint. So as you read each message, it will be removed from the queue.
You might also want to look into using MQSeries to CoOrdinate the MQGET and the DB update, as it sounds like you are treating the commits to MQ and the DB as seperate calls.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| vamsi |
| Posted: Mon Apr 22, 2002 7:04 am Post subject: |
|
|
Newbie
Joined: 17 Apr 2002
Posts: 4
|
Thanks Eddie for your reply,
I have tried the option SYNCPOINTYES but still i am loosing the data.
Can you please let me know how the concept of Commit and Rollback
can be implemented in the program while using MQ alone.
program reads from mq and writes the data ino another mq or a flat file.
Thank you
vamsi |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 22, 2002 8:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
IMS is coordinating the UOW on the mainframe. You need to tell IT when to commit.
MQCONN
MQOPEN
do until 2033 no more messages
MQGET (with syncpoint)
insert to DB2
IMS-CHECKPOINT call (this will commit the MQ message and the DB2 call)
end do
MQCLOSE
MQDISC
or
MQCONN
MQOPEN
do until 2033 no more messages
MQGET (with syncpoint)
insert to DB2
add 1 to counter
if counter = 50 or no more messages
IMS-CHECKPOINT call (this will commit the MQ message and the DB2 call)
set counter to zero
end do
MQCLOSE
MQDISC
Be careful of that IMS checkpoint call! It commits EVERYTHING running in that transaction. If MQ and your DB2 table are it, no big deal. If your MQ/DB2 program ise but a small part of a much larger transaction with other updates to other resources, who are you to commit all of them when it's convienient for you? 
I left out error checking logic, specifically Poisened Message Detection.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Mon Apr 22, 2002 11:29 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
What environment are you running in, is it a plain MVS batch job, an IMS environment or are you running under CICS as the resource co-ordinator?
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 22, 2002 12:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Oh yeah, I guess that makes a differance, doesn't it?!?! I saw the word mainframe and automatically assumed IMS!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Tue Apr 23, 2002 1:47 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Hi folks,
On OS/390 there are the Resource Recovery Service(RRS), which allows you the do the trick.. just by linking CSQBRSTB instead of CSQBSTUB, then MQCMIT will do the two-phase commit. The nice way would be to code it using the SRRCMIT call as show below.
MQCONN
MQOPEN
do until 2033 no more messages
MQGET (with syncpoint)
insert to DB2
SRRCMIT
end do
MQCLOSE
MQDISC
I've tried it and it seems to work, but take a look in the manual....
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| vamsi |
| Posted: Sat May 18, 2002 3:34 am Post subject: MQ rollback problem |
|
|
Newbie
Joined: 17 Apr 2002
Posts: 4
|
Hello All!
The problem reappeared again and it is now solved as per
Mr.Pedersen's code mentioned.Thanking you all for sparing your time.
Regards
vamsi |
|
| Back to top |
|
|
| zpat |
| Posted: Sun May 19, 2002 11:30 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Syncpointing defaults to ON with mainframe queue managers.
You can just use the CICS unit of work and MQ/CICS/DB2 will all work together. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed May 22, 2002 6:33 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
On Z/OS and all other platforms you have to have a syncpoint/commit coordinator, one who take the responcibility to control the two phase commit protocol.
And it's right that on Z/OS online systems: Transactions Server (formerly CICS), it takes the role of doing that task, IMS regions it's the same situation.
In Z/OS Batch it's another question, because there are no (was), coordinator. Today there are the RRS to take charge of that role, but you have to concact this service... and tell it to do it's job.
As far as I recall it MQSeries can act as coordinator in the distribued world.....
Just my 2 cents. 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
