Shared queue via QSG in The Coupling Facility

Discussion:

Cameron Conacher

2013-12-12 19:41:15 UTC

Hello list
We are looking to introduce shared queues via the Coupling Facility to support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but as near as I can tell we depend on them to respect our wishes, and there is no way for us to keep them from setting persistence or very long expiry times.
Is this correct? Are Consumers always simply on their honor not to send persistent messages?

Thanks

Sent from my iPhone
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Dave Corbett

2013-12-12 20:21:35 UTC

Permalink

Cameron,

You can define a list structure that does not allow persistent messages,
and then ensure that those queues are tied to that structure. If an app
attempts to put a persistent message there, they will receive a Peristence
Not Allowed" reason code.

We have separate structures for the two types of messages in the CF -
persistent and not persistent.

Thanks,
David Corbett
Work: 612-973-7086
Pager: 612-280-6307
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0

From: Cameron Conacher <conacher-8a+***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 12/12/2013 02:07 PM
Subject: Shared queue via QSG in The Coupling Facility
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

Hello list
We are looking to introduce shared queues via the Coupling Facility to
support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages
with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but
as near as I can tell we depend on them to respect our wishes, and there
is no way for us to keep them from setting persistence or very long expiry
times.
Is this correct? Are Consumers always simply on their honor not to send
persistent messages?

Thanks

Sent from my iPhone
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

---------------------------------------------------------------------

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Paul S Dennis

2013-12-13 09:03:27 UTC

Permalink

Hi Cameron,

Can I ask why you make this statement:
When using a QSG you don't want to see persistent messages or messages
with long expiry times since the queue data is stored in the CF.

When using shared queues, it is perfectly acceptable to use persistent
messages. These are logged on the queue manager where the put/get is
occurring, so can be recovered from the MQ logs in the event of a
structure failure or DR situation. Is this just a stipulation that you
have decided to place on the use of MQ Shared Queues? As has been stated
by another response, you can stop persistent messages from going onto the
shared queues by setting the structure that the queues are in to be
RECOVER(NO).

Thanks
Paul

Paul Dennis
WebSphere MQ for z/OS Development

From: Cameron Conacher <conacher-8a+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 12/12/2013 20:06
Subject: Shared queue via QSG in The Coupling Facility
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello list
We are looking to introduce shared queues via the Coupling Facility to
support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages
with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but
as near as I can tell we depend on them to respect our wishes, and there
is no way for us to keep them from setting persistence or very long expiry
times.
Is this correct? Are Consumers always simply on their honor not to send
persistent messages?

Thanks

Sent from my iPhone
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Bob Juch

2013-12-13 11:30:12 UTC

Permalink

Cameron,

I recently worked on a project to convert the system that runs Vision+
from a monoplex to a Sysplex. We didn't worry at all about persistent
messages. If your system isn't processing them quickly enough so there
isn't a build-up you have a bigger problem than just the persistence.

So you're saying that the messages your customers are sending can
easily be recreated in case of a system failure that causes
unprocessed messages to be discarded? Even so if you're going to tell
your customers that they have to change their systems because you're
changing yours that's going to cause your project fits because your
schedule will have to accommodate theirs. You'll also cause bad will
with them.

Bob Juch
Juch Services LLC

Post by Cameron Conacher
Hello list
We are looking to introduce shared queues via the Coupling Facility to support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but as near as I can tell we depend on them to respect our wishes, and there is no way for us to keep them from setting persistence or very long expiry times.
Is this correct? Are Consumers always simply on their honor not to send persistent messages?
Thanks
Sent from my iPhone
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Cameron Conacher

2013-12-13 15:51:23 UTC

Permalink

Hello Bob
In our environment almost all of the requests are inquiries satisfying the needs of the web front end.
I understand that it is not very polite of me to assume that a data request is not that important, the reality is that these requests can be recreated.
At a higher level I was looking to protect the Coupling Facility. However it appears that even though we make a Gentleman's agreement amongst ourselves that these messages ought not be sent as persistent, there is nothing we can do on the service provider side to prevent any Consumer from sending persistent messages.
Bob, maybe I am over thinking this and the coupling facility does not require the kid gloves approach I am taking?

Thanks

Sent from my iPhone

