| Author |
Message
|
| KIT_INC |
 Posted: Thu Aug 08, 2013 5:34 am Post subject: What happen to my application when actiive log full |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am running MQ V7 on ZOS. The info center says
"When the active log becomes full, the queue manager halts processing until an off-load has been completed. " It provides info on system action and system programmer action. But there nothing on application action.
I was wondering what will happen to the MQ application (CICS IMS or Batch) when MQ is waiting. Will they get an error return code and will they also be waiting. In the MQ ZOS message and code manual, there are some return codes on Storage medium (e.g. MQRC_STORAGE_MEDIUM_FULL). But the explanation says Q full or structure full. There is nothing on active log full. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Aug 08, 2013 6:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The application will also wait. You may find an application doing a get with wait will return with a 2033 even if messages are available, but I may be wrong on that.
Think of an application that's opening a file that's been migrated to level 2 & needs to be reloaded. The application just hangs waiting for the mount; same principle.
In due course the application will of course fail with a 522 or similar.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elkinsc |
| Posted: Thu Aug 08, 2013 6:35 am Post subject: Active log full |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
When an active log fills, WMQ will move to the next one in the active log string and write the full log to the archive log. This is unless archiving has been turned off, which should NOT be done in a production environment. If archiving is turned off and there is an active UOW on the next active log in the string the queue manager will present:
CSQJ111A: OUT OF SPACE IN ACTIVE LOG DATA SETS
Effectively all action in the queue manager that has to do with persistent messaging will stop until the situation is resolved.
The available actions to resolve the problem are documented in the InfoCenter. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 08, 2013 6:40 am Post subject: Re: Active log full |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| elkinsc wrote: |
| Effectively all action in the queue manager that has to do with persistent messaging will stop until the situation is resolved. |
What this means for your application is that, amazingly enough, you will start getting non-zero completion and reason codes from MQ API calls.
Just like happens with every other situation where MQ has an issue of any kind - it tells the applications using the same mechanism it uses to tell the application that everything worked. |
|
| Back to top |
|
|
| elkinsc |
| Posted: Thu Aug 08, 2013 7:00 am Post subject: on z/OS |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 08, 2013 7:03 am Post subject: Re: on z/OS |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm always happy to be completely wrong.
 |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Thu Aug 08, 2013 7:04 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Quote: |
| What this means for your application is that, amazingly enough, you will start getting non-zero completion and reason codes from MQ API calls. |
Actually application getting a RC and take action is what I like to see . If many applications (or transactions) just sit there and wait, it can prevent new CICS or IMS transactions to start .These new transactions may not use MQ. I can see that a MQGET wait call will get 2033. But what about applications doing MQPUT. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 08, 2013 7:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
If no log space is available for any event that requires logging, the app will receive the fail RC/CC - MQSET, MQPUT, MQGET, MQCMIT ...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 08, 2013 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| But what about applications doing MQPUT. |
Yes, this can prevent CICS and IMS transaction starts. This is the same behaviour as you'll experience for any z/OS WAIT state.
This is also, as the previous poster correctly said, why you don't turn archiving off in Prod.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 08, 2013 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| If no log space is available for any event that requires logging, the app will receive the fail RC/CC - MQSET, MQPUT, MQGET, MQCMIT ... |
No it won't. On z/OS the app waits for the log archive to complete. On distributed, the call fails as you indicate.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Thu Aug 08, 2013 7:36 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks for all the responses. It's nice to know this important difference between distributed and ZOS. I was wondering why ZOS does not do the same as distributed. Give the application an RC saying log full. So that it can quit. Yes, I know that we should "NEVER TURN ARCHIVE OFF" in MVS production. But there are unplanned situations where it can cause the archive to take too long happen (waiting for tape mount) or not happen (no more space ). I know that all these are result of bad planning or configuration. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 08, 2013 8:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Doh!
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 08, 2013 8:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| I know that all these are result of bad planning or configuration. |
Or bad luck.
This is why all sites have some form of incident reporting & root cause analysis procedure. Bad stuff happens.
FWIW this is z/OS trying to be helpful. If there's a subsystem WAIT, it pages all the applications out in the expectation the WAIT will clear itself (i.e. a tape mount takes a while but does complete in the end) and the applications can continue not knowing something bad ever happened. This is distinct from distributed where the apps need some kind of error detection / restart strategy themselves.
I'm not saying one way is better or worse than the other, just highlighting the difference for the enlightenment of future readers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elkinsc |
| Posted: Thu Aug 08, 2013 8:38 am Post subject: |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
thank you!
Enlightenment leads to nirvana?
Have a lovely day |
|
| Back to top |
|
|
|
|
