| Author |
Message
|
| ivanachukapawn |
 Posted: Mon Oct 18, 2010 9:47 am Post subject: long running UOW - |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
In response to this problem FJ Saper wrote (in 2006)
| Quote: |
a) never do a prepare commit or a rollback and disconnect
b) do a prepare commit but never commit or rollback and disconnect... |
I wonder about prepare commit - a) indicates that I should never do a prepare commit while b) indicates that I could do a prepare commit but never commit or rollback and disconnect. I'm just wondering what this advice actually intended to advise.
I have long running UOWs and related problems and am trying to investigate and debug via http://www-01.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DA400&uid=swg27010604&loc=en_US&cs=UTF-8&lang=en&rss=ct171websphere
Any help would be appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Oct 18, 2010 10:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It looks like the problem you are having might not be relate to that old post.
Make sure you have sufficient log space to cover your long running transactions...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Oct 19, 2010 6:38 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
You wrote:
| Quote: |
It looks like the problem you are having might not be relate to that old post.
Make sure you have sufficient log space to cover your long running transactions... |
I'm still interested in your 2006 advice to never do a prepare commit, but I followed your advice and found that multiple jobs actually do very large units of work. The jobs in question are jury-rigging an FTP by sandwiching multiple MQPUTs between start trans and commit. These puts are for messages which have max message length of 100mb. Often the transactions transmit >1GB in multiple MQPUTs. I suspect the log sizes are not sufficient to handle this as you suggest. I would like to run some tests (not in production) to 1) duplicate the problem 2) expand the log sizes to find out if the problem can be solved. I have an alarming ignorance of all things Z-MQ and need help. Looking at the manuals I see CSQUTIL COPYPAGE but don't know if this may be relevant to increase log space. Is this a viable way to increase/expand the log file allocations, and if so, how should I go about determining which page sets to COPYPAGE? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 19, 2010 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ivanachukapawn wrote: |
| I have an alarming ignorance of all things Z-MQ and need help. |
You need the assitance of a local z/OS systems programmer. Seriously. The z/OS platform is nothing like distributed & you will almost certainly need a sys prog to run the jobs you need due to RACF considerations.
| ivanachukapawn wrote: |
| Looking at the manuals I see CSQUTIL COPYPAGE but don't know if this may be relevant to increase log space. |
No. Page sets are queue storage.
Try this manual. I repeat, if you do not have experience with z/OS generally do not mess with this and find someone who does. Both the log files and the BSDS are VSAM files that must be modified with z/OS utilities and with some care or your queue manager will turn to a pile of cream cheese in the bottom of the address space.
Even if the sys prog says, "oh, write some JCL & I'll run it for you" don't fall for it. To quote a famous film character:
Get them to amend the files for you based on the JCL used to create the queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Oct 19, 2010 9:52 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
z/OS uses linear logging. so there should be "enough" log space. however, if active logs are too small some data from the current UOW may also be in the log archives. In case of a backout of that uow it increases time required for the backout.
Or you may fill up your active logs if archiving is not able to catch up. This can harm the whole queuemanager.
So you should make sure your UOW can be covered by the active logs.
I addition, there is a "maximun number of uncomitted messagtes within a unit of work" - parameter for each queuemanager. A you deal with (few?) big messages i assume you will not hit this limit, but this is also something that you should take into account when dealing with big UOWs.
Of course pageset storage is an option too and has to be verified. If these big messages are send via MQ channels, you should also consider setting proper channel parameters, e.g. batchsize 1 and whatever is recommended for large messages.
As Vitor already said - see your local z/OS MQ sysprog....... he should be aware of things that needs to be checked for large UOWs and big messages....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Sun Oct 24, 2010 2:02 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| I haven't found the reference to batchsize = 1. Hypothetically, if my UOW consisted of 30 100MB messages (between start trans and commit) would batchsize = 1 be the recommended setting? |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Oct 25, 2010 1:05 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i would use it, others mileage may vary.
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