Post by Dave Corbett
Cameron,
I recently worked on a project to convert the system that runs Vision+
from a monoplex to a Sysplex. We didn't worry at all about persistent
messages. If your system isn't processing them quickly enough so there
isn't a build-up you have a bigger problem than just the persistence.
So you're saying that the messages your customers are sending can
easily be recreated in case of a system failure that causes
unprocessed messages to be discarded? Even so if you're going to tell
your customers that they have to change their systems because you're
changing yours that's going to cause your project fits because your
schedule will have to accommodate theirs. You'll also cause bad will
with them.
Bob Juch
Juch Services LLC

in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Cameron Conacher

2013-12-13 18:53:15 UTC

Permalink

Hello Paul
My understanding (maybe incorrect) is that when we use a QSG the queue message data is actually held in the Coupling Facility. If bad things happen and the queue were to accumulate too many messages then the CF would be at risk, and then the entire SYSPLEX could be in a bad situation.
Perhaps I am overstating the risks?
I don't want to be the reason that a Coupling Facility fails

Thanks

Sent from my iPhone

Post by Paul S Dennis
Hi Cameron,
When using a QSG you don't want to see persistent messages or messages with long expiry times since the queue data is stored in the CF.
When using shared queues, it is perfectly acceptable to use persistent messages. These are logged on the queue manager where the put/get is occurring, so can be recovered from the MQ logs in the event of a structure failure or DR situation. Is this just a stipulation that you have decided to place on the use of MQ Shared Queues? As has been stated by another response, you can stop persistent messages from going onto the shared queues by setting the structure that the queues are in to be RECOVER(NO).
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
Date: 12/12/2013 20:06
Subject: Shared queue via QSG in The Coupling Facility
Hello list
We are looking to introduce shared queues via the Coupling Facility to support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but as near as I can tell we depend on them to respect our wishes, and there is no way for us to keep them from setting persistence or very long expiry times.
Is this correct? Are Consumers always simply on their honor not to send persistent messages?
Thanks
Sent from my iPhone
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Dave Corbett

2013-12-13 19:33:54 UTC

Permalink

Cameron,

We make extensive use of Shared queues - which by themselves give a
measure of persistence because if one QMGR in the QSG goes down, the
messages are still in the CF. Persistent messages in the CF just protect
you from list structure failures, or the CF itself failing (a rare thing -
but possible).

To mitigate the risk, we have created several (meaning more than 3), list
structures, and if we deem an application to have a persistent message
requirement, but may also have enough volume that during some time where
the GETting application was unavailable (for any reason), we would put
their message into their own List Structure, and if it filled up it would
only affect them. At least, I believe the failure would be restricted at
that level - someone else can correct me if I am wrong here. Also,
MAXDEPTH comes into play at design time as well.

Thanks,
David Corbett
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0

From: Cameron Conacher <conacher-8a+***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org,
Date: 12/13/2013 12:54 PM
Subject: Re: Shared queue via QSG in The Coupling Facility
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>

Hello Paul
My understanding (maybe incorrect) is that when we use a QSG the queue
message data is actually held in the Coupling Facility. If bad things
happen and the queue were to accumulate too many messages then the CF
would be at risk, and then the entire SYSPLEX could be in a bad situation.
Perhaps I am overstating the risks?
I don't want to be the reason that a Coupling Facility fails

Thanks

Sent from my iPhone

