ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » REMOTE storage class

Post new topic  Reply to topic Goto page 1, 2  Next
 REMOTE storage class « View previous topic :: View next topic » 
Author Message
MonkeyDoo
PostPosted: Thu Sep 05, 2013 9:59 am    Post subject: REMOTE storage class Reply with quote

Novice

Joined: 05 Aug 2013
Posts: 17

Pardon my ignorance, but I see there are some default storage class' already defined. I know I should create some more page sets and storage class' for applications.

Here is my question, is it common to use the REMOTE storage class for XMITQs?

Is REMOTE a default object or did somebody make that?
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Sep 05, 2013 10:12 am    Post subject: Re: REMOTE storage class Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

MonkeyDoo wrote:
Here is my question, is it common to use the REMOTE storage class for XMITQs?

Is REMOTE a default object or did somebody make that?


As indicated here the REMOTE storage class is one of the 4 required classes with specific uses:

Quote:
REMOTE (required)
This storage class is used primarily for transmission queues, that is, system related queues with short-lived performance-critical messages

_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Sep 05, 2013 10:19 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.

Enroll in ibm's WM300 ccouse: WMQ for z/OS System Administration.
_________________
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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 05, 2013 10:23 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
Enroll in ibm's WM300 ccouse: WMQ for z/OS System Administration.


Oh no! He's been possessed by a spirit!!
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
MonkeyDoo
PostPosted: Thu Sep 05, 2013 10:47 am    Post subject: Reply with quote

Novice

Joined: 05 Aug 2013
Posts: 17

Thx, so somebody created a WMB broker and I see the SYSTEM.BROKER.* queues are using a storage class of SYSTEM and DEFAULT. Since the IC says don't put application msgs on page set 0 (which this is when using SYSTEM), I take it I need to alter this to something sensible. These don't look long lived but I don't know that I'm seeing the PROD state as it will/should be...

I know not all these queue belong to WMB. Some are for the PUB/SUB engine.

Any thoughts on if a new storage class should be created for this purpose?

Classes? I thought Wild Ace Guessing was the defacto development method around the world...
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Sep 05, 2013 11:34 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

MonkeyDoo wrote:
I take it I need to alter this to something sensible. These don't look long lived but I don't know that I'm seeing the PROD state as it will/should be...


Gosh yes. Nothing should be using DEFAULT and only system should be using SYSTEM. Applications should be given their own storage class(es).

MonkeyDoo wrote:
Any thoughts on if a new storage class should be created for this purpose?


At the risk of getting things thrown at me, I don't think you can have too many storage classes unless you go mad & give each individual application a class!

Do not allow anything which is not the system to use page set 0. If that fills up the darkness will rise and enfold you.

MonkeyDoo wrote:
Classes? I thought Wild Ace Guessing was the defacto development method around the world...


Informed experimentation is the preferred method. In this one specific instance it's a good idea as WMQ on z/OS works differently to WMQ on anything else, and of course z/OS is a unqiue animal.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Sep 05, 2013 12:47 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.

WMQ for z/OS comes with some pre-defined storage classes. This is all documented nicely in the z/OS-related WMQ documentation.

Storage-classes allow WMQ sysprogs to 'tune' how WMQ for z/OS uses message-holding virtual storage buffers in the qmgr address space, and where message-holding datasets (pagesets) shall reside on disk.

Don't go hog-wild with new storage-classes. As with any tuning effort, there needs to be a demonstrable need for tuning, a plan for tuning what needs tuning, and a method of measuring performance improvements - if any.

If you are only putting a few dozen or hundred messages per second or minute, little tuning should be needed. If your message sizes run from very small to very large, some tuning might help.

Some initial guidelines to entertain you: Create a storage-class for short-lived messages, and another for long-lived messages. Why? Few short-lived messages should need to be pushed to disk (as short-lived means consumed PDQ). Create a storage-class for small messages, and another for large messages.

It depends.
_________________
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
View user's profile Send private message
MonkeyDoo
PostPosted: Fri Sep 06, 2013 6:40 am    Post subject: Reply with quote

Novice

Joined: 05 Aug 2013
Posts: 17

Thx very much.

The picture is getting clearer with your thoughts and my reading (and yes, I will look for virtual ed).

So in addition to the required four STGCLASS', I will (most likely) want four more:

  • Short lived mice
  • Long lived mice
  • Short lived elephants
  • Long lived elephants

We all know you will get significant problems like a mosh pit went mixing elephants and mice...

And of course a few more STGCLASS' for the 'special' applications...

I don't quite get the point of lots of STGCLASS' when you can only have 100 page sets...
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Sep 06, 2013 6:50 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

