Weird 2035 with FTE

Discussion:

Weird 2035 with FTE

T.Rob

2013-07-25 17:45:34 UTC

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might have
some insight into what's going on. When I run fteListAgents in bindings
mode, under my ID, which is in the mqm group, I get a 2035 Type-1 CONN NOT
AUTHORIZED. When I use MS0P to view the event messages it shows the ID
connecting as "UNKNOWN." However, when I use the same account to run
amqsput and amqsget it works just fine. Is there something in FTE or in
Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long. But
what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
BFGCL0033E: A messaging problem prevented the command from completing
successfully. The WebSphere MQ completion code was 2, and the reason code
was 2035. A connection could not be established to queue manager [NAME OF
COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR]
Sample AMQSPUT0 start
target queue is SYSTEM.DEFAULT.LOCAL.QUEUE
Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR]
Sample AMQSGET0 start
message <Hello world!>
no more messages
Sample AMQSGET0 end
$

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

Potkay, Peter M (CTO Architecture + Engineering)

2013-07-25 19:00:30 UTC

Permalink

Jeff will be along shortly to confirm / correct this, but I seem to remember him saying here or on MQSeries.net that for reasons I can't remember the JVM won't have a reliable ID to use, so it sends none, so you are getting the ID of Unknown. The C language does not have that problem as the real ID the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might have some insight into what's going on. When I run fteListAgents in bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it shows the ID connecting as "UNKNOWN." However, when I use the same account to run amqsput and amqsget it works just fine. Is there something in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long. But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
BFGCL0033E: A messaging problem prevented the command from completing successfully. The WebSphere MQ completion code was 2, and the reason code was 2035. A connection could not be established to queue manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR] Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no more messages Sample AMQSGET0 end $

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
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

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

T.Rob

2013-07-25 20:47:53 UTC

Permalink

I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 15:01 PM
Subject: Re: Weird 2035 with FTE
Jeff will be along shortly to confirm / correct this, but I seem to

remember

Post by Potkay, Peter M (CTO Architecture + Engineering)
him saying here or on MQSeries.net that for reasons I can't remember the
JVM won't have a reliable ID to use, so it sends none, so you are getting

the

Post by Potkay, Peter M (CTO Architecture + Engineering)
ID of Unknown. The C language does not have that problem as the real ID
the process runs under is used.
Peter Potkay
-----Original Message-----
Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
Subject: Weird 2035 with FTE
Hi folks,
I'm seeing some weird behavior in FTE and was hoping someone else might
have some insight into what's going on. When I run fteListAgents in
bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-
1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it
shows the ID connecting as "UNKNOWN." However, when I use the same
account to run amqsput and amqsget it works just fine. Is there something
in FTE or in Java that causes this?
I know that UNKNOWN is what gets returned when a user ID is too long.
But what would cause it to work under WMQ C code but fail under Java?
Thanks -- T.Rob
$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
BFGCL0033E: A messaging problem prevented the command from
completing successfully. The WebSphere MQ completion code was 2, and
the reason code was 2035. A connection could not be established to queue
manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSPUT0 start target queue is
SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!
Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no
more messages Sample AMQSGET0 end $
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
**********************************************************
**
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you

are

Post by Potkay, Peter M (CTO Architecture + Engineering)
not the intended recipient, please notify the sender immediately by return
e-mail, delete this communication and destroy all copies.
**********************************************************
**
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

Brumbaugh Glen

2013-07-25 21:39:28 UTC

Permalink

T-Rob,

As you know, being in the mqm group does not provide any OAM rights. Most of these rights are assumed by user's to exist because of the sticky bits set on the binaries (e.g. runmqsc).
What is the Sticky Bit in MFT for the executable? Is the executable NFS mounted?
If you explicitly grant the necessary rights to your User ID do you still have the same problem?
There is a similar issue that you and I worked on for Message Broker using WMQ 7.5. There is an associated Technote 1442991. I know that you are aware of this but I include it for everyone on the list.

With that as background, I have frequently encountered files that are "owned" as the User ID "Unknown" when things were not set up correctly on NFS mounts. Could this be a combination of the Sticky Bit behavior and and a NFS mount issue?

Regards,

Glen Brumbaugh
Technology Manager
Prolifics
Global Technology Solutions Provider

Post by T.Rob
I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?

remember

the

are

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
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

T.Rob

2013-07-26 13:34:35 UTC

Permalink

Hi Glen,

Been doing some more testing and verification.

. This is all local bindings mode. The Command and Coordination
QMgrs are the same and none of the properties files has a client channel
specified.

. No NFS involved. Executables are on dedicated SAN LUN.

. In addition to being able to run the C samples, I can run the
IVTRun program so the WMQ JMS classes work.

. The executables in the FTE bin directory do not have any setuid
bits set and are world-executable.

. The samples I'm using as my control test (amwqsget and amqsput)
also do not have any setuid bits set and are world-executable.

Additionally, the issues with OAM you describe are further down the stack
than this call is getting. Here's the relevant bits from FDC:

| Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred.
|

