Discussion:
Window Size for Linux Servers
Dawson, John A
2014-03-31 22:13:49 UTC
Permalink
Fellow MQ'ers,

Has anyone experienced an issue with the TCP/IP window size for transmitting data to/from the Linux platform with WMQ version 7?

How many has had to actually use the below values in a qm.ini file to control the TCP/IP window size?


TCP:
SndBuffSize=
RcvBuffSize=
RcvSndBuffSize=
RcvRcvBuffSize=
ClntSndBuffSize=
ClntRcvBuffSize=
SvrSndBuffSize=
SvrRcvBuffSize=

Thanks for your time and responses.


John Dawson

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
Anderson, Charles W.
2014-04-01 03:40:06 UTC
Permalink
John,

We recently went through this when trying to open a 256k TCP Window from z/OS (MQ7.1) to OEL5 server (MQ7.0.1.9).
With no attributes in the TCP stanza we were getting a 64k window on Linux, which is the default.
With specific settings in the TCP stanza, which would have MQ setting the TCP window, the settings were ignored, still 64k.
We opened a PMR with IBM for assistance with this and got a "Not My Problem". That is, it isn't an MQ issue talk to your OS vendor.
No help with why the settings in the TCP stanza didn't work with Linux, they read the traces and said MQ is working. I believe they said they could see MQ setting the Window size in the trace.
We opened a ticket with Oracle and they were not as helpful as IBM, not a clue. Never heard of MQSeries or WMQ.
We set the TCP attributes to zero, per the InfoCenter and MQ let the OS control the TCP window and we were able to get a 256k window on Linux.
I've not tried it on the client side or Linux to Linux.
We did see significant increase in throughput (Sender to Receiver) during heavy volumes on the specific channel we were working on, which resolved our issue.
Also in the course of testing we tried OEL6/MQv7.0 with the same results. We didn't try MQv7.5 as we were going with IBM, not an MQ issue.
We're going with the settings below on new Linux builds for MQ.


TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0



Charles

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dawson, John A
Sent: Monday, March 31, 2014 6:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Window Size for Linux Servers

Fellow MQ'ers,

Has anyone experienced an issue with the TCP/IP window size for transmitting data to/from the Linux platform with WMQ version 7?

How many has had to actually use the below values in a qm.ini file to control the TCP/IP window size?


TCP:
SndBuffSize=
RcvBuffSize=
RcvSndBuffSize=
RcvRcvBuffSize=
ClntSndBuffSize=
ClntRcvBuffSize=
SvrSndBuffSize=
SvrRcvBuffSize=

Thanks for your time and responses.


John Dawson

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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 Clarke
2014-04-01 08:41:25 UTC
Permalink
If I remember correctly MQ uses setsockopt() with SO_SNDBUF and SO_RCVBUF to set the buffer sizes. I believe that these calls are advisory and the OS can ignore the settings. Later versions of MQ trace out the setting of these values, it then queries the current settings and trace those out too so you may be able to tell whether TCP at least accepted your settings. Of there’s still no guarantee it will actually use them. However, if MQ is issuing the setting with the correct value there’s nothing further it can really do and you should talk to the OS TCP boys to find out why any setting is ignored.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Anderson, Charles W.
Sent: Tuesday, April 01, 2014 4:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Window Size for Linux Servers

John,



We recently went through this when trying to open a 256k TCP Window from z/OS (MQ7.1) to OEL5 server (MQ7.0.1.9).

With no attributes in the TCP stanza we were getting a 64k window on Linux, which is the default.

With specific settings in the TCP stanza, which would have MQ setting the TCP window, the settings were ignored, still 64k.

We opened a PMR with IBM for assistance with this and got a “Not My Problem”. That is, it isn’t an MQ issue talk to your OS vendor.

No help with why the settings in the TCP stanza didn’t work with Linux, they read the traces and said MQ is working. I believe they said they could see MQ setting the Window size in the trace.

We opened a ticket with Oracle and they were not as helpful as IBM, not a clue. Never heard of MQSeries or WMQ.

We set the TCP attributes to zero, per the InfoCenter and MQ let the OS control the TCP window and we were able to get a 256k window on Linux.

I’ve not tried it on the client side or Linux to Linux.

We did see significant increase in throughput (Sender to Receiver) during heavy volumes on the specific channel we were working on, which resolved our issue.

Also in the course of testing we tried OEL6/MQv7.0 with the same results. We didn’t try MQv7.5 as we were going with IBM, not an MQ issue.

We’re going with the settings below on new Linux builds for MQ.





TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0







Charles



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dawson, John A
Sent: Monday, March 31, 2014 6:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Window Size for Linux Servers



Fellow MQ’ers,



Has anyone experienced an issue with the TCP/IP window size for transmitting data to/from the Linux platform with WMQ version 7?



How many has had to actually use the below values in a qm.ini file to control the TCP/IP window size?





TCP:
SndBuffSize=
RcvBuffSize=
RcvSndBuffSize=
RcvRcvBuffSize=
ClntSndBuffSize=
ClntRcvBuffSize=
SvrSndBuffSize=
SvrRcvBuffSize=



Thanks for your time and responses.





John Dawson




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

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
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
Schanz, Arthur
2014-04-01 11:24:16 UTC
Permalink
Paul is absolutely correct. We had a problem last year when we moved from one variant of Unix to another, in that the performance of the SDR/RCVR on the new platform was horrible. We enlisted IBM to assist in the diagnosis, but the performance experts had us tweak OS settings to values that were just absurd. I had been looking at the traces for some time, but was always viewing channels that had already been in a RUNNING state. I decided to capture traces that included the channel start and the TCP handshake - what an eye-opener! Here is a snippet of what we saw and matches Paul's comments below:

* SDR channel formatted trace file for new platform:
* Current socket receive buffer size: 262088
* Current socket send buffer size: 262088
* Socket send buffer size: 32766
* Socket receive buffer size: 2048
* Final socket receive buffer size: 2048
* Final socket send buffer size: 32766
* SDR channel formatted trace file for current platform:
* Current socket receive buffer size: 263536
* Current socket send buffer size: 262144
* Socket send buffer size: 32766
* Socket receive buffer size: 2048
* Final socket receive buffer size: 263536
* Final socket send buffer size: 32766

* RCVR channel formatted trace file for new platform:
* Current socket receive buffer size: 262088
* Current socket send buffer size: 262088
* Socket send buffer size: 2048
* Socket receive buffer size: 32766
* Final socket receive buffer size: 32766
* Final socket send buffer size: 2048
* RCVR channel formatted trace file for current platform:
* Current socket receive buffer size: 263536
* Current socket send buffer size: 262144
* Socket send buffer size: 2048
* Socket receive buffer size: 32766
* Final socket receive buffer size: 263536
* Final socket send buffer size: 2048

The red and green sections above are what you will actually see in the formatted trace files for the channel processes. As you can see, the new platform honors the setsockopt() values, whereas the current one uses a hybrid of those values. We went from an environment that had TCP buffers for a SDR channel of 263536/32766 and RCVR channel of 263536/2048 to an environment that had TCP buffers for a SDR channel of 2048/32766 and RCVR channel of 32766/2048. No wonder we were having performance issues!

We tried setting the documented SndBuffSize & RcvBuffSize parms in the TCP stanza to force the new platform to act like the current one, but to no avail. It wasn't until we found the 'under-documented' parameters of RcvSendBuffSize & RcvRcvBuffSize and set those to match our current environment, that we were able to attain comparable performance. Our final TCP stanza settings looked like this:

TCP:
SndBuffSize=262144
RcvBuffSize=2048
RcvSendBuffSize=2048
RcvRcvBuffSize=262144

Coding all 4 of these TCP buffer parameters got us the expected and desired results. Here is a quick picture to show where those values are used in your environment, with a SDR channel on the left and a RCVR channel on the right:

[cid:image006.jpg-ip/bz97aRHqU3XK2g92M/***@public.gmane.org]

Hope that helps!

Cheers,
Art

________________________________
[National IT Services]Arthur Schanz
Distributed Computing Spec
Messaging and File Transfer






[National IT Green Logo]

[CertWS_color]



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Tuesday, April 01, 2014 4:41 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Window Size for Linux Servers

If I remember correctly MQ uses setsockopt() with SO_SNDBUF and SO_RCVBUF to set the buffer sizes. I believe that these calls are advisory and the OS can ignore the settings. Later versions of MQ trace out the setting of these values, it then queries the current settings and trace those out too so you may be able to tell whether TCP at least accepted your settings. Of there's still no guarantee it will actually use them. However, if MQ is issuing the setting with the correct value there's nothing further it can really do and you should talk to the OS TCP boys to find out why any setting is ignored.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Anderson, Charles W.<mailto:Charles.Anderson-***@public.gmane.org>
Sent: Tuesday, April 01, 2014 4:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Window Size for Linux Servers

John,

We recently went through this when trying to open a 256k TCP Window from z/OS (MQ7.1) to OEL5 server (MQ7.0.1.9).
With no attributes in the TCP stanza we were getting a 64k window on Linux, which is the default.
With specific settings in the TCP stanza, which would have MQ setting the TCP window, the settings were ignored, still 64k.
We opened a PMR with IBM for assistance with this and got a "Not My Problem". That is, it isn't an MQ issue talk to your OS vendor.
No help with why the settings in the TCP stanza didn't work with Linux, they read the traces and said MQ is working. I believe they said they could see MQ setting the Window size in the trace.
We opened a ticket with Oracle and they were not as helpful as IBM, not a clue. Never heard of MQSeries or WMQ.
We set the TCP attributes to zero, per the InfoCenter and MQ let the OS control the TCP window and we were able to get a 256k window on Linux.
I've not tried it on the client side or Linux to Linux.
We did see significant increase in throughput (Sender to Receiver) during heavy volumes on the specific channel we were working on, which resolved our issue.
Also in the course of testing we tried OEL6/MQv7.0 with the same results. We didn't try MQv7.5 as we were going with IBM, not an MQ issue.
We're going with the settings below on new Linux builds for MQ.


TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0



Charles

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dawson, John A
Sent: Monday, March 31, 2014 6:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Window Size for Linux Servers

Fellow MQ'ers,

Has anyone experienced an issue with the TCP/IP window size for transmitting data to/from the Linux platform with WMQ version 7?

How many has had to actually use the below values in a qm.ini file to control the TCP/IP window size?


TCP:
SndBuffSize=
RcvBuffSize=
RcvSndBuffSize=
RcvRcvBuffSize=
ClntSndBuffSize=
ClntRcvBuffSize=
SvrSndBuffSize=
SvrRcvBuffSize=

Thanks for your time and responses.


John Dawson

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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
Tim Zielke
2014-04-01 18:02:12 UTC
Permalink
Hi Art,

Thanks for the informative note! I have saved that off for future reference.

Charles - We don't use OEL, but on SLES I see the behavior that Art is describing below. I'm not sure what Oracle did to look into your issue, but I would of hoped they would of at least asked you to run an strace and recreate the issue. This is an educated guess on my part, but I think it may be an ioctl system call that is adjusting the socket buffer sizes. If you or IBM can point Oracle to the misbehaving system call, I don't think it is unreasonable to ask them to investigate it further.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Schanz, Arthur
Sent: Tuesday, April 01, 2014 6:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Window Size for Linux Servers

Paul is absolutely correct. We had a problem last year when we moved from one variant of Unix to another, in that the performance of the SDR/RCVR on the new platform was horrible. We enlisted IBM to assist in the diagnosis, but the performance experts had us tweak OS settings to values that were just absurd. I had been looking at the traces for some time, but was always viewing channels that had already been in a RUNNING state. I decided to capture traces that included the channel start and the TCP handshake - what an eye-opener! Here is a snippet of what we saw and matches Paul's comments below:

* SDR channel formatted trace file for new platform:
* Current socket receive buffer size: 262088
* Current socket send buffer size: 262088
* Socket send buffer size: 32766
* Socket receive buffer size: 2048
* Final socket receive buffer size: 2048
* Final socket send buffer size: 32766
* SDR channel formatted trace file for current platform:
* Current socket receive buffer size: 263536
* Current socket send buffer size: 262144
* Socket send buffer size: 32766
* Socket receive buffer size: 2048
* Final socket receive buffer size: 263536
* Final socket send buffer size: 32766

* RCVR channel formatted trace file for new platform:
* Current socket receive buffer size: 262088
* Current socket send buffer size: 262088
* Socket send buffer size: 2048
* Socket receive buffer size: 32766
* Final socket receive buffer size: 32766
* Final socket send buffer size: 2048
* RCVR channel formatted trace file for current platform:
* Current socket receive buffer size: 263536
* Current socket send buffer size: 262144
* Socket send buffer size: 2048
* Socket receive buffer size: 32766
* Final socket receive buffer size: 263536
* Final socket send buffer size: 2048

The red and green sections above are what you will actually see in the formatted trace files for the channel processes. As you can see, the new platform honors the setsockopt() values, whereas the current one uses a hybrid of those values. We went from an environment that had TCP buffers for a SDR channel of 263536/32766 and RCVR channel of 263536/2048 to an environment that had TCP buffers for a SDR channel of 2048/32766 and RCVR channel of 32766/2048. No wonder we were having performance issues!

We tried setting the documented SndBuffSize & RcvBuffSize parms in the TCP stanza to force the new platform to act like the current one, but to no avail. It wasn't until we found the 'under-documented' parameters of RcvSendBuffSize & RcvRcvBuffSize and set those to match our current environment, that we were able to attain comparable performance. Our final TCP stanza settings looked like this:

TCP:
SndBuffSize=262144
RcvBuffSize=2048
RcvSendBuffSize=2048
RcvRcvBuffSize=262144

Coding all 4 of these TCP buffer parameters got us the expected and desired results. Here is a quick picture to show where those values are used in your environment, with a SDR channel on the left and a RCVR channel on the right:

[cid:image004.jpg-oTov/U/***@public.gmane.org]

Hope that helps!

Cheers,
Art

________________________________
[National IT Services]Arthur Schanz
Distributed Computing Spec
Messaging and File Transfer





[National IT Green Logo]

[CertWS_color]



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Tuesday, April 01, 2014 4:41 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Window Size for Linux Servers

If I remember correctly MQ uses setsockopt() with SO_SNDBUF and SO_RCVBUF to set the buffer sizes. I believe that these calls are advisory and the OS can ignore the settings. Later versions of MQ trace out the setting of these values, it then queries the current settings and trace those out too so you may be able to tell whether TCP at least accepted your settings. Of there's still no guarantee it will actually use them. However, if MQ is issuing the setting with the correct value there's nothing further it can really do and you should talk to the OS TCP boys to find out why any setting is ignored.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Anderson, Charles W.<mailto:Charles.Anderson-***@public.gmane.org>
Sent: Tuesday, April 01, 2014 4:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Window Size for Linux Servers

John,

We recently went through this when trying to open a 256k TCP Window from z/OS (MQ7.1) to OEL5 server (MQ7.0.1.9).
With no attributes in the TCP stanza we were getting a 64k window on Linux, which is the default.
With specific settings in the TCP stanza, which would have MQ setting the TCP window, the settings were ignored, still 64k.
We opened a PMR with IBM for assistance with this and got a "Not My Problem". That is, it isn't an MQ issue talk to your OS vendor.
No help with why the settings in the TCP stanza didn't work with Linux, they read the traces and said MQ is working. I believe they said they could see MQ setting the Window size in the trace.
We opened a ticket with Oracle and they were not as helpful as IBM, not a clue. Never heard of MQSeries or WMQ.
We set the TCP attributes to zero, per the InfoCenter and MQ let the OS control the TCP window and we were able to get a 256k window on Linux.
I've not tried it on the client side or Linux to Linux.
We did see significant increase in throughput (Sender to Receiver) during heavy volumes on the specific channel we were working on, which resolved our issue.
Also in the course of testing we tried OEL6/MQv7.0 with the same results. We didn't try MQv7.5 as we were going with IBM, not an MQ issue.
We're going with the settings below on new Linux builds for MQ.


TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0



Charles

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dawson, John A
Sent: Monday, March 31, 2014 6:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Window Size for Linux Servers

Fellow MQ'ers,

Has anyone experienced an issue with the TCP/IP window size for transmitting data to/from the Linux platform with WMQ version 7?

How many has had to actually use the below values in a qm.ini file to control the TCP/IP window size?


TCP:
SndBuffSize=
RcvBuffSize=
RcvSndBuffSize=
RcvRcvBuffSize=
ClntSndBuffSize=
ClntRcvBuffSize=
SvrSndBuffSize=
SvrRcvBuffSize=

Thanks for your time and responses.


John Dawson

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

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
Raul Acevedo
2014-04-02 17:55:24 UTC
Permalink
I have been trying to connect using the JMS Output node in Message Broker
to AQ for several weeks and have not been successful.
If anyone knows how to do this, please let me know.

I am using Oracle OID LDAP to define the JNDI. According to the
instructions in the help it should work:

1. Complete the following steps in Oracle AQ, referring to Oracle
documentation for the specific details of each step.
a. You must install the Oracle Internet Directory Server (OID) to
host the JNDI administered objects for Oracle AQ.
You can configure Oracle AQ to register JMS connection
factories and destinations (queues and topics)
automatically with the OID server when these JMS
connection factories and destinations are created in the
Oracle database.
b. Create the database tables to hold the JMS queues and topics.
c. Create the JMS queues and topics and associate them with the
tables created in step 1b.

OID is installed and configured:And here is the program that was able
to register it:
****************************************************************************************************************
import java.util.Hashtable;
import java.util.Properties;
import javax.jms.JMSException;
import javax.naming.Context;
import oracle.jms.AQjmsConstants;
import oracle.jms.AQjmsFactory;

public class registerOracleAQ {
public static void main(String[] args) {
createCF();
}

private static void createCF() {
String url;
Hashtable env = new Hashtable(5, 0.75f);
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://orappsrv01:389");
env.put("searchbase",
"cn=oretail,cn=OracleContext,dc=orappsrv01,dc=com");
env.put
("server_dn","cn=oretail,cn=OracleContext,dc=orappsrv01,dc=com");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=orcladmin");
env.put(Context.SECURITY_CREDENTIALS, "oracle10g");
Properties properties = new Properties();
properties.setProperty("user","ribaq");
properties.setProperty("password","ribaq");

url = "jdbc:oracle:thin:@ordbsrv:1521:oretail";
try {
AQjmsFactory.registerConnectionFactory(env, "ribaq", url,
properties, "queue");

} catch ( JMSException e) {
e.printStackTrace();
}
}
}
**************************************************************************************************************
This is the ldif I used to create these 3 leaves in those branches:
****************************************************************************************************
dn: cn=RIBAQ.ETXITEM,cn=OracleDBQueues,cn=oretail,cn=OracleContext,
dc=orappsrv01,dc=com
orcldbaqpointerattr:
cn=RIBAQ.ETXITEMTABLE,cn=OracleDBQueueTables,cn=oretail,cn=OracleContext,dc=orappsrv01,dc=com
javaClassName: oracle.jms.AQjmsDestination
orcldbaqobjname: ETXITEM
javaFactory: oracle.jms.AQjmsDestinationFactory
objectClass: top
objectClass: javaContainer
objectClass: javaObject
objectClass: javaNamingReference
objectClass: orclDBAQObject
orcldbaqobjtype: Queue
cn: RIBAQ.ETXITEM
orcldbaqgeneric: maxretries=3
orcldbaqobjowner: RIBAQ

dn:
cn=RIBAQ.ETXITEMTABLE,cn=OracleDBQueueTables,cn=oretail,cn=OracleContext,
dc=orappsrv01,dc=com
orcldbaqobjname: ETXITEMTABLE
orcldbaqobjtype: QueueTable
objectClass: top
objectClass: javaContainer
objectClass: javaObject
objectClass: javaNamingReference
objectClass: orclDBAQObject
javaClassName: oracle.AQ.AQOracleQueueTable
javaFactory: oracle.AQ.AQOracleQueueTableFactory
orcldbaqobjowner: RIBAQ
orcldbaqgeneric: PayloadType=SYS.AQ$_JMS_MESSAGE
cn: RIBAQ.ETXITEMTABLE

dn: cn=RIBAQ,cn=OracleDBConnections,cn=oretail,cn=OracleContext,
dc=orappsrv01,dc=com
objectClass: top
objectClass: javaContainer
objectClass: javaObject
objectClass: javaNamingReference
objectClass: orclDBAQConnection
javaFactory: oracle.jms.AQjmsConnectionFactory
javaClassName: oracle.jms.AQjmsQueueConnectionFactory
cn: RIBAQ
orcldbaqgeneric: JDBC_connect_string=jdbc:oracle:thin:@ordbsrv:1521:oretail
orcldbaqgeneric: Username=ribaq
orcldbaqgeneric: Password=xxxxxxx
*******************************************************************************************************

I then uploaded it by using:
ldapadd -h orappsrv01 -p 389 -D "cn=orcladmin" -w oracle10g -c -v -f
cleanqueue.ldif
==========================================================================

mqsichangeproperties IB9NODE -c JMSProviders -o Oracle_AQ -n jarsURL
-v \Winapp\Oracle\jdbc\lib
mqsichangeproperties IB9NODE -c JMSProviders -o Oracle_AQ -n
nativeLibs -v \Winapp\Oracle\jdbc\lib
mqsichangeproperties IB9NODE -c JMSProviders –o Oracle_AQ -n
connectionFactoryName -v
cn=ribaq,cn=OracleDBConnections,cn=oretail,cn=OracleContext,dc=orappsrv01,dc=com
mqsichangeproperties IB9NODE -c JMSProviders –o Oracle_AQ -n
initialContextFactory -v com.sun.jndi.ldap.LdapCtxFactory
mqsichangeproperties IB9NODE –c JMSProviders –o Oracle_AQ -n
jndiBindingsLocation -v ldap://orappsrv01:389
mqsichangeproperties IB9NODE -c JMSProviders –o Oracle_AQ -n
jarsURL,InitialContextFactory -v \Winapps\Oracle\jdbc
\lib,com.sun.jndi.ldap.LdapCtxFactory
mqsireportproperties IB9NODE -o Oracle_AQ -r -c JMSProviders

JMSProviders
Oracle_AQ
clientAckBatchSize='0'
clientAckBatchTime='0'
connectionFactoryName=''
initialContextFactory='com.sun.jndi.ldap.LdapCtxFactory'
jarsURL='\Winapp\Oracle\jdbc\lib'
jmsAsyncExceptionHandling='false'
jmsProviderXASupport='true'
jndiBindingsLocation='ldap://orappsrv01:389'
jndiEnvironmentParms='default_none'
nativeLibs='default_Path'
proprietaryAPIAttr1='default_none'
proprietaryAPIAttr2='default_none'
proprietaryAPIAttr3='default_none'
proprietaryAPIAttr4='default_none'
proprietaryAPIAttr5='default_none'
proprietaryAPIHandler='default_none'


================================================================================================================

========================================================================================================================

================================================================================================================================
Result:
2014-04-02 11:07:29.232224 9980 UserTrace BIP12036E: Failed to find
JNDI definition for destination queue
''cn=RIBAQ.ETXITEM,cn=OracleDBQueues,cn=oretail,cn=OracleContext,
dc=orappsrv01,dc=com''.
The node cannot obtain a JNDI
Administered Object, because some of the values specified are incorrect.
The JMS Exception text is: ''javax.naming.Reference incompatible with
javax.jms.Destination''.
Check the JNDI Administered
configuration for the JMS provider used by the node.
Either:
Modify the JNDI Administered
objects and rebuild the bindings
or
Change the Configurable Service
attributes associated with this JMS Provider and restart the execution
group
or
Change the node attributes and
redeploy the message flow.
2014-04-02 11:07:29.740386 9980 UserTrace BIP2231E: Error detected
whilst processing a message in node
'ESB_RIB_ItemMaintenance.ESB_RIB_RibMessages.PublishToRIB_JMSOutput'.
The message broker detected an error
whilst processing a message in node
'ESB_RIB_ItemMaintenance.ESB_RIB_RibMessages.PublishToRIB_JMSOutput'. The
message has been augmented with an exception list and has been propagated
to the node's failure terminal for further processing.
See the following messages for
details of the error.
2014-04-02 11:07:29.740456 9980 RecoverableException BIP4640E: IIB
JMSClient. ''Broker 'IB9NODE'; Execution Group 'default'; Message Flow
'ESB_RIB_ItemMaintenance'; Node
'ESB_RIB_RibMessages.PublishToRIB_JMSOutput::ComIbmJMSClientOutputNode' ''
There is a configuration problem with the JNDI Administered objects where:
Initial Context Factory = ''com.sun.jndi.ldap.LdapCtxFactory''. Location
of the bindings = ''ldap://orappsrv01:389''. ConnectionFactory Name =
''oracle.jms.AQjmsDestinationFactory''. JMS destination = ''''. The
exception text is : ''javax.naming.Reference incompatible with
javax.jms.Destination''.
The node cannot obtain a JNDI
Administered Object, because some of the values specified are incorrect.
Check the JNDI Administered
configuration for the JMS provider used by the node.
Either:
Modify the JNDI Administered
objects and rebuild the bindings
or
Change the Configurable Service
attributes associated with this JMS Provider and restart the execution
group
or
Change the node attributes and
redeploy the message flow.
2014-04-02 11:07:29.740552 9980 UserTrace BIP2539I: Node
'ESB_RIB_ItemMaintenance.ESB_RIB_RibMessages.Trace2': Evaluating expression
''ExceptionList'' at ('', '1.3'). This resolved to ''ExceptionList''. The
result was ''ROW... Root Element Type=16777216 NameSpace='' Name='Root'
Value=NULL''.
2014-04-02 11:07:29.740850 9980 UserTrace BIP4060I: Data
''( ['MQROOT' : 0x27b5cbb0]

(0x01000000:Name):RecoverableException = (
(0x03000000:NameValue):File
= 'F:\build\slot2\S000_P\src\DataFlowEngine\MessageServices
\ImbDataFlowNode.cpp' (CHARACTER)
(0x03000000:NameValue):Line
= 1153 (INTEGER)
(0x03000000:NameValue):Function
= 'ImbDataFlowNode::createExceptionList' (CHARACTER)
(0x03000000:NameValue):Type
= 'ComIbmJMSClientOutputNode' (CHARACTER)
(0x03000000:NameValue):Name
=
'ESB_RIB_ItemMaintenance#FCMComposite_1_4.ESB_RIB_RibMessages#FCMComposite_1_7' (CHARACTER)
(0x03000000:NameValue):Label
=
'ESB_RIB_ItemMaintenance.ESB_RIB_RibMessages.PublishToRIB_JMSOutput' (CHARACTER)
(0x03000000:NameValue):Catalog
= 'BIPmsgs' (CHARACTER)
(0x03000000:NameValue):Severity
= 3 (INTEGER)
(0x03000000:NameValue):Number
= 2230 (INTEGER)
(0x03000000:NameValue):Text
= 'Node throwing exception' (CHARACTER)

(0x01000000:Name ):RecoverableException = (
(0x03000000:NameValue):File
= 'JMSClientErrors.java' (CHARACTER)
(0x03000000:NameValue):Line
= 694 (INTEGER)

(0x03000000:NameValue):Function = 'JMSClientHelper::lookUpJMSDestinations
()' (CHARACTER)
(0x03000000:NameValue):Type
= '' (CHARACTER)
(0x03000000:NameValue):Name
= '' (CHARACTER)
(0x03000000:NameValue):Label
= '' (CHARACTER)
(0x03000000:NameValue):Catalog
= 'BIPmsgs' (CHARACTER)

(0x03000000:NameValue):Severity = 3 (INTEGER)
(0x03000000:NameValue):Number
= 4640 (INTEGER)
(0x03000000:NameValue):Text
= 'Unable to find JMS Destination in JNDI' (CHARACTER)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= 'Broker 'IB9NODE'; Execution Group 'default'; Message Flow
'ESB_RIB_ItemMaintenance'; Node
'ESB_RIB_RibMessages.PublishToRIB_JMSOutput::ComIbmJMSClientOutputNode'
' (CHARACTER)
)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= 'com.sun.jndi.ldap.LdapCtxFactory' (CHARACTER)
)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= 'ldap://orappsrv01:389' (CHARACTER)
)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= 'oracle.jms.AQjmsDestinationFactory' (CHARACTER)
)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= '' (CHARACTER)
)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= 'javax.naming.Reference incompatible with
javax.jms.Destination' (CHARACTER)
)
(0x01000000:Name ):Insert
= (
(0x03000000:NameValue):Type
= 5 (INTEGER)
(0x03000000:NameValue):Text
= ' java.lang.ClassCastException : javax.naming.Reference incompatible with
javax.jms.Destination' (CHARACTER)
)
)
)
)
'' from trace node
'ESB_RIB_ItemMaintenance.ESB_RIB_RibMessages.Trace2'.
===============================================================================================================================
I have run out of ideas.

Respectfully,

Raúl L. Acevedo
Senior IT Architect
Smarter Commerce - AIS Retail
IBM Global Business Service
818 599 6626 mobile
***@us.ibm.com email
Dawson, John A
2014-04-02 11:11:03 UTC
Permalink
All,

Thank you very much for all of your responses on this matter. Since this list server has always been a very vocal group, the lack of number of responses tells me that these qm.ini parameters are not used by many shops.


Mr. Clarke,

As always, your input is very valued.


Mr. Schanz,

Thank you for your input, I just happen to find your excellent presentation from the WMQ Technical conference, listed below. This is why attendance at the technical conference is so valuable.

http://www.mqtechconference.com/sessions_v2013/MQTC_v2013-WMQ_and_TCP_Buffers-Size_DOES_Matter.pdf



John Dawson

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Schanz, Arthur
Sent: Tuesday, April 01, 2014 6:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Window Size for Linux Servers

Paul is absolutely correct. We had a problem last year when we moved from one variant of Unix to another, in that the performance of the SDR/RCVR on the new platform was horrible. We enlisted IBM to assist in the diagnosis, but the performance experts had us tweak OS settings to values that were just absurd. I had been looking at the traces for some time, but was always viewing channels that had already been in a RUNNING state. I decided to capture traces that included the channel start and the TCP handshake - what an eye-opener! Here is a snippet of what we saw and matches Paul's comments below:

* SDR channel formatted trace file for new platform:
* Current socket receive buffer size: 262088
* Current socket send buffer size: 262088
* Socket send buffer size: 32766
* Socket receive buffer size: 2048
* Final socket receive buffer size: 2048
* Final socket send buffer size: 32766
* SDR channel formatted trace file for current platform:
* Current socket receive buffer size: 263536
* Current socket send buffer size: 262144
* Socket send buffer size: 32766
* Socket receive buffer size: 2048
* Final socket receive buffer size: 263536
* Final socket send buffer size: 32766

* RCVR channel formatted trace file for new platform:
* Current socket receive buffer size: 262088
* Current socket send buffer size: 262088
* Socket send buffer size: 2048
* Socket receive buffer size: 32766
* Final socket receive buffer size: 32766
* Final socket send buffer size: 2048
* RCVR channel formatted trace file for current platform:
* Current socket receive buffer size: 263536
* Current socket send buffer size: 262144
* Socket send buffer size: 2048
* Socket receive buffer size: 32766
* Final socket receive buffer size: 263536
* Final socket send buffer size: 2048

The red and green sections above are what you will actually see in the formatted trace files for the channel processes. As you can see, the new platform honors the setsockopt() values, whereas the current one uses a hybrid of those values. We went from an environment that had TCP buffers for a SDR channel of 263536/32766 and RCVR channel of 263536/2048 to an environment that had TCP buffers for a SDR channel of 2048/32766 and RCVR channel of 32766/2048. No wonder we were having performance issues!

We tried setting the documented SndBuffSize & RcvBuffSize parms in the TCP stanza to force the new platform to act like the current one, but to no avail. It wasn't until we found the 'under-documented' parameters of RcvSendBuffSize & RcvRcvBuffSize and set those to match our current environment, that we were able to attain comparable performance. Our final TCP stanza settings looked like this:

TCP:
SndBuffSize=262144
RcvBuffSize=2048
RcvSendBuffSize=2048
RcvRcvBuffSize=262144

Coding all 4 of these TCP buffer parameters got us the expected and desired results. Here is a quick picture to show where those values are used in your environment, with a SDR channel on the left and a RCVR channel on the right:

[cid:image004.jpg-CyrmR+***@public.gmane.org]

Hope that helps!

Cheers,
Art

________________________________
[National IT Services]Arthur Schanz
Distributed Computing Spec
Messaging and File Transfer





[National IT Green Logo]

[CertWS_color]



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Tuesday, April 01, 2014 4:41 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Window Size for Linux Servers

If I remember correctly MQ uses setsockopt() with SO_SNDBUF and SO_RCVBUF to set the buffer sizes. I believe that these calls are advisory and the OS can ignore the settings. Later versions of MQ trace out the setting of these values, it then queries the current settings and trace those out too so you may be able to tell whether TCP at least accepted your settings. Of there's still no guarantee it will actually use them. However, if MQ is issuing the setting with the correct value there's nothing further it can really do and you should talk to the OS TCP boys to find out why any setting is ignored.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<https://urldefense.proofpoint.com/v1/url?u=http://www.mqgem.com&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=cbfbd89d80be2e369749428eb4193ef169ea30532b57b60bc4675088e29f5d94>

From: Anderson, Charles W.<mailto:Charles.Anderson-***@public.gmane.org>
Sent: Tuesday, April 01, 2014 4:40 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Window Size for Linux Servers

John,

We recently went through this when trying to open a 256k TCP Window from z/OS (MQ7.1) to OEL5 server (MQ7.0.1.9).
With no attributes in the TCP stanza we were getting a 64k window on Linux, which is the default.
With specific settings in the TCP stanza, which would have MQ setting the TCP window, the settings were ignored, still 64k.
We opened a PMR with IBM for assistance with this and got a "Not My Problem". That is, it isn't an MQ issue talk to your OS vendor.
No help with why the settings in the TCP stanza didn't work with Linux, they read the traces and said MQ is working. I believe they said they could see MQ setting the Window size in the trace.
We opened a ticket with Oracle and they were not as helpful as IBM, not a clue. Never heard of MQSeries or WMQ.
We set the TCP attributes to zero, per the InfoCenter and MQ let the OS control the TCP window and we were able to get a 256k window on Linux.
I've not tried it on the client side or Linux to Linux.
We did see significant increase in throughput (Sender to Receiver) during heavy volumes on the specific channel we were working on, which resolved our issue.
Also in the course of testing we tried OEL6/MQv7.0 with the same results. We didn't try MQv7.5 as we were going with IBM, not an MQ issue.
We're going with the settings below on new Linux builds for MQ.


TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0



Charles

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Dawson, John A
Sent: Monday, March 31, 2014 6:14 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Window Size for Linux Servers

Fellow MQ'ers,

Has anyone experienced an issue with the TCP/IP window size for transmitting data to/from the Linux platform with WMQ version 7?

How many has had to actually use the below values in a qm.ini file to control the TCP/IP window size?


TCP:
SndBuffSize=
RcvBuffSize=
RcvSndBuffSize=
RcvRcvBuffSize=
ClntSndBuffSize=
ClntRcvBuffSize=
SvrSndBuffSize=
SvrRcvBuffSize=

Thanks for your time and responses.


John Dawson

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=9c526e7138c711e1cb2b3a122df2870ae48cc2f6c28efcec8e1fd980c6d95986> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=77347b0dea25b71ff7b1d10db535ba5399d3f7eb438aff8d1be08f992a9fc023> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=8ff4786fd5e6c7208ab7dc002f025d28979e608aa53e9a5219f2d2cace37fa55>

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=9c526e7138c711e1cb2b3a122df2870ae48cc2f6c28efcec8e1fd980c6d95986> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=77347b0dea25b71ff7b1d10db535ba5399d3f7eb438aff8d1be08f992a9fc023> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=8ff4786fd5e6c7208ab7dc002f025d28979e608aa53e9a5219f2d2cace37fa55>

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=9c526e7138c711e1cb2b3a122df2870ae48cc2f6c28efcec8e1fd980c6d95986> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=77347b0dea25b71ff7b1d10db535ba5399d3f7eb438aff8d1be08f992a9fc023> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=8ff4786fd5e6c7208ab7dc002f025d28979e608aa53e9a5219f2d2cace37fa55>

________________________________
List Archive<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/archives/mqser-l.html&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=9c526e7138c711e1cb2b3a122df2870ae48cc2f6c28efcec8e1fd980c6d95986> - Manage Your List Settings<https://urldefense.proofpoint.com/v1/url?u=http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1%3Dmqser-l%26A%3D1&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=77347b0dea25b71ff7b1d10db535ba5399d3f7eb438aff8d1be08f992a9fc023> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<https://urldefense.proofpoint.com/v1/url?u=http://www.lsoft.com/resources/manuals.asp&k=wdHsQuqY0Mqq1fNjZGIYnA%3D%3D%0A&r=XluWPTUchfbxgUKw1SihIVRoUhgr41qgYFWyEVx8iCE%3D%0A&m=W3BvS%2FghIEPlnVtVQs%2F3T%2BgqjBdeELKvLVRlIIAsahw%3D%0A&s=8ff4786fd5e6c7208ab7dc002f025d28979e608aa53e9a5219f2d2cace37fa55>

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

Loading...