MonkeyDoo wrote:
So in addition to the required four STGCLASS', I will (most likely) want four more:

  • Short lived mice
  • Long lived mice
  • Short lived elephants
  • Long lived elephants



And rules to ensure all the mice and elephants end up here and not in the DEFAULT.

MonkeyDoo wrote:
And of course a few more STGCLASS' for the 'special' applications...

I don't quite get the point of lots of STGCLASS' when you can only have 100 page sets...


If you need more than 100 page sets your page sets are too small and/or you're holding too many messages on the queues.

Purely as an example, consider if you have some long lived gold plated elephants which don't want to be impacted if you have a problem either with elephant storage or the processing of elephants. Or elephants which are scared of mice and need to be stored separately due to security or contractual requirements. Each of these may profit from their own storage class.

As well as all the "special" application you alude to.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
MonkeyDoo
PostPosted: Fri Sep 06, 2013 7:10 am    Post subject: Reply with quote

Novice

Joined: 05 Aug 2013
Posts: 17

Vitor,

Where the wheels come off is, how does it help if I have 5000 STGCLASS' that all use the same page set?

Why wouldn't I want 1:1? or
Why is 5000:1 helpful?

I might think it would be handy (maybe not in a technical way) to isolate every application (group) to their own page set/STGCLASS.

I don't perceive the why.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Sep 06, 2013 7:14 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.

MonkeyDoo wrote:
I don't quite get the point of lots of STGCLASS' when you can only have 100 page sets...

A single pageset is a disk dataset that can be sized from small to very large, depending on the number and size of messages that need to be written to it. If you have 100meg messages, the pageset dataset must be very large.

Pagesets allow the sysprog to separate messages based on categories, such as size, number, application-type, whatever, to different pagesets. There is no equivalent facility for midrange WMQ.

Pageset 00 is used by WMQ for storing object definitions, leaving 99 other pagesets for your use.

Again, don't go crazy with STGCLASS and pagesets. Just because you can have 99 pagesets doesn't mean that you should.

There needs to be a significant reason to separate low-volume payroll time-card messages from low-volume inventory-request messages. The return-on-investment will likely be very low. In a banking application, however, you might get some benefit by separating high-volume ATM transaction messages from some other very-large, low-volume messages.

Your mice vs. elephants analogy is quite good, and cute. You don't want to store both in the same container. Retrieving a 4oz. mouse might require you to first retrieve one or more 4 ton elephants.
_________________
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
View user's profile Send private message
Vitor
PostPosted: Fri Sep 06, 2013 7:20 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

MonkeyDoo wrote:
Where the wheels come off is, how does it help if I have 5000 STGCLASS' that all use the same page set?


If all the storage classes are sharing page sets then it doesn't help. Why would you share page sets if that's the requirement you're trying to meet? Why would you share page sets at all?

MonkeyDoo wrote:
I might think it would be handy (maybe not in a technical way) to isolate every application (group) to their own page set/STGCLASS.


I don't - please see my comment above:

Vitor wrote:
unless you go mad & give each individual application a class


It's not even "handy" from a non-technical standpoint. Think of the administrative burden you're creating, and the diagnostic mess you'll have when someone complains "MQ lost my message".

MonkeyDoo wrote:
I don't perceive the why.


Nor do I.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Sep 06, 2013 7:24 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
Pagesets allow the sysprog to separate messages based on categories, such as size, number, application-type, whatever, to different pagesets. There is no equivalent facility for midrange WMQ.




Remember that not all z/OS disk is created equal, much more so than for distributed. Your sys prog may have a specific area in which he keeps mice.

bruce2359 wrote:
Pageset 00 is used by WMQ for storing object definitions, leaving 99 other pagesets for your use.




As I said above, don't allow page set 0 to fill. Ever.

bruce2359 wrote:
Again, don't go crazy with STGCLASS and pagesets. Just because you can have 99 pagesets doesn't mean that you should.




bruce2359 wrote:
There needs to be a significant reason to separate low-volume payroll time-card messages from low-volume inventory-request messages.


Nicely put. There's typically very little reason to separate mice by colour.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Sep 06, 2013 7:33 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.

Vitor wrote:
There's typically very little reason to separate mice by colour.

Likewise, there is seldom a reason to separate elephants by ear-shape.
_________________
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
View user's profile Send private message
Vitor
PostPosted: Fri Sep 06, 2013 7:49 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
Vitor wrote:
There's typically very little reason to separate mice by colour.

Likewise, there is seldom a reason to separate elephants by ear-shape.


I don't know - you put African & Indian elephants in together and you're just asking for trouble.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » REMOTE storage class
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.