| FDCSequenceNumber :- 0
|

| Comment1 :- xcsGetpwuid failed to get password entry for process
|

| with real uid 10211.
|

| Comment2 :- Details: getuid() returned 10211; getpwuid_r(10211)
|

| failed with errno=0.
|

| Comment3 :- A user name of "UNKNOWN" will be used, which will
|

| likely cause later authorisation failures. Note this FFST can be turned
|

| off by exporting env var AMQ_NOFFST_PROCESS_UID.
|

The FDC is cut under my ID rather than "UNKNOWN." The getuid() and
getpwuid() calls appear to work in the test C code and IVT program, assuming
these make the same OS API call as FTE.

I'm thinking this might be an FTE bug since it doesn't present anywhere but
FTE. Unless the list has any other suggestions, I'm going to ask my client
to open a PMR.

Thanks - T.Rob

$ dspmqver

Name: WebSphere MQ

Version: 7.1.0.2

Level: p710-002-121018

BuildType: IKAP - (Production)

Platform: WebSphere MQ for Linux (zSeries 64-bit platform)

Mode: 64-bit

O/S: Linux 2.6.32-358.11.1.el6.s390x

InstName: Installation1

InstDesc:

InstPath: /opt/mqm

DataPath: /var/mqm

Primary: Yes

MaxCmdLevel: 711

$ fteDisplayVersion -v

5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED

Name: WebSphere MQ File Transfer Edition Server

Version: 7.0.4.3

Level: f704-FP3-20130429-1711

Platform: Linux (2.6.32-358.11.1.el6.s390x)

Architecture: s390

JVM: JRE 1.6.0 IBM J9 2.4 Linux s390-31
jvmxz3160sr12-20121024_126067 (JIT enabled, AOT enabled)

J9VM - 20121024_126067

JIT - r9_20120914_26057

GC - 20120928_AA

Product: /opt/ibm/WMQFTE

Configuration: /var/ibm/WMQFTE/config

WebSphere MQ Components:

Name: Common Services for Java Platform, Standard Edition

Version: 7.0.1.9

Level: k701-109-120705

$

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Brumbaugh Glen
Sent: Thursday, July 25, 2013 17:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

T-Rob,

As you know, being in the mqm group does not provide any OAM rights. Most
of these rights are assumed by user's to exist because of the sticky bits
set on the binaries (e.g. runmqsc).

What is the Sticky Bit in MFT for the executable? Is the executable NFS
mounted?

If you explicitly grant the necessary rights to your User ID do you still
have the same problem?

There is a similar issue that you and I worked on for Message Broker using
WMQ 7.5. There is an associated Technote 1442991. I know that you are
aware of this but I include it for everyone on the list.

With that as background, I have frequently encountered files that are
"owned" as the User ID "Unknown" when things were not set up correctly on
NFS mounts. Could this be a combination of the Sticky Bit behavior and and
a NFS mount issue?

Regards,

Glen Brumbaugh

Technology Manager
Prolifics

Global Technology Solutions Provider

On Jul 25, 2013, at 4:47 PM, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org> wrote:

I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 15:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to

remember

him saying here or on MQSeries.net that for reasons I can't remember the
JVM won't have a reliable ID to use, so it sends none, so you are getting

the

ID of Unknown. The C language does not have that problem as the real ID
the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might
have some insight into what's going on. When I run fteListAgents in
bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-
1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it
shows the ID connecting as "UNKNOWN." However, when I use the same
account to run amqsput and amqsget it works just fine. Is there something
in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long.
But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS
RESERVED
BFGCL0033E: A messaging problem prevented the command from
completing successfully. The WebSphere MQ completion code was 2, and
the reason code was 2035. A connection could not be established to queue
manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSPUT0 start target queue is
SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no
more messages Sample AMQSGET0 end $

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

2013-07-26 15:24:12 UTC

Permalink

Hi T.Rob,

I noticed you said you tested a getpwuid call. Did you also test a getpwuid_r call? It looks like a getpwuid_r call was failing in that FDC, instead of a getpwuid call.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, July 26, 2013 8:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi Glen,

Been doing some more testing and verification.

* This is all local bindings mode. The Command and Coordination QMgrs are the same and none of the properties files has a client channel specified.

* No NFS involved. Executables are on dedicated SAN LUN.

* In addition to being able to run the C samples, I can run the IVTRun program so the WMQ JMS classes work.

* The executables in the FTE bin directory do not have any setuid bits set and are world-executable.

* The samples I'm using as my control test (amwqsget and amqsput) also do not have any setuid bits set and are world-executable.

Additionally, the issues with OAM you describe are further down the stack than this call is getting. Here's the relevant bits from FDC:

| Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred. |
| FDCSequenceNumber :- 0 |
| Comment1 :- xcsGetpwuid failed to get password entry for process |
| with real uid 10211. |
| Comment2 :- Details: getuid() returned 10211; getpwuid_r(10211) |
| failed with errno=0. |
| Comment3 :- A user name of "UNKNOWN" will be used, which will |
| likely cause later authorisation failures. Note this FFST can be turned |
| off by exporting env var AMQ_NOFFST_PROCESS_UID. |