On 2013-12-13, at 4:03 AM, Paul S Dennis <DENNISPS-E4/***@public.gmane.org> wrote:

Hi Cameron,

Can I ask why you make this statement:
When using a QSG you don't want to see persistent messages or messages
with long expiry times since the queue data is stored in the CF.

When using shared queues, it is perfectly acceptable to use persistent
messages. These are logged on the queue manager where the put/get is
occurring, so can be recovered from the MQ logs in the event of a
structure failure or DR situation. Is this just a stipulation that you
have decided to place on the use of MQ Shared Queues? As has been stated
by another response, you can stop persistent messages from going onto the
shared queues by setting the structure that the queues are in to be
RECOVER(NO).

Thanks
Paul

Paul Dennis
WebSphere MQ for z/OS Development

From: Cameron Conacher <conacher-8a+***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 12/12/2013 20:06
Subject: Shared queue via QSG in The Coupling Facility
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello list
We are looking to introduce shared queues via the Coupling Facility to
support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages
with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but
as near as I can tell we depend on them to respect our wishes, and there
is no way for us to keep them from setting persistence or very long expiry
times.
Is this correct? Are Consumers always simply on their honor not to send
persistent messages?

Thanks

Sent from my iPhone
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

---------------------------------------------------------------------

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Cameron Conacher

2013-12-13 22:53:11 UTC

Permalink

Thank you David

Sent from my iPhone

Post by Dave Corbett
Cameron,
We make extensive use of Shared queues - which by themselves give a measure of persistence because if one QMGR in the QSG goes down, the messages are still in the CF. Persistent messages in the CF just protect you from list structure failures, or the CF itself failing (a rare thing - but possible).
To mitigate the risk, we have created several (meaning more than 3), list structures, and if we deem an application to have a persistent message requirement, but may also have enough volume that during some time where the GETting application was unavailable (for any reason), we would put their message into their own List Structure, and if it filled up it would only affect them. At least, I believe the failure would be restricted at that level - someone else can correct me if I am wrong here. Also, MAXDEPTH comes into play at design time as well.
Thanks,
David Corbett
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0
Date: 12/13/2013 12:54 PM
Subject: Re: Shared queue via QSG in The Coupling Facility
Hello Paul
My understanding (maybe incorrect) is that when we use a QSG the queue message data is actually held in the Coupling Facility. If bad things happen and the queue were to accumulate too many messages then the CF would be at risk, and then the entire SYSPLEX could be in a bad situation.
Perhaps I am overstating the risks?
I don't want to be the reason that a Coupling Facility fails
Thanks
Sent from my iPhone
Hi Cameron,
When using a QSG you don't want to see persistent messages or messages with long expiry times since the queue data is stored in the CF.
When using shared queues, it is perfectly acceptable to use persistent messages. These are logged on the queue manager where the put/get is occurring, so can be recovered from the MQ logs in the event of a structure failure or DR situation. Is this just a stipulation that you have decided to place on the use of MQ Shared Queues? As has been stated by another response, you can stop persistent messages from going onto the shared queues by setting the structure that the queues are in to be RECOVER(NO).
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
Date: 12/12/2013 20:06
Subject: Shared queue via QSG in The Coupling Facility
Hello list
We are looking to introduce shared queues via the Coupling Facility to support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages with long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but as near as I can tell we depend on them to respect our wishes, and there is no way for us to keep them from setting persistence or very long expiry times.
Is this correct? Are Consumers always simply on their honor not to send persistent messages?
Thanks
Sent from my iPhone
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.
---------------------------------------------------------------------
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Bob Juch

2013-12-13 23:21:49 UTC

Permalink

Cameron,

You are correct that when you use a QSG the messages are saved in the
CF (unless they are too long). Do you realize that's true whether or
not the messages are persistent?

You won't crash your CF if your queues become too long, just affect
all shared queues. To keep that from happening you need to ensure
you're consuming messages from the queues. You should have enough
consuming tasks that they keep the queue low.

Bob Juch
Juch Services LLC

Post by Cameron Conacher
Hello Paul
My understanding (maybe incorrect) is that when we use a QSG the queue
message data is actually held in the Coupling Facility. If bad things happen
and the queue were to accumulate too many messages then the CF would be at
risk, and then the entire SYSPLEX could be in a bad situation.
Perhaps I am overstating the risks?
I don't want to be the reason that a Coupling Facility fails
Thanks
Sent from my iPhone
Hi Cameron,
When using a QSG you don't want to see persistent messages or messages with
long expiry times since the queue data is stored in the CF.
When using shared queues, it is perfectly acceptable to use persistent
messages. These are logged on the queue manager where the put/get is
occurring, so can be recovered from the MQ logs in the event of a structure
failure or DR situation. Is this just a stipulation that you have decided to
place on the use of MQ Shared Queues? As has been stated by another
response, you can stop persistent messages from going onto the shared queues
by setting the structure that the queues are in to be RECOVER(NO).
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
Date: 12/12/2013 20:06
Subject: Shared queue via QSG in The Coupling Facility
________________________________
Hello list
We are looking to introduce shared queues via the Coupling Facility to
support our Vision+ platform.
When using a QSG you don't want to see persistent messages or messages with
long expiry times since the queue data is stored in the CF.
We can tell our service Consumers to never send persistent messages, but as
near as I can tell we depend on them to respect our wishes, and there is no
way for us to keep them from setting persistence or very long expiry times.
Is this correct? Are Consumers always simply on their honor not to send
persistent messages?
Thanks
Sent from my iPhone
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Cameron Conacher

2013-12-14 16:33:25 UTC

Permalink

Thanks Bob
What would happen if the CICS regions were unavailable to eat the messages?
I guess the queues just fill to the predefined depths and life goes on?

Yes I understood that all messages would be saved in the CF unless message size was greater than 63K in which case they are stored in DB2

Sent from my iPhone

Post by Dave Corbett
Cameron,
You are correct that when you use a QSG the messages are saved in the
CF (unless they are too long). Do you realize that's true whether or
not the messages are persistent?
You won't crash your CF if your queues become too long, just affect
all shared queues. To keep that from happening you need to ensure
you're consuming messages from the queues. You should have enough
consuming tasks that they keep the queue low.
Bob Juch
Juch Services LLC

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Bruce Lerner

2013-12-14 21:40:22 UTC

Permalink

A full-queue in a QSG does not put the CF, or all or other structures at
risk. Persistent messages do not put the CF or other structures at risk.
CFs are used by very large organizations in their mission-critical
applications. CFs and their structures are highly reliable and resilient.

If the messages (and other data in the CF) is mission-critical, then a 2nd
CF, or the CF control code (CFCC) in an LPAR, can be deployed as hot backup.
Who is leading you to believe that CFs and their structures are fragile?
Non-z/OS sysadmins?

CFs are not virtual boxes. Developers and sysprogs specify the size/shape
of CF structures, as they would with non-QSG queues.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Bob Juch

2013-12-15 03:45:49 UTC

Permalink

While a full queue will not affect the rest of a CF, it could cause
all of the pool defined for it and other queues to become full thus
causing problems to the other queues as well as itself. As I said in a
previous message the persistence of messages has no effect on that
however.

Bob Juch
Juch Services LLC

Post by Bruce Lerner
A full-queue in a QSG does not put the CF, or all or other structures at
risk. Persistent messages do not put the CF or other structures at risk.
CFs are used by very large organizations in their mission-critical
applications. CFs and their structures are highly reliable and resilient.
If the messages (and other data in the CF) is mission-critical, then a 2nd
CF, or the CF control code (CFCC) in an LPAR, can be deployed as hot backup.
Who is leading you to believe that CFs and their structures are fragile?
Non-z/OS sysadmins?
CFs are not virtual boxes. Developers and sysprogs specify the size/shape
of CF structures, as they would with non-QSG queues.
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Bruce Lerner

2013-12-15 15:29:20 UTC

Permalink

Bob Juch wrote: "While a full queue will not affect the rest of a CF, it
could cause all of the pool defined for it and other queues to become full thus
causing problems to the other queues as well as itself."

Yes, I agree. The same can be said of a single MVS WMQ pageset (or
UNIX/Windows filesystem) that holds the messages for multiple queues.

The CF is not virtual, meaning CF structures can't expand beyond the CFs
physical central storage. Thus, like a pageset (or filesystem), max msg
length and max depth queue attributes must be set appropriately to constrain
apps from filling that CF structure.

This is basic math, not rocket-science. WMQ and other uses of CF
structures, like DB2, must be calculated, and CF structures defined accordingly.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Cameron Conacher

2013-12-16 14:19:16 UTC

Permalink

Thanks Bruce

Sent from my iPhone

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Cameron Conacher

2013-12-16 14:19:48 UTC

Permalink

Thank you again Bob
Merry Christmas

Sent from my iPhone

Post by Bob Juch
While a full queue will not affect the rest of a CF, it could cause
all of the pool defined for it and other queues to become full thus
causing problems to the other queues as well as itself. As I said in a
previous message the persistence of messages has no effect on that
however.
Bob Juch
Juch Services LLC

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Cameron Conacher

2013-12-16 14:20:20 UTC

Permalink

Thanks again Bruce
Merry Christmas

Sent from my iPhone

Post by Bruce Lerner
Bob Juch wrote: "While a full queue will not affect the rest of a CF, it
could cause all of the pool defined for it and other queues to become full thus
causing problems to the other queues as well as itself."
Yes, I agree. The same can be said of a single MVS WMQ pageset (or
UNIX/Windows filesystem) that holds the messages for multiple queues.
The CF is not virtual, meaning CF structures can't expand beyond the CFs
physical central storage. Thus, like a pageset (or filesystem), max msg
length and max depth queue attributes must be set appropriately to constrain
apps from filling that CF structure.
This is basic math, not rocket-science. WMQ and other uses of CF
structures, like DB2, must be calculated, and CF structures defined accordingly.
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES