| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| OS/390 storage class for cluster queues |
« View previous topic :: View next topic » |
| Author |
Message
|
| JT |
 Posted: Wed May 05, 2004 12:47 pm Post subject: OS/390 storage class for cluster queues |
 |
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Have limited knowledge of MQSeries running on the mainframe so please excuse the elementary nature of this clustering question.
Running v5.3.4 on all platforms.
Three queue managers are joined in a cluster, two queue managers, full repositories, are residing on a Solaris platform, the remaining queue manger, partial repository, resides on the OS/390 platform. A local queue definition is created on one of the Solaris queue managers and defined to participate in the cluster. A subsequent cluster definition is created on the OS/390 (as well as the other Solaris queue manager).
It appears the OS/390 cluster definition does not have a storage class assigned, thus messages written to the queue definition result in a reason code of 2071 (Storage not available). I'm sure we're missing something simple.
Can anyone assist? |
|
| Back to top |
|
 |
| offshore |
| Posted: Fri May 07, 2004 3:37 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
JT,
A 2071 usually is because a the application program is running out of control & using up all the main storage available to MQ on the OS/390 system. Have the Sys Progs check to make sure the MQ didn't go short on storage.
The cluster queue(s) & every other queue have a storageclass associated with them. If a specific stgclass wasn't assigned to the queue at creation it will be assigned to the DEFAULT stgclass. You may want to check that the page_datasets have large enough buffers to support all the queues assigned to that page_dataset/stgclass.
You can do this by issuing MQSC Commands:
1.]Find out what queue(s) are assigned to a specific stgclass
DIS QUEUE(queue_name or "*" for all queues) STGCLASS
2.]Once you find out what stgclass the queue is assigned to, check the page_dataset/bufferpool information
DIS USAGE PSID(*)
The Restart Extents & Expand Counts are the fields of concern on this panel.
If the restart extends are high, then you will want to either:
1.] Make that particular VSAM PSID larger.
2.] Create different STGCLASSes (16 is the max) and PSID's (99 is the max) and distribute the queues among the newly created STGCLASSes.
If the Expand Count is high, then you need to increase the bufferpool sizes for that particular page_dataset.
To see all STGCLASS and what PSID they're assigned to the, issue the DIS STGCLASS(*) PSID(*). |
|
| Back to top |
|
|
| JT |
| Posted: Mon May 10, 2004 6:52 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Offshore wrote: |
| If a specific stgclass wasn't assigned to the queue at creation it will be assigned to the DEFAULT stgclass. |
The OS/390 "cluster" definition of the local queue that I created on the UNIX queue manager doesn't have a storage class assigned to it. The stgclass parameter is blank. When I created the local queue definition on the distributive queue manager there was no option available to specify a storage class, since it's an OS/390 only parameter.
It appears that the "DEFAULT" stgclass is not being assigned automatically for the mainframe cluster queue defintion. Is there an option/parameter that my OS/390 MQ team is missing? Do they have to expand the default settings for local queues to also include cluster queues?
Also, it looks like we're running v5.3.0 on the OS/390, not v5.3.4. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Mon May 10, 2004 7:22 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
I am not an Os/390 expert either, but here are few pointers that i found from your Post.
---You did not make it clear what queue are you referring to. Whether you have a "local" instance of a cluster queue defined and hosted on os/390 or if you were talking about the cluster queue that is published by your solaris qm. If it is the latter, then you dont need to worry about the storage. Since this is just a routing definition to the QM that is actually hosting the queue. In your case it would be the solaris qm.
---If you are "manually" and "explicityly" creating a local instance of the cluster queue and hence make the Os/390 qm host the cluster queue, then it is nothing more than defining a local queue. Which would mean you have to assign a storage class to it, manually when you define the queue. Of course this one from the manuals.
"If you define a queue without specifying a storage class, WebSphere MQ uses a default storage class. "
Hope this helps.
Also try and find out where are you getting this 2071 from. What api call, under what circumstances. Any errors in the error logs. Is it repeatable.
Cheers
Kumar |
|
| Back to top |
|
|
| JT |
| Posted: Tue May 11, 2004 9:22 am Post subject: OS/390 storage class for cluster queues - Solved |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Problem has been resolved with the installation of PTF UQ73491. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