The FDC is cut under my ID rather than "UNKNOWN." The getuid() and getpwuid() calls appear to work in the test C code and IVT program, assuming these make the same OS API call as FTE.

I'm thinking this might be an FTE bug since it doesn't present anywhere but FTE. Unless the list has any other suggestions, I'm going to ask my client to open a PMR.

Thanks - T.Rob

$ dspmqver
Name: WebSphere MQ
Version: 7.1.0.2
Level: p710-002-121018
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Linux (zSeries 64-bit platform)
Mode: 64-bit
O/S: Linux 2.6.32-358.11.1.el6.s390x
InstName: Installation1
InstDesc:
InstPath: /opt/mqm
DataPath: /var/mqm
Primary: Yes
MaxCmdLevel: 711
$ fteDisplayVersion -v
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
Name: WebSphere MQ File Transfer Edition Server
Version: 7.0.4.3
Level: f704-FP3-20130429-1711
Platform: Linux (2.6.32-358.11.1.el6.s390x)
Architecture: s390
JVM: JRE 1.6.0 IBM J9 2.4 Linux s390-31 jvmxz3160sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT - r9_20120914_26057
GC - 20120928_AA
Product: /opt/ibm/WMQFTE
Configuration: /var/ibm/WMQFTE/config

WebSphere MQ Components:

Name: Common Services for Java Platform, Standard Edition
Version: 7.0.1.9
Level: k701-109-120705
$

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Brumbaugh Glen
Sent: Thursday, July 25, 2013 17:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

T-Rob,

As you know, being in the mqm group does not provide any OAM rights. Most of these rights are assumed by user's to exist because of the sticky bits set on the binaries (e.g. runmqsc).
What is the Sticky Bit in MFT for the executable? Is the executable NFS mounted?
If you explicitly grant the necessary rights to your User ID do you still have the same problem?
There is a similar issue that you and I worked on for Message Broker using WMQ 7.5. There is an associated Technote 1442991. I know that you are aware of this but I include it for everyone on the list.

With that as background, I have frequently encountered files that are "owned" as the User ID "Unknown" when things were not set up correctly on NFS mounts. Could this be a combination of the Sticky Bit behavior and and a NFS mount issue?

Regards,

Glen Brumbaugh
Technology Manager
Prolifics
Global Technology Solutions Provider
On Jul 25, 2013, at 4:47 PM, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>> wrote:

I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 15:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to
remember
him saying here or on MQSeries.net<http://MQSeries.net> that for reasons I can't remember the
JVM won't have a reliable ID to use, so it sends none, so you are getting
the
ID of Unknown. The C language does not have that problem as the real ID
the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might
have some insight into what's going on. When I run fteListAgents in
bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-
1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it
shows the ID connecting as "UNKNOWN." However, when I use the same
account to run amqsput and amqsget it works just fine. Is there something
in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long.
But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS
RESERVED
BFGCL0033E: A messaging problem prevented the command from
completing successfully. The WebSphere MQ completion code was 2, and
the reason code was 2035. A connection could not be established to queue
manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSPUT0 start target queue is
SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no
more messages Sample AMQSGET0 end $

________________________________
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

T.Rob

2013-07-26 16:35:13 UTC

Permalink

Hi Tim,

My testing was by using several things other than WMQ FTE to connect to MQ.
It's WMQ making the getpwuid or getpwuir_r call and I'm just assuming that
it would make the same call regardless of what connects to it. It seems
pretty straightforward to first get the UID of the process, then walk the
group entries and that it would do the same procedure for any type of
connection. However, FTE may have access to some privileged API calls. I
remember a while back when FTE 7.0.1 didn't work with WMQ 7.0.1
(http://www-01.ibm.com/support/docview.wss?uid=swg1IC62582) in bindings mode
and am wondering if this is a regression or similar problem.

Thanks - T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Tim Zielke
Sent: Friday, July 26, 2013 11:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi T.Rob,

I noticed you said you tested a getpwuid call. Did you also test a
getpwuid_r call? It looks like a getpwuid_r call was failing in that FDC,
instead of a getpwuid call.

Thanks,

Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Friday, July 26, 2013 8:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi Glen,

Been doing some more testing and verification.

. This is all local bindings mode. The Command and Coordination
QMgrs are the same and none of the properties files has a client channel
specified.

. No NFS involved. Executables are on dedicated SAN LUN.

. In addition to being able to run the C samples, I can run the
IVTRun program so the WMQ JMS classes work.

. The executables in the FTE bin directory do not have any setuid
bits set and are world-executable.

. The samples I'm using as my control test (amwqsget and amqsput)
also do not have any setuid bits set and are world-executable.

Additionally, the issues with OAM you describe are further down the stack
than this call is getting. Here's the relevant bits from FDC:

| Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred.
|

| FDCSequenceNumber :- 0
|

| Comment1 :- xcsGetpwuid failed to get password entry for process
|

| with real uid 10211.
|

| Comment2 :- Details: getuid() returned 10211; getpwuid_r(10211)
|

| failed with errno=0.
|

| Comment3 :- A user name of "UNKNOWN" will be used, which will
|

| likely cause later authorisation failures. Note this FFST can be turned
|

| off by exporting env var AMQ_NOFFST_PROCESS_UID.
|

The FDC is cut under my ID rather than "UNKNOWN." The getuid() and
getpwuid() calls appear to work in the test C code and IVT program, assuming
these make the same OS API call as FTE.

I'm thinking this might be an FTE bug since it doesn't present anywhere but
FTE. Unless the list has any other suggestions, I'm going to ask my client
to open a PMR.

Thanks - T.Rob

$ dspmqver

Name: WebSphere MQ

Version: 7.1.0.2

Level: p710-002-121018

BuildType: IKAP - (Production)

Platform: WebSphere MQ for Linux (zSeries 64-bit platform)

Mode: 64-bit

O/S: Linux 2.6.32-358.11.1.el6.s390x

InstName: Installation1

InstDesc:

InstPath: /opt/mqm

DataPath: /var/mqm

Primary: Yes

MaxCmdLevel: 711

$ fteDisplayVersion -v

5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED

Name: WebSphere MQ File Transfer Edition Server

Version: 7.0.4.3

Level: f704-FP3-20130429-1711

Platform: Linux (2.6.32-358.11.1.el6.s390x)

Architecture: s390

JVM: JRE 1.6.0 IBM J9 2.4 Linux s390-31
jvmxz3160sr12-20121024_126067 (JIT enabled, AOT enabled)

J9VM - 20121024_126067

JIT - r9_20120914_26057

GC - 20120928_AA

Product: /opt/ibm/WMQFTE

Configuration: /var/ibm/WMQFTE/config

WebSphere MQ Components:

Name: Common Services for Java Platform, Standard Edition

Version: 7.0.1.9

Level: k701-109-120705

$

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Brumbaugh Glen
Sent: Thursday, July 25, 2013 17:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

T-Rob,

As you know, being in the mqm group does not provide any OAM rights. Most
of these rights are assumed by user's to exist because of the sticky bits
set on the binaries (e.g. runmqsc).

What is the Sticky Bit in MFT for the executable? Is the executable NFS
mounted?

If you explicitly grant the necessary rights to your User ID do you still
have the same problem?

There is a similar issue that you and I worked on for Message Broker using
WMQ 7.5. There is an associated Technote 1442991. I know that you are
aware of this but I include it for everyone on the list.

With that as background, I have frequently encountered files that are
"owned" as the User ID "Unknown" when things were not set up correctly on
NFS mounts. Could this be a combination of the Sticky Bit behavior and and
a NFS mount issue?

Regards,

Glen Brumbaugh

Technology Manager
Prolifics

Global Technology Solutions Provider

On Jul 25, 2013, at 4:47 PM, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org> wrote:

I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 15:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to

remember

him saying here or on MQSeries.net that for reasons I can't remember the
JVM won't have a reliable ID to use, so it sends none, so you are getting

the

ID of Unknown. The C language does not have that problem as the real ID
the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might
have some insight into what's going on. When I run fteListAgents in
bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-
1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it
shows the ID connecting as "UNKNOWN." However, when I use the same
account to run amqsput and amqsget it works just fine. Is there something
in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long.
But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS
RESERVED
BFGCL0033E: A messaging problem prevented the command from
completing successfully. The WebSphere MQ completion code was 2, and
the reason code was 2035. A connection could not be established to queue
manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSPUT0 start target queue is
SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no
more messages Sample AMQSGET0 end $

_____

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

2013-07-26 19:51:41 UTC

Permalink

Ok, I misunderstood. I thought you had written a separate C test stub program to test the functions that were failing, to see if they also failed with the test stub.

The only other suggestion I have is running an strace on the C sample program that works and the FTE process that does not. I have found that helpful in the past with debugging these types of issues on Linux/UNIX, especially when you can compare something that is working with something that is not.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, July 26, 2013 11:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi Tim,

My testing was by using several things other than WMQ FTE to connect to MQ. It's WMQ making the getpwuid or getpwuir_r call and I'm just assuming that it would make the same call regardless of what connects to it. It seems pretty straightforward to first get the UID of the process, then walk the group entries and that it would do the same procedure for any type of connection. However, FTE may have access to some privileged API calls. I remember a while back when FTE 7.0.1 didn't work with WMQ 7.0.1 (http://www-01.ibm.com/support/docview.wss?uid=swg1IC62582) in bindings mode and am wondering if this is a regression or similar problem.

Thanks - T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Friday, July 26, 2013 11:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi T.Rob,

I noticed you said you tested a getpwuid call. Did you also test a getpwuid_r call? It looks like a getpwuid_r call was failing in that FDC, instead of a getpwuid call.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, July 26, 2013 8:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

Hi Glen,

Been doing some more testing and verification.

* This is all local bindings mode. The Command and Coordination QMgrs are the same and none of the properties files has a client channel specified.

* No NFS involved. Executables are on dedicated SAN LUN.

* In addition to being able to run the C samples, I can run the IVTRun program so the WMQ JMS classes work.

* The executables in the FTE bin directory do not have any setuid bits set and are world-executable.

* The samples I'm using as my control test (amwqsget and amqsput) also do not have any setuid bits set and are world-executable.

Additionally, the issues with OAM you describe are further down the stack than this call is getting. Here's the relevant bits from FDC:

| Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred. |
| FDCSequenceNumber :- 0 |
| Comment1 :- xcsGetpwuid failed to get password entry for process |
| with real uid 10211. |
| Comment2 :- Details: getuid() returned 10211; getpwuid_r(10211) |
| failed with errno=0. |
| Comment3 :- A user name of "UNKNOWN" will be used, which will |
| likely cause later authorisation failures. Note this FFST can be turned |
| off by exporting env var AMQ_NOFFST_PROCESS_UID. |

The FDC is cut under my ID rather than "UNKNOWN." The getuid() and getpwuid() calls appear to work in the test C code and IVT program, assuming these make the same OS API call as FTE.

I'm thinking this might be an FTE bug since it doesn't present anywhere but FTE. Unless the list has any other suggestions, I'm going to ask my client to open a PMR.

Thanks - T.Rob

$ dspmqver
Name: WebSphere MQ
Version: 7.1.0.2
Level: p710-002-121018
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Linux (zSeries 64-bit platform)
Mode: 64-bit
O/S: Linux 2.6.32-358.11.1.el6.s390x
InstName: Installation1
InstDesc:
InstPath: /opt/mqm
DataPath: /var/mqm
Primary: Yes
MaxCmdLevel: 711
$ fteDisplayVersion -v
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
Name: WebSphere MQ File Transfer Edition Server
Version: 7.0.4.3
Level: f704-FP3-20130429-1711
Platform: Linux (2.6.32-358.11.1.el6.s390x)
Architecture: s390
JVM: JRE 1.6.0 IBM J9 2.4 Linux s390-31 jvmxz3160sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT - r9_20120914_26057
GC - 20120928_AA
Product: /opt/ibm/WMQFTE
Configuration: /var/ibm/WMQFTE/config

WebSphere MQ Components:

Name: Common Services for Java Platform, Standard Edition
Version: 7.0.1.9
Level: k701-109-120705
$

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Brumbaugh Glen
Sent: Thursday, July 25, 2013 17:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

T-Rob,

As you know, being in the mqm group does not provide any OAM rights. Most of these rights are assumed by user's to exist because of the sticky bits set on the binaries (e.g. runmqsc).
What is the Sticky Bit in MFT for the executable? Is the executable NFS mounted?
If you explicitly grant the necessary rights to your User ID do you still have the same problem?
There is a similar issue that you and I worked on for Message Broker using WMQ 7.5. There is an associated Technote 1442991. I know that you are aware of this but I include it for everyone on the list.

With that as background, I have frequently encountered files that are "owned" as the User ID "Unknown" when things were not set up correctly on NFS mounts. Could this be a combination of the Sticky Bit behavior and and a NFS mount issue?

Regards,

Glen Brumbaugh
Technology Manager
Prolifics
Global Technology Solutions Provider
On Jul 25, 2013, at 4:47 PM, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>> wrote:

I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?
-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 15:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to
remember
him saying here or on MQSeries.net<http://MQSeries.net> that for reasons I can't remember the
JVM won't have a reliable ID to use, so it sends none, so you are getting
the
ID of Unknown. The C language does not have that problem as the real ID
the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might
have some insight into what's going on. When I run fteListAgents in
bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-
1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it
shows the ID connecting as "UNKNOWN." However, when I use the same
account to run amqsput and amqsget it works just fine. Is there something
in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long.
But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS
RESERVED
BFGCL0033E: A messaging problem prevented the command from
completing successfully. The WebSphere MQ completion code was 2, and
the reason code was 2035. A connection could not be established to queue
manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSPUT0 start target queue is
SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no
more messages Sample AMQSGET0 end $

________________________________
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

2013-07-28 03:44:47 UTC

Permalink

Hi T.Rob,

I had one other idea about this issue. The getpwuid_r is searching the password database (i.e. /etc/passwd file, LDAP, etc.) and the 0 return code is saying the id was not found. If the 10211 user id does exist locally on the /etc/passwd file, you might be encountering an issue where an earlier record before the 10211 id is corrupted or has a bad character which is causing the getpwuid_r function to not find the 10211 record in the /etc/passwd file. I have seen something similar happen with a poorly formatted record in the /etc/group file, which caused MQ to miss later group records when it was parsing the /etc/group file with the getgrent function.

Anyway, it might be worth checking. You can use the "od -c /etc/passwd" command (octal dump) to help see if there is a record with a bad format.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Friday, July 26, 2013 2:52 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Ok, I misunderstood. I thought you had written a separate C test stub program to test the functions that were failing, to see if they also failed with the test stub.

The only other suggestion I have is running an strace on the C sample program that works and the FTE process that does not. I have found that helpful in the past with debugging these types of issues on Linux/UNIX, especially when you can compare something that is working with something that is not.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, July 26, 2013 11:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi Tim,

My testing was by using several things other than WMQ FTE to connect to MQ. It's WMQ making the getpwuid or getpwuir_r call and I'm just assuming that it would make the same call regardless of what connects to it. It seems pretty straightforward to first get the UID of the process, then walk the group entries and that it would do the same procedure for any type of connection. However, FTE may have access to some privileged API calls. I remember a while back when FTE 7.0.1 didn't work with WMQ 7.0.1 (http://www-01.ibm.com/support/docview.wss?uid=swg1IC62582) in bindings mode and am wondering if this is a regression or similar problem.

Thanks - T.Rob

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Friday, July 26, 2013 11:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Hi T.Rob,

I noticed you said you tested a getpwuid call. Did you also test a getpwuid_r call? It looks like a getpwuid_r call was failing in that FDC, instead of a getpwuid call.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Friday, July 26, 2013 8:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

Hi Glen,

Been doing some more testing and verification.

* This is all local bindings mode. The Command and Coordination QMgrs are the same and none of the properties files has a client channel specified.

* No NFS involved. Executables are on dedicated SAN LUN.

* In addition to being able to run the C samples, I can run the IVTRun program so the WMQ JMS classes work.

* The executables in the FTE bin directory do not have any setuid bits set and are world-executable.

* The samples I'm using as my control test (amwqsget and amqsput) also do not have any setuid bits set and are world-executable.

Additionally, the issues with OAM you describe are further down the stack than this call is getting. Here's the relevant bits from FDC:

| Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred. |
| FDCSequenceNumber :- 0 |
| Comment1 :- xcsGetpwuid failed to get password entry for process |
| with real uid 10211. |
| Comment2 :- Details: getuid() returned 10211; getpwuid_r(10211) |
| failed with errno=0. |
| Comment3 :- A user name of "UNKNOWN" will be used, which will |
| likely cause later authorisation failures. Note this FFST can be turned |
| off by exporting env var AMQ_NOFFST_PROCESS_UID. |

The FDC is cut under my ID rather than "UNKNOWN." The getuid() and getpwuid() calls appear to work in the test C code and IVT program, assuming these make the same OS API call as FTE.

I'm thinking this might be an FTE bug since it doesn't present anywhere but FTE. Unless the list has any other suggestions, I'm going to ask my client to open a PMR.

Thanks - T.Rob

$ dspmqver
Name: WebSphere MQ
Version: 7.1.0.2
Level: p710-002-121018
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Linux (zSeries 64-bit platform)
Mode: 64-bit
O/S: Linux 2.6.32-358.11.1.el6.s390x
InstName: Installation1
InstDesc:
InstPath: /opt/mqm
DataPath: /var/mqm
Primary: Yes
MaxCmdLevel: 711
$ fteDisplayVersion -v
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
Name: WebSphere MQ File Transfer Edition Server
Version: 7.0.4.3
Level: f704-FP3-20130429-1711
Platform: Linux (2.6.32-358.11.1.el6.s390x)
Architecture: s390
JVM: JRE 1.6.0 IBM J9 2.4 Linux s390-31 jvmxz3160sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT - r9_20120914_26057
GC - 20120928_AA
Product: /opt/ibm/WMQFTE
Configuration: /var/ibm/WMQFTE/config

WebSphere MQ Components:

Name: Common Services for Java Platform, Standard Edition
Version: 7.0.1.9
Level: k701-109-120705
$

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Brumbaugh Glen
Sent: Thursday, July 25, 2013 17:39 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

T-Rob,

As you know, being in the mqm group does not provide any OAM rights. Most of these rights are assumed by user's to exist because of the sticky bits set on the binaries (e.g. runmqsc).
What is the Sticky Bit in MFT for the executable? Is the executable NFS mounted?
If you explicitly grant the necessary rights to your User ID do you still have the same problem?
There is a similar issue that you and I worked on for Message Broker using WMQ 7.5. There is an associated Technote 1442991. I know that you are aware of this but I include it for everyone on the list.

With that as background, I have frequently encountered files that are "owned" as the User ID "Unknown" when things were not set up correctly on NFS mounts. Could this be a combination of the Sticky Bit behavior and and a NFS mount issue?

Regards,

Glen Brumbaugh
Technology Manager
Prolifics
Global Technology Solutions Provider
On Jul 25, 2013, at 4:47 PM, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org<mailto:***@IOPTCONSULTING.COM>> wrote:

I know that's the case with client-connected things, but this is bindings
mode. My understanding was WMQ gets the ID from the process table in that
case, right?
-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 15:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to
remember
him saying here or on MQSeries.net<http://MQSeries.net> that for reasons I can't remember the
JVM won't have a reliable ID to use, so it sends none, so you are getting
the
ID of Unknown. The C language does not have that problem as the real ID
the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might
have some insight into what's going on. When I run fteListAgents in
bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-
1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it
shows the ID connecting as "UNKNOWN." However, when I use the same
account to run amqsput and amqsget it works just fine. Is there something
in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long.
But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS
RESERVED
BFGCL0033E: A messaging problem prevented the command from
completing successfully. The WebSphere MQ completion code was 2, and
the reason code was 2035. A connection could not be established to queue
manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSPUT0 start target queue is
SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME
OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no
more messages Sample AMQSGET0 end $

________________________________
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

Maryellen Evans

2013-07-25 19:02:41 UTC

Permalink

Start with the account and contact info and then I will explain the opportunity info

Best Regards,

M. Ariel Evans
Managing Director
(o) 425-605-6358
(m) 203.644.4916
mevans-***@public.gmane.org
www.evansresourcegroup.com

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 12:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to remember him saying here or on MQSeries.net that for reasons I can't remember the JVM won't have a reliable ID to use, so it sends none, so you are getting the ID of Unknown. The C language does not have that problem as the real ID the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might have some insight into what's going on. When I run fteListAgents in bindings mode, under my ID, which is in the mqm group, I get a 2035 Type-1 CONN NOT AUTHORIZED. When I use MS0P to view the event messages it shows the ID connecting as "UNKNOWN." However, when I use the same account to run amqsput and amqsget it works just fine. Is there something in FTE or in Java that causes this?

I know that UNKNOWN is what gets returned when a user ID is too long. But what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
BFGCL0033E: A messaging problem prevented the command from completing successfully. The WebSphere MQ completion code was 2, and the reason code was 2035. A connection could not be established to queue manager [NAME OF COORD QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR] Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE Hello world!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR] Sample AMQSGET0 start message <Hello world!> no more messages Sample AMQSGET0 end $

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
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

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

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

Dominique Courtois

2013-07-25 21:56:21 UTC

Permalink

Glen,
I am sorry because this is a detail not MQ related.
I guess you are not meaning "sticky bit" but "set user-id/group bit" which
is a quite different thing. Actually the sticky bit was useful long, long ago.
Regards
Dominique

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

Brumbaugh Glen

2013-07-25 23:32:30 UTC

Permalink

Dominique,

This is actually an essential WMQ detail. Many users of WMQ do not actually understand how the WMQ OAM actually works. Being a member of the "mqm" Group does not provide any authorization grants within the OAM. Almost all user experience with WMQ has been based upon the actual rights of the "mqm" User ID. The rights under this ID were provided by the Sticky Bit containing a value for UID (User ID) and, yes, on this side of the pond we often generically to the first octet of the chmod command as the "sticky bit" (I know that a "bit" with 8 values does not make a lot of sense). The only reason that any WMQ admin has had any access to WMQ is because the UID was set for the executable files. This can easily be verified by turning this bit off on the runmqsc program and seeing what happens.

In a discussion with a member of the WMQ development team, it was stated that the lab was considering removing the UID settings. The direction was to force WMQ users to explicitly grant the necessary access rights. The use of the UID for the executables has masked the issue of their not actually being more granular rights assigned. If the lab follows through, this will be a big change in the WMQ experience for all of us; but not an actual change in the OAM behavior.

The relationship of all of this with T-Rob's problem is that IF the UID was set for the WMQ MFT executable AND that executable was in an improperly configured NFS mount he would experience the systems he describes. I have experienced this exact symptom with an NFS mount of /opt/mqm/bin that was improperly done, so it can happen.

l

Regards,

Glen Brumbaugh
Technology Manager
Prolifics
Global Technology Solutions Provider

Post by Dominique Courtois
Glen,
I am sorry because this is a detail not MQ related.
I guess you are not meaning "sticky bit" but "set user-id/group bit" which
is a quite different thing. Actually the sticky bit was useful long, long ago.
Regards
Dominique
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

Dominique Courtois

2013-07-26 09:34:16 UTC

Permalink

Glen,
I really think that there is a great deal of confusion in your post.

1- as far as my previous message is concerned you did not correct the common mistake between "sticky bit" and "est user or group id bit". You seem to be still mistaking. Any decent Unix documentation will show the difference between the two. Once again this (the difference between the various Unix permission bits) is a detail with respect to WMQ.

2-I will not elaborate on the key points : How the OAM works and what belongs to WMQ (OAM) domain and what belongs to the system domain (for instance the set user-id bit stuff) but I desagree on almost everything.

Regards
Dominique

----- Mail original -----
De: "Brumbaugh Glen" <glen.brumbaugh-***@public.gmane.org>
À: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Envoyé: Vendredi 26 Juillet 2013 01:32:30
Objet: Re: Weird 2035 with FTE

Dominique,

This is actually an essential WMQ detail. Many users of WMQ do not actually understand how the WMQ OAM actually works. Being a member of the "mqm" Group does not provide any authorization grants within the OAM. Almost all user experience with WMQ has been based upon the actual rights of the "mqm" User ID. The rights under this ID were provided by the Sticky Bit containing a value for UID (User ID) and, yes, on this side of the pond we often generically to the first octet of the chmod command as the "sticky bit" (I know that a "bit" with 8 values does not make a lot of sense). The only reason that any WMQ admin has had any access to WMQ is because the UID was set for the executable files. This can easily be verified by turning this bit off on the runmqsc program and seeing what happens.

In a discussion with a member of the WMQ development team, it was stated that the lab was considering removing the UID settings. The direction was to force WMQ users to explicitly grant the necessary access rights. The use of the UID for the executables has masked the issue of their not actually being more granular rights assigned. If the lab follows through, this will be a big change in the WMQ experience for all of us; but not an actual change in the OAM behavior.

The relationship of all of this with T-Rob's problem is that IF the UID was set for the WMQ MFT executable AND that executable was in an improperly configured NFS mount he would experience the systems he describes. I have experienced this exact symptom with an NFS mount of /opt/mqm/bin that was improperly done, so it can happen.

l

Regards,

Glen Brumbaugh
Technology Manager
Prolifics
Global Technology Solutions Provider

On Jul 25, 2013, at 5:56 PM, Dominique Courtois < dominic77-***@public.gmane.org > wrote:

Glen,
I am sorry because this is a detail not MQ related.
I guess you are not meaning "sticky bit" but "set user-id/group bit" which
is a quite different thing. Actually the sticky bit was useful long, long ago.
Regards
Dominique

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

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

Maryellen Evans

2013-07-26 15:03:11 UTC

Permalink

Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [162.211.217.85]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.26.144517
X-PMX-Spam: Gauge= Probability=9%, Report='
AT_TLD 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CANPHARM_COPYRIGHT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_XOIP 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NS '

Apologies List Servers...

Replied to wrong email.

Best Regards,

M. Ariel Evans
Managing Director
(o) 425-605-6358
(m) 203.644.4916
mevans-***@public.gmane.org
www.evansresourcegroup.com

-----Original Message-----
From: Maryellen Evans=20
Sent: Thursday, July 25, 2013 12:03 PM
To: 'MQSeries List'
Subject: RE: Weird 2035 with FTE

Start with the account and contact info and then I will explain the opportu=
nity info

Best Regards,

M. Ariel Evans
Managing Director
(o) 425-605-6358
(m) 203.644.4916
mevans-***@public.gmane.org
www.evansresourcegroup.com

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf O=
f Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, July 25, 2013 12:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Weird 2035 with FTE

Jeff will be along shortly to confirm / correct this, but I seem to remembe=
r him saying here or on MQSeries.net that for reasons I can't remember the =
JVM won't have a reliable ID to use, so it sends none, so you are getting t=
he ID of Unknown. The C language does not have that problem as the real ID =
the process runs under is used.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf O=
f T.Rob
Sent: Thursday, July 25, 2013 1:46 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Weird 2035 with FTE

Hi folks,

I'm seeing some weird behavior in FTE and was hoping someone else might hav=
e some insight into what's going on. When I run fteListAgents in bindings =
mode, under my ID, which is in the mqm group, I get a 2035 Type-1 CONN NOT =
AUTHORIZED. When I use MS0P to view the event messages it shows the ID con=
necting as "UNKNOWN." However, when I use the same account to run amqsput =
and amqsget it works just fine. Is there something in FTE or in Java that =
causes this?

I know that UNKNOWN is what gets returned when a user ID is too long. But =
what would cause it to work under WMQ C code but fail under Java?

Thanks -- T.Rob

$ fteListAgents
5655-U80, 5724-R10 Copyright IBM Corp. 2008, 2011. ALL RIGHTS RESERVED
BFGCL0033E: A messaging problem prevented the command from completing succe=
ssfully. The WebSphere MQ completion code was 2, and the reason code was 20=
35. A connection could not be established to queue manager [NAME OF COORD =
QMGR].
$ /opt/mqm/samp/bin/amqsput SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR]=
Sample AMQSPUT0 start target queue is SYSTEM.DEFAULT.LOCAL.QUEUE Hello wor=
ld!

Sample AMQSPUT0 end
$ /opt/mqm/samp/bin/amqsget SYSTEM.DEFAULT.LOCAL.QUEUE [NAME OF COORD QMGR]=
Sample AMQSGET0 start message <Hello world!> no more messages Sample AMQSG=
ET0 end $

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the mes=
sage body (not the subject), write: SIGNOFF MQSERIES Instructions for manag=
ing your mailing list subscription are provided in the Listserv General Use=
rs Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addr=
essee and may contain proprietary, confidential and/or privileged informati=
on. If you are not the intended recipient, any use, copying, disclosure, d=
issemination or distribution is strictly prohibited. If you are not the in=
tended recipient, please notify the sender immediately by return e-mail, de=
lete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the mes=
sage body (not the subject), write: SIGNOFF MQSERIES Instructions for manag=
ing your mailing list subscription are provided in the Listserv General Use=
rs 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