Re: MQClient getting persistent messages - Chance of duplicate pr ocessing?

[Potkay, Peter M (PLC, IT)]

Would the backout count of the message go up by one in this specific case?
(the QM/server crashes while a client has the message in syncpoint) I have
tested and coded apps to take advantage of this field, but its always been
because the app rolled back the message, or the app abended. I've never
attempted the other way around. Will the QM be good enough to up the backout
count before the QM/server goes down? Or as its coming back up? Or at all?


Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906


-Original Message-
From: Miller, Dennis [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 6:23 PM
To: [EMAIL PROTECTED]
Subject: Re: MQClient getting persistent messages - Chance of duplicate
pr oces sing?


If the commit was never done, then the message certainly will still be
there. I'd say it's documented in so many words, as that's more or less the
essence of syncpoint control. The client does need to compensate for this,
but undoing everything is not the only game in town. Sometimes you can just
process the message twice, throw the duplicate away, or let it expire on the
queue--it's very application dependent.

But that begs the question of how to reliably determine if the commit
actually finished. A bad RC is inconclusive!  For example, the
server/network might fail after the commit and never deliver the positive
response. You get 2009 or some such thing, but everything's fine on the
server. Since the negative RC is ambiguous, I think it best not to rely on
it.  Bad RC's on the MQCMIT should rarely occur. But in the case one does,
I'd be inclined to let the rest of the processing stand and find a scheme to
ignore/tolerate/discard the duplicate message

> -Original Message-
> From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, July 12, 2002 12:43 PM
> To:   [EMAIL PROTECTED]
> Subject:  MQClient getting persistent messages - Chance of duplicate
> proces sing?
>
> QM1 has Q1, a triggered on first queue. A remote application puts
> persistent
> message to this queue, causing an MQClient app on another machine to start
> up and connect to QM1, open Q1 and get the message under syncpoint. While
> the client is processing the message, the server housing QM1 goes down.
> Meanwhile the client finishes processing the message and goes to close and
> disconnect, only to find the QM not there anymore.
>
> What happened to that message? It was persistent and gotten under
> syncpoint,
> but a commit (either implicit or explicit) was never done. Will it be
> there
> when the QM comes back up? And will the client app have to be coded to
> handle duplicate messages?
>
> If the message will be there, is this a documented feature? In other words
> could/should the client code say unless I get a good RC on my MQCMIT or my
> MQDISC call, I assume all messages in this UOW will be there again, so
> undo
> everything I just did to avoid duplicates?
>
> Peter Potkay
> IBM MQSeries Certified Specialist, Developer
> [EMAIL PROTECTED]
> X 77906
>
>
>
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all
> copies.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security - SSL

[Brian S. Crabtree]

Philip

See Morag Hughson's posts in this thread

According to the manual SSL provides all the security features that you will
ever need

Secure Sockets Layer in WebSphere MQ
Message channels and MQI channels can use the SSL protocol to provide link
level security. A caller MCA is an SSL client and a responder MCA is an SSL
server.

> Does SSL provide authentication security for JMS or JAVA applications ?  I
> don't believe so.

The docs say that you can do it - I havent delved deeply enough to find the
specifics on setting up JMS/SSL support but it is in there somewhere

Brian S. Crabtree
EAI Consultant

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 6:09 PM
Subject: Re: MQSeries Client Security - SSL


> Does SSL provide authentication security for JMS or JAVA applications ?  I
> don't believe so.
>
>
>
>
>
>   pavel.tolkachev@ To:
[EMAIL PROTECTED]
>   DB.COM   cc:
>   Sent by: Subject: Re: MQSeries
Client Security - SSL
>   MQSERIES@akh-wie
>   n.ac.at
>
>
>   07/12/2002 09:55
>   AM
>   Please respond
>   to MQSERIES
>
>
>
>
>
> Yes, please! :-)
>
> Or if there is no document readily available, can someone who knows 5.3
> share his or her knowledge about the following:
>
> 1. Is it possible to configure server end of the client channel to
> authenticate different identities based on MCAUSER field? Other fields? I
> mean: to be really useful SSL channel security should be integrated with
MQ
> user name-based or group name-based access control architecture. I do not
> think the anonymous clients are really useful in secure environment unless
> you want to allow a separate port and channel process for each user or
> administrative group.
>
> 2. How do I configure the client end for SSL? Is this new API, new
> configuration file or what? Can I configure different identities on same
> client machine? Different identities for same user name on different
> machines? (e.g. user1@host1 and user1@host2 to have different identities
> and therefore different rights)? My client and server platforms of
interest
> are NT, Solaris, AIX, Linux.
>
> Thank you in advance,
> Pavel
>
>
>
>
>
>   "Garcia Rich
>   (SYS1RXG)"   To:
> [EMAIL PROTECTED]
>   <[EMAIL PROTECTED]>cc:
>   Sent by: MQSeriesSubject:  Re: MQSeries
> Client Security - SSL
>   List
>  n.AC.AT>
>
>
>   07/12/2002 09:02
>   AM
>   Please respond to
>   MQSeries List
>
>
>
>
>
>
> Is this security manual which you are referring too available now or is it
> 5.3 if it is can you please pass the link.
>
> Thank you
>
> -Original Message-
> From: Morag Hughson [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 12, 2002 4:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: MQSeries Client Security - SSL
>
>
> SSL allows you to authenticate the parties concerned. Each queue manager
or
> client log-on gets a digital certificate, and these certificates are
> authenticated when a channel, using SSL, is started between two queue
> managers, or between a client and queue manager (you can choose to only
> authenticate the responding end of the channel if you wish, allowing you
to
> effectively have anonymous initiators or clients). Once authentication has
> been completed a secret key is set up to use to do encryption for the
> lifetime of that channel instance.
>
> There's more information about SSL in the new Security Manual.
>
> Cheers
> Morag
>
> Morag Hughson
> WebSphere MQ for z/OS Development
> Internet: [EMAIL PROTECTED]
>
>
>
>
>   Tony Reddiough
>[EMAIL PROTECTED]
>   ACOURT.COM> cc:
>   Sent by: MQSeries   Subject:  Re: MQSeries
> Client Security
>   List
>   <[EMAIL PROTECTED]
>   C.AT>
>
>
>   12/07/2002 08:59
>   Please respond to
>   MQSeries List
>
>
>
>
>
> James,
>  I haven't got my hands on 5.3 yet.  I know it adds SSL
but
> I thought this was only for encryption.  Does it help with authentication
> as
> well ?
>
> I'd be interested in retrying my testing with 5.3 in that case.
>
> Thanks,
> Tony.
>
> Tony Reddiough
> Certified MQSeries Specialist
> Tel:   +44 (0) 1793 616100
> Mobile:  +44 (0) 7711 264281
> www.alphacourt.com 
>
> Alphacourt - "The Integration Practice"
>
>
> -Original Message-
> From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behal

TXSeries CICS and MQ under AIX

[Tony Devitt]

Is there any manual that describes how the CICS regions and/or transactions
interact with a queue manager on an AIX machine.  I have searched through
the manuals I can think of but have not found what I am looking for...along
the lines of the CICS Adapter chapter in the O/390 MQ SysAdm Guide.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Guillaume Delvallez/France/IBM is out of the office.

[Guillaume Delvallez]

I will be out of the office starting July 13, 2002 and will not return
until August 11, 2002.

I will respond to your message when I return.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: List server

[Brian S. Crabtree]

Nushin

Don Golding already commented on this on 7/5

>Anybody notice that this got cut off by the list server on the 21st June?
This
>one's still working though:

>http://www.mail-archive.com/mqseries%40akh-wien.ac.at/index.html

There was a message from the listserver saying that messageq.com had been
unsubscribed for refusing too many emails but that message seems to have
disappeared

You can always contact messageq.com and ask them to fix it - these service
disruptions seem to happen every year on messageq.com

Brian S. Crabtree
EAI Consultant

- Original Message -
From: "nushin mehran" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 6:38 PM
Subject: List server


> Hello all,
> Can some body tell me why I am not able to see items
> in listServer after June 20, 2002 ?.
> The link that I am using is
> http://www.messageq.com/forums/vienna/
>
> Thanks a lot.
>
> __
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

List server

[nushin mehran]

Hello all,
Can some body tell me why I am not able to see items
in listServer after June 20, 2002 ?.
The link that I am using is
http://www.messageq.com/forums/vienna/

Thanks a lot.

__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQClient getting persistent messages - Chance of duplicate pr oces sing?

[Miller, Dennis]

If the commit was never done, then the message certainly will still be
there. I'd say it's documented in so many words, as that's more or less the
essence of syncpoint control. The client does need to compensate for this,
but undoing everything is not the only game in town. Sometimes you can just
process the message twice, throw the duplicate away, or let it expire on the
queue--it's very application dependent.

But that begs the question of how to reliably determine if the commit
actually finished. A bad RC is inconclusive!  For example, the
server/network might fail after the commit and never deliver the positive
response. You get 2009 or some such thing, but everything's fine on the
server. Since the negative RC is ambiguous, I think it best not to rely on
it.  Bad RC's on the MQCMIT should rarely occur. But in the case one does,
I'd be inclined to let the rest of the processing stand and find a scheme to
ignore/tolerate/discard the duplicate message

> -Original Message-
> From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, July 12, 2002 12:43 PM
> To:   [EMAIL PROTECTED]
> Subject:  MQClient getting persistent messages - Chance of duplicate
> proces sing?
>
> QM1 has Q1, a triggered on first queue. A remote application puts
> persistent
> message to this queue, causing an MQClient app on another machine to start
> up and connect to QM1, open Q1 and get the message under syncpoint. While
> the client is processing the message, the server housing QM1 goes down.
> Meanwhile the client finishes processing the message and goes to close and
> disconnect, only to find the QM not there anymore.
>
> What happened to that message? It was persistent and gotten under
> syncpoint,
> but a commit (either implicit or explicit) was never done. Will it be
> there
> when the QM comes back up? And will the client app have to be coded to
> handle duplicate messages?
>
> If the message will be there, is this a documented feature? In other words
> could/should the client code say unless I get a good RC on my MQCMIT or my
> MQDISC call, I assume all messages in this UOW will be there again, so
> undo
> everything I just did to avoid duplicates?
>
> Peter Potkay
> IBM MQSeries Certified Specialist, Developer
> [EMAIL PROTECTED]
> X 77906
>
>
>
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all
> copies.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security - SSL

[philip . distefano]

Does SSL provide authentication security for JMS or JAVA applications ?  I
don't believe so.





  pavel.tolkachev@ To:  [EMAIL PROTECTED]
  DB.COM   cc:
  Sent by: Subject: Re: MQSeries Client Security - 
SSL
  MQSERIES@akh-wie
  n.ac.at


  07/12/2002 09:55
  AM
  Please respond
  to MQSERIES





Yes, please! :-)

Or if there is no document readily available, can someone who knows 5.3
share his or her knowledge about the following:

1. Is it possible to configure server end of the client channel to
authenticate different identities based on MCAUSER field? Other fields? I
mean: to be really useful SSL channel security should be integrated with MQ
user name-based or group name-based access control architecture. I do not
think the anonymous clients are really useful in secure environment unless
you want to allow a separate port and channel process for each user or
administrative group.

2. How do I configure the client end for SSL? Is this new API, new
configuration file or what? Can I configure different identities on same
client machine? Different identities for same user name on different
machines? (e.g. user1@host1 and user1@host2 to have different identities
and therefore different rights)? My client and server platforms of interest
are NT, Solaris, AIX, Linux.

Thank you in advance,
Pavel





  "Garcia Rich
  (SYS1RXG)"   To:
[EMAIL PROTECTED]
  <[EMAIL PROTECTED]>cc:
  Sent by: MQSeriesSubject:  Re: MQSeries
Client Security - SSL
  List
  


  07/12/2002 09:02
  AM
  Please respond to
  MQSeries List






Is this security manual which you are referring too available now or is it
5.3 if it is can you please pass the link.

Thank you

-Original Message-
From: Morag Hughson [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 4:53 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security - SSL


SSL allows you to authenticate the parties concerned. Each queue manager or
client log-on gets a digital certificate, and these certificates are
authenticated when a channel, using SSL, is started between two queue
managers, or between a client and queue manager (you can choose to only
authenticate the responding end of the channel if you wish, allowing you to
effectively have anonymous initiators or clients). Once authentication has
been completed a secret key is set up to use to do encryption for the
lifetime of that channel instance.

There's more information about SSL in the new Security Manual.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  Tony Reddiough
   cc:
  Sent by: MQSeries   Subject:  Re: MQSeries
Client Security
  List
  <[EMAIL PROTECTED]
  C.AT>


  12/07/2002 08:59
  Please respond to
  MQSeries List





James,
 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication
as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided
>in the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com
Archive: ht

Re: MQClient getting persistent messages - Chance of duplicate pr oces sing?

[Hill, Dave]

Peter-
As I understand in Client channels the MSG's are not assured. This has been
my experience anyway.
Dave

-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 3:43 PM
To: [EMAIL PROTECTED]
Subject: MQClient getting persistent messages - Chance of duplicate
proces sing?


QM1 has Q1, a triggered on first queue. A remote application puts persistent
message to this queue, causing an MQClient app on another machine to start
up and connect to QM1, open Q1 and get the message under syncpoint. While
the client is processing the message, the server housing QM1 goes down.
Meanwhile the client finishes processing the message and goes to close and
disconnect, only to find the QM not there anymore.

What happened to that message? It was persistent and gotten under syncpoint,
but a commit (either implicit or explicit) was never done. Will it be there
when the QM comes back up? And will the client app have to be coded to
handle duplicate messages?

If the message will be there, is this a documented feature? In other words
could/should the client code say unless I get a good RC on my MQCMIT or my
MQDISC call, I assume all messages in this UOW will be there again, so undo
everything I just did to avoid duplicates?

Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906



This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all
copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

MQClient getting persistent messages - Chance of duplicate proces sing?

[Potkay, Peter M (PLC, IT)]

QM1 has Q1, a triggered on first queue. A remote application puts persistent
message to this queue, causing an MQClient app on another machine to start
up and connect to QM1, open Q1 and get the message under syncpoint. While
the client is processing the message, the server housing QM1 goes down.
Meanwhile the client finishes processing the message and goes to close and
disconnect, only to find the QM not there anymore.

What happened to that message? It was persistent and gotten under syncpoint,
but a commit (either implicit or explicit) was never done. Will it be there
when the QM comes back up? And will the client app have to be coded to
handle duplicate messages?

If the message will be there, is this a documented feature? In other words
could/should the client code say unless I get a good RC on my MQCMIT or my
MQDISC call, I assume all messages in this UOW will be there again, so undo
everything I just did to avoid duplicates?

Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906



This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ on XP

[Jeff A Tressler]

>Has anyone installed MQ 5.2.1 on XP professional?
>Is there any new media for XP? I did not find any
>in the Websphere MQ link...
>
Windows XP is not a supported OS for MQSeries 5.2.1.

WebSphere MQ 5.3 is the first version to support
Windows XP.

Jeff Tressler

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ and Win2K load balancing w/ COM+

[Sreenivas.Checka]

We have done extensive testing of Application Center Component Load
Balancing (CLB) and Network Load Balancing in our Proof Of Concept
environment.  CLB works exactly as Peter Larson described.  We have not
tested the JIT concept.

As for the behavior of MQ, you are right in that your application has to
hold a reference to the COM+ object to ensure that you wait on a reply from
the node that put the message on initially.  If you lose the reference and
try to do a get later, you will end up possibly getting directed to another
node.


Can anyone share their experience with pure MQ load balancing on Windows
2000 servers.

Regards
Checka
Software Architect
314 923 6708
[EMAIL PROTECTED]


-Original Message-
From: Peter Larsson [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 7:07 AM
To: [EMAIL PROTECTED]
Subject: Re: MQ and Win2K load balancing w/ COM+


Hi Peter,

Don't know if this will be to any help for you or if it's just
noise..anyway here are my thoughts.

I haven't been involved in any dev regarding  App Center, but..
My understanding of Component Load Balancing, which is the feature that does
load-balancing of COM+ apps in App Center, is that it load-balances COM+
object creation. Which should mean that as long as
you're holding on to a object reference, it should be bound to the same
server hosting that object-instance.
This should be true even if your COM-classes use Just-In-Time activation ,
however as I mentioned I haven't used it !
So it COULD be that i.e. JIT-activated objects not are bound to the same
server for the object reference life-time, then you'll be stuck with using
objects that don't deactivate between method call's
and thereby kills scalability (at least as MS says).
After reading your posting I looked around on the MS Site and there weren't
any docs that clearly (deep tech) showed how it really works, but the text I
found stated that subsequent request for an
already created object should be routed to the same server.

Regards,
Peter Larsson




Peter Heggie
   cc:
Sent by: MQSeriesSubject: MQ and Win2K load
balancing w/ COM+
List



2002-07-11 21:04
Please respond to
MQSeries List






Has anyone gotten application load-balancing to work in a Windows
COM+/Application Center world? I'm thinking of a request/reply scenario,
where the replytoqueuemanager name is filled in dynamically, but the
application could be swapped between two machines..

Its hard for me to get a handle on the concepts - once an application calls
a COM+ component which performs MQ calls, will the application stay
connected to the same component (which is waiting for a reply)? Or is there
a chance that load balancing will move the application to a different
machine?

It seems to me that an application that performs a  Put (request), then a
Get (reply) w/Wait, will be fine.. but an application that performs the
Gets at a later time (disconnects and then later connects) runs the risk of
being load balanced to a different machine than the one where the reply may
be waiting.

If this is true, then application design will make or break the
request/reply process..

Peter

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Robert Broderick]

Yes that is all well and true. BUTMS still deserves to be hated!!


>From: "Miller, Dennis" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: MQSeries Client Security
>Date: Fri, 12 Jul 2002 10:36:47 -0700
>
>It's a curiosity (MS haters take note). Microsoft gets slammed for obscure
>holes in IE or IM, despite often delivering patches before the press hits
>the streets. Yet IBM manages to stave off solutions for years, passing off
>security caverns big enough to drive a truck through as "opportunities" for
>3rd party developers. Oh, I hope V5.3 takes care of this.
>
>But in the meantime, I've learned that if security is that important, you
>must add a layer in your application to do the dirty work. That's one of
>the
>reasons for promoting SIL designs--because they're a very natural place to
>take care of it. Maybe when IBM gets the client situation under wraps they
>can mobilize to address qmgr-qmgr connections and message-level security,
>as
>well.
>
> > -Original Message-
> > From: Tony Reddiough [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, July 11, 2002 10:21 AM
> > To:   [EMAIL PROTECTED]
> > Subject:  Re: MQSeries Client Security
> >
> > If you provide a userid (specified within the Java program itself) it
>will
> > be checked.  However, if you don't, Java cannot determine the signed on
> > userid and so passes nothing to the server.  In this case, the listener
> > has
> > to either reject the channel start request or simply let it through.
>IBM
> > chose to do the latter.  If you then look at the messages on the queue,
>in
> > the MQMD, you'll see the userid of the listener which is usually mqm or
> > MQUSR_ADMIN or something very powerful.
> >
> > Of course you cannot rely on Mr Hacker to specify his userid from within
> > his
> > Java program - he might not be that helpful !
> >
> > I successfully managed to put a message to the
>SYSTEM.DEFAULT.LOCAL.QUEUE
> > on
> > my clients production queue manager which he thought was well protected.
> > He
> > was not impressed !  Since then he has either deleted all SVRCONN
>channels
> > or disabled them by coding MCAUSER(wibble) where wibble has no
>authority.
> > This overrides all other userids but does mean everyone gets the same
> > treatment.
> >
> > I was pretty shocked when I discovered this but IBM thought it was
> > perfectly
> > acceptable.  They always recommend security exits anyway.
> >
> > Hope this helps,
> > Tony.
> >
> > Tony Reddiough
> > Certified MQSeries Specialist
> > Tel:   +44 (0) 1793 616100
> > Mobile:  +44 (0) 7711 264281
> > www.alphacourt.com 
> >
> > Alphacourt - "The Integration Practice"
> >
> >
> > -Original Message-
> > From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
> > Broderick
> > Sent: 11 July 2002 17:18
> > To: [EMAIL PROTECTED]
> > Subject: Re: MQSeries Client Security
> >
> >
> > I have a question. How does the JAVA client application bypass the
> > security
> > checking on the server. If the svrconn channel has blanks in the MCAUSER
> > attribute doesn't the server have to authenticate the userid in the
> > message
> > against the server. We have JAVA apps here and that seems the way they
> > perform. Am I missing something??
> >
> >bobbee
> >
> >
> > >From: Tony Reddiough <[EMAIL PROTECTED]>
> > >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: MQSeries Client Security
> > >Date: Thu, 11 Jul 2002 15:20:15 +0100
> > >
> > >Bill,
> > >  I recently discovered a "limitation" with client security on
> > the
> > >distributed platforms, not sure if it applies to OS/390 but I wouldn't
>be
> > >at
> > >all suprised.
> > >
> > >When a client attaches through the SVRCONN channel, the userid under
> > which
> > >the client application is running will be assumed by the server end
>(i.e.
> > >OS/390 in your case).  So, if you client is an win2000 application
> > running
> > >under userid "fred" then that user will be authenticated at the OS/390
>to
> > >make sure it can connect to the queue manager, put messages on the
> > specific
> > >queue etc.  So, the upshot is, you have to define "fred" to OS/390 and
> > >grant
> > >it permission to your queues.
> > >
> > >This is fine.  However, if the client application is written in Java,
>it
> > >manages to skip all this checking and can therefore access whatever it
> > >likes
> > >on your OS/390 queue manager.
> > >
> > >Ok, you say, my program isn't written in Java.  BUT you also have to
> > worry
> > >about the mallicious guy who is hacking in - his program might be
>written
> > >in
> > >java.
> > >
> > >Bottom line, all SVRCONN channels provide access to the queue manager
> > where
> > >they are defined without going through a securty check.  Since all
>queue
> > >managers define SYSTEM.DE



Re: MQSeries Client Security, (continued)


Re: MQSeries Client Security,
Jame

Re: MQ on XP

[Saar, Andrew]

Did you try creating a QM from the command line?  I've found that to be the most 
stable mechanism.

Andrew

-Original Message-
From: Edward Pius [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 1:42 PM
To: [EMAIL PROTECTED]
Subject: MQ on XP


Hello,

Has anyone installed MQ 5.2.1 on XP professional? Is there any new media for 
XP? I did not find any in the Websphere MQ link...

I tried installing 5.2.1 on XP. The install seems to succeed even though it 
seems to hang when I try to create a queue manager...

Edward Pius

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Any good Perl scripting examples around

[Jim Ford]

Here's a couple of truly simple Perl programs that we use on Unix. They use
the procedural interface, not the OO one, and are the equivalent of amqsget
and amqsput,

(See attached file: putter.pl)(See attached file: getter.pl)




  Ed Newbold
  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  OM>  cc:
  Sent by: MQSeriesSubject:  Any good Perl scripting 
examples around
  List
  


  07/12/2002 12:21
  PM
  Please respond to
  MQSeries List






I'm looking to get a fast-start on using Perl scripting to GET and/or PUT
messages into queues.  Does anyone have any good, more or less complete,
sample code available I could examine?

Thanks for your thoughts,
Ed Newbold
Columbus, OH


__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive





putter.pl
Description: Binary data


getter.pl
Description: Binary data

MQ on XP

[Edward Pius]

Hello,

Has anyone installed MQ 5.2.1 on XP professional? Is there any new media for 
XP? I did not find any in the Websphere MQ link...

I tried installing 5.2.1 on XP. The install seems to succeed even though it 
seems to hang when I try to create a queue manager...

Edward Pius

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Miller, Dennis]

It's a curiosity (MS haters take note). Microsoft gets slammed for obscure
holes in IE or IM, despite often delivering patches before the press hits
the streets. Yet IBM manages to stave off solutions for years, passing off
security caverns big enough to drive a truck through as "opportunities" for
3rd party developers. Oh, I hope V5.3 takes care of this.

But in the meantime, I've learned that if security is that important, you
must add a layer in your application to do the dirty work. That's one of the
reasons for promoting SIL designs--because they're a very natural place to
take care of it. Maybe when IBM gets the client situation under wraps they
can mobilize to address qmgr-qmgr connections and message-level security, as
well.

> -Original Message-
> From: Tony Reddiough [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, July 11, 2002 10:21 AM
> To:   [EMAIL PROTECTED]
> Subject:  Re: MQSeries Client Security
>
> If you provide a userid (specified within the Java program itself) it will
> be checked.  However, if you don't, Java cannot determine the signed on
> userid and so passes nothing to the server.  In this case, the listener
> has
> to either reject the channel start request or simply let it through.  IBM
> chose to do the latter.  If you then look at the messages on the queue, in
> the MQMD, you'll see the userid of the listener which is usually mqm or
> MQUSR_ADMIN or something very powerful.
>
> Of course you cannot rely on Mr Hacker to specify his userid from within
> his
> Java program - he might not be that helpful !
>
> I successfully managed to put a message to the SYSTEM.DEFAULT.LOCAL.QUEUE
> on
> my clients production queue manager which he thought was well protected.
> He
> was not impressed !  Since then he has either deleted all SVRCONN channels
> or disabled them by coding MCAUSER(wibble) where wibble has no authority.
> This overrides all other userids but does mean everyone gets the same
> treatment.
>
> I was pretty shocked when I discovered this but IBM thought it was
> perfectly
> acceptable.  They always recommend security exits anyway.
>
> Hope this helps,
> Tony.
>
> Tony Reddiough
> Certified MQSeries Specialist
> Tel:   +44 (0) 1793 616100
> Mobile:  +44 (0) 7711 264281
> www.alphacourt.com 
>
> Alphacourt - "The Integration Practice"
>
>
> -Original Message-
> From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
> Broderick
> Sent: 11 July 2002 17:18
> To: [EMAIL PROTECTED]
> Subject: Re: MQSeries Client Security
>
>
> I have a question. How does the JAVA client application bypass the
> security
> checking on the server. If the svrconn channel has blanks in the MCAUSER
> attribute doesn't the server have to authenticate the userid in the
> message
> against the server. We have JAVA apps here and that seems the way they
> perform. Am I missing something??
>
>bobbee
>
>
> >From: Tony Reddiough <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: MQSeries Client Security
> >Date: Thu, 11 Jul 2002 15:20:15 +0100
> >
> >Bill,
> >  I recently discovered a "limitation" with client security on
> the
> >distributed platforms, not sure if it applies to OS/390 but I wouldn't be
> >at
> >all suprised.
> >
> >When a client attaches through the SVRCONN channel, the userid under
> which
> >the client application is running will be assumed by the server end (i.e.
> >OS/390 in your case).  So, if you client is an win2000 application
> running
> >under userid "fred" then that user will be authenticated at the OS/390 to
> >make sure it can connect to the queue manager, put messages on the
> specific
> >queue etc.  So, the upshot is, you have to define "fred" to OS/390 and
> >grant
> >it permission to your queues.
> >
> >This is fine.  However, if the client application is written in Java, it
> >manages to skip all this checking and can therefore access whatever it
> >likes
> >on your OS/390 queue manager.
> >
> >Ok, you say, my program isn't written in Java.  BUT you also have to
> worry
> >about the mallicious guy who is hacking in - his program might be written
> >in
> >java.
> >
> >Bottom line, all SVRCONN channels provide access to the queue manager
> where
> >they are defined without going through a securty check.  Since all queue
> >managers define SYSTEM.DEFAULT.SVRCONN when they are created (and most
> >people don't delete them), I reckon I could put a message onto most queue
> >managers in the world unchallenged given access to the network.
> >
> >Bottom, bottom line, you need security exits !
> >
> >Tony Reddiough
> >Certified MQSeries Specialist
> >Alphacourt Limited
> >Tel:   +44 (0) 1793 616100
> >Mobile:  +44 (0) 7711 264281
> >www.alphacourt.com 
> >
> >Alphacourt - The Integration Practice
> >
> >
> >-Original Message-
> >From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf

Using GetEnvPlugIn (From IA06)

[Gary Weik]

Has anyone been able to get the GetEnvPlugIn from SupportPac IA06 to work?
I followed the instructions that came with it and I get the following error
on a Windows NT Workstation:

"BIP1553S: Deploy configuration failed processing message flow data: UUID of
resource is 'GetEnvPlugIn <> '.
An empty hash table was supplied when adding message flow data to the
'DPLING' section of the configuration repositiory. The UUID of the resource
in question is 'GetEnvPlugIn <> '.
This is an internal error. Contact your IBM support center."


Thanks,
Gary Weik

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Any good Perl scripting examples around

[Ed Newbold]

I'm looking to get a fast-start on using Perl scripting to GET and/or PUT
messages into queues.  Does anyone have any good, more or less complete,
sample code available I could examine?

Thanks for your thoughts,
Ed Newbold
Columbus, OH


__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ Series 5.2 for win2k

[Michael F Murphy/AZ/US/MQSolutions]

Not sure, but I don't think you can install the CSD on an evaluation copy so you may want to stick with the base product.  It is looking for a file "nodelock" in :\\qmgrs\@SYSTEM so see if that file is present.  If it is not, that is your problem.  When you newly install MQ, the nodelock is not there.  It gets created upon creation of your first queue manager.  This is somehow based on the file "amqpcert.lic" which is in :\\bin.  Make sure you have this file.  If it does not work, try completely uninstalling it, make sure all the directories and registry entries are deleted.   Restart the machine, reinstall just the base software.  Look for the amqpcert.lic file and make a copy of it.  Then if you have a problem and this file disappears, try to copy it back in there and try to create your queue manager.  I don't know what causes this stuff but th
ere is definitely something screwy with licenses on Windows.  I actually have had similar problems with 5.2.1 in Win NT SP 6a but never on Win2K yet.

You can search the archives on the subject "Windows installer "rolls back" install of 5.2.1" and find a short discussion that includes a similar problem.

Mike Murphy
Sr. Middleware Consultant
MQ Solutions, LLC
http://www.mqsolutions.com



"Shanmugam, Vasu" <[EMAIL PROTECTED]> wrote:



Date Recieved:

07/12/2002 08:53:30 AM


To:

[EMAIL PROTECTED]


cc:




Bcc




Subject:

MQ Series 5.2 for win2k

Hi 
I installed 60 days eval copy of MQSeries 5.2 on a win2k server, after that I installed the CSD04 patch to that. If I try to create a queue manager using crtmqm command, I am getting the following error
AMQ7128 : No License istalled for this copy of MQSeries. 
Where as it was working fine before the CSD04 patch update. Any suggestions/solution? 
regards 
Vasu 


***
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.

Re: PCF commands FROM OS/390 to Win2K

[David Awerbuch]

Larry,

I read some of the responses you've already received, and would like to add my
two cents worth.

1.  I believe you can send PCF commands from os/390 to Win2k.  The problem you
may encounter would be data translation on the way back.  I think that can be
handled properly by setting the MQMD_FORMAT field to MQFMT_PCF.  The response
should come back with the same format.  I confess, though, I haven't done this
off an os/390, only across vaxes.

2.  The message type should be MQMD_REQUEST, and sent to
'system.admin.command.queue'.  The reply-to-queue must be coded in the MQMD of
the request; it can be modeled after 'system.mqsc.reply.queue'.  You should get
back an MQMD_REPLY.

3.  You can send an ESCAPE command, which allows you to send real RUNMQSC
command and not have to build the command structures, but you will still have
to interpret the results.  Either way, refer to supportpac MS02; that's the one
I used as the basis for a utility that I had written for a client.  I don't
recall seeing any way to get back the structured response that RUNMQSC
presents.

4.  one important thing.  When you get an error back from the command server,
you will get back more than one response.  Keep that in mind as your parse
responses.  I don't recall the exact situation, but I believe the code in MS02
handles it properly.

That's all I can do for you.  Hope this helps.

David Awerbuch
APC Consulting Services, Inc.
West Hempstead, NY
(516) 481-6440
[EMAIL PROTECTED]





-Original Message-
>From: Larry LaChanse <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: PCF commands FROM OS/390 to Win2K
>Date: Wed, 10 Jul 2002 11:54:04 -0400
>
>I'm running MQ V2.1 on OS/390 and V5.2 on Win2K.I want to periodically
>alter the GET attribute of a Q which lives on a Win2K box.   I want to
>control the attribute from events that occur in my OS/390 environment.I
>could write to a triggered Q on the target box, launching an MQSC command
>file to alter the attribute and send a success message back to the
>mainframe, but I was wondering if I could instead do the same thing with a
>PCF command.
>
>I've never worked with PCF commands before.   I believe PCF commands aren't
>supported "inbound" to OS/390, but can I create a PCF command originating
>on my OS/390 box headed out to the queue manager running on a Windows 2000
>server? If so, has anyone done this who would be willing to share
>tips/techniques, or actual code?
>
>Thanks in advance!
>Larry LaChanse
>The MONY Group
>


__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

MQ Series 5.2 for win2k

[Shanmugam, Vasu]

Title: MQ Series 5.2 for win2k





Hi


I installed 60 days eval copy of MQSeries 5.2 on a win2k server, after that I installed the CSD04 patch to that. If I try to create a queue manager using crtmqm command, I am getting the following error

AMQ7128 : No License istalled for this copy of MQSeries.


Where as it was working fine before the CSD04 patch update. Any suggestions/solution?


regards
Vasu




***
WARNING:  All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.

'UNSUBSCRIBE'

[Karthikeyan Senthilnathan]

'UNSUBSCRIBE'

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

WMQI on AIX problem

[John Scott]

We have a PMR open with IBM and their change team are looking into why we
have the following problem. However, I would like to ask an open question
that may bring any gotchas/stupid mistakes that we may have done to light.

The environment is WMQI 2.1 CSD02 broker running on AIX. The broker database
is remote UDB 7.1 fixpak 3 and we use DB Client 7.12 fixpak 3.

We have both a QA and production environment behaving in the same way, so it
is probably something stupid we have missed that is not immediately
apparent.

Basically we can start the broker up and it appears to start successfully.
However we are unable to control any of the execution groups or flows
reliably. Most of the time we get timeout errors waiting for a response from
the dataflow engine or something (BIP 2066E in syslog mostly).

If we do manage to get flows running, they do seem to process messages. We
have had ex-groups crash one or twice (pre CSD02 being applied) and after
this the whole broker appears to die, refusing to respond to messages.

We have also seen messages building up on the SYSTEM.BROKER.* queues at
times and messages left on these queues when we have stopped the broker.
(This indicates to me that the various processes are having trouble dealing
with the control messages).

None of the flows have database nodes in, but some of them were using the
MQGet support pack plugin. We have removed these flows and renamed the
support pack lil file to another extension, but the thing is still unstable.
We have not got the NEON formatter installed any more (having uninstalled
the WMQI code and re-installed rather than just removing the neon
components). We did not require the NEON formatter anyway.

We have increased database connectivity to 200 connections, we're connecting
through a database "loopback alias" (our DBA's terminology) to fix a known
problem with UDB client talking to UDB server on AIX and copied db2_36.o to
db2.o to fix another DB2 problem identified with WMQI.

Does anybody have and suggestions as to things we may have missed during the
setup? Perhaps there's something buried deep in the
installation/admin/troubleshooting guides.

Regards
John Scott
Senior Middleware Technical Specialist
Argos Ltd





Click here to visit the Argos home page http://www.argos.co.uk

The information contained in this message or any of its attachments may be privileged 
and confidential, and is intended exclusively for the addressee.
The views expressed may not be official policy, but the personal views of the 
originator.
If you are not the addressee, any disclosure, reproduction, distribution, 
dissemination or use of this communication is not authorised.
If you have received this message in error, please advise the sender by using the 
reply facility in your e-mail software.
All messages sent and received by Argos Ltd are monitored for virus, high risk file 
extensions, and inappropriate content.  As a result users should be aware that mail 
may be accessed.



Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security - SSL

[Morag Hughson]

The brand new V5.3 books are available on the following website:-
http://www-3.ibm.com/software/ts/mqseries/library/manualsa/manuals/crosslatest.html
the usual place in other words.

Specifically the security manual is:-
HTML
http://publibfp.boulder.ibm.com/epubs/html/csqzas00/csqzas00tfrm.htm
PDF
http://publibfp.boulder.ibm.com/epubs/pdf/csqzas00.pdf

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  "Garcia Rich
  (SYS1RXG)"   To:   [EMAIL PROTECTED]
  <[EMAIL PROTECTED]>cc:
  Sent by: MQSeriesSubject:  Re: MQSeries Client Security 
- SSL
  List
  


  12/07/2002 14:02
  Please respond to
  MQSeries List





Is this security manual which you are referring too available now or is it
5.3 if it is can you please pass the link.

Thank you

-Original Message-
From: Morag Hughson [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 4:53 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security - SSL


SSL allows you to authenticate the parties concerned. Each queue manager or
client log-on gets a digital certificate, and these certificates are
authenticated when a channel, using SSL, is started between two queue
managers, or between a client and queue manager (you can choose to only
authenticate the responding end of the channel if you wish, allowing you to
effectively have anonymous initiators or clients). Once authentication has
been completed a secret key is set up to use to do encryption for the
lifetime of that channel instance.

There's more information about SSL in the new Security Manual.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  Tony Reddiough
   cc:
  Sent by: MQSeries   Subject:  Re: MQSeries
Client Security
  List
  <[EMAIL PROTECTED]
  C.AT>


  12/07/2002 08:59
  Please respond to
  MQSeries List





James,
 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication
as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided
>in the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Running a stand alone MQ Java client application

[Bushra Mohammad]

I
re-installed MA88 and now I have got all the classes and the application works
fine!
 
Thank
you!
 
Bushra
 

  -Original Message-From: Michael F
  Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]]Sent:
  Friday, July 12, 2002 2:54 AMTo:
  [EMAIL PROTECTED]Subject: Re: Running a stand alone MQ Java
  client applicationThat
  class is in connector.jar.  Make sure you have connector.jar and
  com.ibm.mq.jar in the classpath.  If you get into JMS you need some
  others too,  I think providerutil.jar ???  and mqjms.jar
   ??? On Windows I have
  encountered an interesting problem where the classes don't all install
  properly too.  I have had it happen on more than one machine so it is not
  a fluke.  I haven't seen it with this class, but you never know.  If
  your classpath is right, look in connector.jar to make sure this class
  ResourceException is present with the path javax/resource.  If it is not
  there, completely remove and reinstall MA88 and it fixes the
  problem.Mike
  MurphySr. Middleware ConsultantMQ Solutions,
  LLChttp://www.mqsolutions.comBushra Mohammad <[EMAIL PROTECTED]>
  wrote:
  


  
Date
Recieved:
  
  07/11/2002 08:54:27 AM

  
To:
  
  [EMAIL PROTECTED]

  
cc:
  
  

  
Bcc
  
  

  
Subject:
  
  Running a stand alone MQ Java client
applicationHi,I
  have developed a stand alone application using the Ma88 support pac.The
  documentation says I can run the application as a client application ifit
  uses TCP/IP connectivity to connect to the MQ Server.But when I try to run
  the java application on a windows NT PC, that has Ma88installed and try to
  connect to a remote queue manager,I get the following error
  message:Exception in thread "main"
  java.lang.NoClassDefFoundError:javax/resource/ResourceException 
       at
  com.ibm.mq.MQEnvironment.(MQEnvironment.java:224)Is
  something more required to run the application?Any help would be
  appreciated.ThanksBushraInstructions for managing your
  mailing list subscription are provided inthe Listserv General Users Guide
  available at http://www.lsoft.comArchive:
  http://vm.akh-wien.ac.at/MQSeries.archive

... is out of office from 12/07/2002 until 19/08/2002 (additional information)

[Manuel Morales]

I'm on holidays until 19th of August. This message has been sent to Oscar Saez
Manuel Morales
-
8024 - Mainframe Technology / Middleware
Deutsche Bank, S.A.E.
Tel: +34 93 581.83.34
Fax: +34 93 581.85.83
E-mail: [EMAIL PROTECTED]
-



--

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn 
Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das 
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Running a stand alone MQ Java client application

[Bushra Mohammad]

 I don't even find connection.jar installed on the
PC !
Anyway
I will uninstall and re-install MA88 and give it a try.
 
Thanks for your
inputs
 
Bushra

  -Original Message-From: Michael F
  Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]]Sent:
  Friday, July 12, 2002 2:54 AMTo:
  [EMAIL PROTECTED]Subject: Re: Running a stand alone MQ Java
  client applicationThat
  class is in connector.jar.  Make sure you have connector.jar and
  com.ibm.mq.jar in the classpath.  If you get into JMS you need some
  others too,  I think providerutil.jar ???  and mqjms.jar
   ??? On Windows I have
  encountered an interesting problem where the classes don't all install
  properly too.  I have had it happen on more than one machine so it is not
  a fluke.  I haven't seen it with this class, but you never know.  If
  your classpath is right, look in connector.jar to make sure this class
  ResourceException is present with the path javax/resource.  If it is not
  there, completely remove and reinstall MA88 and it fixes the
  problem.Mike
  MurphySr. Middleware ConsultantMQ Solutions,
  LLChttp://www.mqsolutions.comBushra Mohammad <[EMAIL PROTECTED]>
  wrote:
  


  
Date
Recieved:
  
  07/11/2002 08:54:27 AM

  
To:
  
  [EMAIL PROTECTED]

  
cc:
  
  

  
Bcc
  
  

  
Subject:
  
  Running a stand alone MQ Java client
applicationHi,I
  have developed a stand alone application using the Ma88 support pac.The
  documentation says I can run the application as a client application ifit
  uses TCP/IP connectivity to connect to the MQ Server.But when I try to run
  the java application on a windows NT PC, that has Ma88installed and try to
  connect to a remote queue manager,I get the following error
  message:Exception in thread "main"
  java.lang.NoClassDefFoundError:javax/resource/ResourceException 
       at
  com.ibm.mq.MQEnvironment.(MQEnvironment.java:224)Is
  something more required to run the application?Any help would be
  appreciated.ThanksBushraInstructions for managing your
  mailing list subscription are provided inthe Listserv General Users Guide
  available at http://www.lsoft.comArchive:
  http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security - SSL

[Tom Schneider]

Rich,

If you go to http://www-3.ibm.com/software/ts/mqseries/library/manualsa/manuals/crosslatest.html the WebSphere MQ Security manual be downloaded as a PDF.

-Tom

==
Tom Schneider / IBM Global Services
(513) 533-3644 
[EMAIL PROTECTED]
==







"Garcia Rich (SYS1RXG)" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
07/12/2002 09:02 AM
Please respond to MQSeries List

        
        To:        [EMAIL PROTECTED]
        cc:        
        Subject:        Re: MQSeries Client Security - SSL

       

Is this security manual which you are referring too available now or is it
5.3 if it is can you please pass the link.

Thank you

-Original Message-
From: Morag Hughson [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 4:53 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security - SSL


SSL allows you to authenticate the parties concerned. Each queue manager or
client log-on gets a digital certificate, and these certificates are
authenticated when a channel, using SSL, is started between two queue
managers, or between a client and queue manager (you can choose to only
authenticate the responding end of the channel if you wish, allowing you to
effectively have anonymous initiators or clients). Once authentication has
been completed a secret key is set up to use to do encryption for the
lifetime of that channel instance.

There's more information about SSL in the new Security Manual.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




                      Tony Reddiough
                      
[EMAIL PROTECTED]
                      ACOURT.COM>                 cc:
                      Sent by: MQSeries           Subject:  Re: MQSeries
Client Security
                      List
                      <[EMAIL PROTECTED]
                      C.AT>


                      12/07/2002 08:59
                      Please respond to
                      MQSeries List





James,
                 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:       +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided
>in the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: how to cleanly removed a crampy cluster on NT/2k?

[Järgen Pedersen]

Normally it requres that you make your qmgr repostory qmgr for that qluster
too (using a Namelist), then you can use RESET CLUSTER
and when reset cluster is done, and you see that it's claen, chenage your
repository settings back.
That approach is working fine for me  It has been discussed previous.

I hope it will help you cleaning up. ;o)

Best regards

Joergen H. Pedersen
Systemprogrammer
WM-data SDC
[EMAIL PROTECTED]

IBM Certified MQSeries Specialist
IBM Certified MQSeries Solutions Expert

Please apply this disclaimer to the above message - the opinions are mine
and certainly not necessarily those of my employer.






"Quigley, Robert" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 12-07-2002
15:20:46

Please respond to MQSeries List <[EMAIL PROTECTED]>

Sent by:MQSeries List <[EMAIL PROTECTED]>


To:[EMAIL PROTECTED]
cc:
Subject:Re: how to cleanly removed a crampy cluster on NT/2k?



They should go away after 90 days.  You could try RESET CLUSTER
(clusterName) QMNAME(yourQMgrName) ACTION(FORCEREMOVE) on a repository q
mgr.

-Rob Quigley
Perot Systems
-Original Message-
From: Benjamin Zhou [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 11:29 AM
To: [EMAIL PROTECTED]
Subject: how to cleanly removed a crampy cluster on NT/2k?



Hi all,

after repeatedly encountering problems with clustering on NT/2k, we decided
to get rid of it and use distributed queuing instead.

I followed all the steps in the manual to remove qmgrs from the cluster,
and did everything from command line. The resulting objects are clean.

But I keep getting error messages from windows eventlog saying the
following:

Channel program 'TO_QM_BROKER' started.

Channel not defined remotely.
There is no definition of channel 'TO_QM_BROKER' at the remote location.
Add an appropriate definition to the remote hosts list of defined channels
and retry the operation.

Channel 'TO_QM_BROKER' not found.
The requested operation failed because the program could not find a
definition of channel 'TO_QM_BROKER'.
Check that the name is specified correctly and the channel definition is
available.

Channel program ended abnormally.
Channel program 'TO_QM_BROKER' ended abnormally.
Look at previous error messages for channel program 'TO_QM_BROKER' in the
error files to determine the cause of the failure.

...

There is absolutely not such a channel, I deleted them one by one. Where
else are such objects registered in MQ? Can they be cleanly removed? I
can't afford recreating the queue managers, too many people are using them.

This is definitely bad bugs in the clustering mechanism, does anyone from
IBM happen to know when the bug fix will be released? Several times, a
newly created cluster worked fine in the evening, but stops working the
next morning.

I appreciate any hint on solving this problem or get around it.

thanks a lot,

Benjamin Zhou
Princeton Financial




Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Problem receiving messages from a restarted client application.

[Richard Brunette]

Pavel

After some amount of back-and-forth with IBM Support, we have gotten them
to create an APAR ( PQ62906) for porting the fix to this back to the 5.2
0S/390 queue manager. They have provided us a copy of a fix to test which
worked when applied to our test queue manager. They have been notified of
the results and we are waiting to hear of the creation of PTF for this.

Rick



|-+--->
| |   Pavel Tolkachev |
| |   <[EMAIL PROTECTED]>|
| |   |
| |   Sent by: MQSeries List  |
| |   <[EMAIL PROTECTED]>   |
| |   |
| |   |
| |   |
| |   Thursday May 30, 2002 01:28 PM  |
| |   Please respond to MQSeries List |
| |   |
|-+--->
  
>|
  |
|
  |   To: [EMAIL PROTECTED]  
|
  |   cc:  
|
  |   Subject:   Re: Problem receiving messages from a restarted client
  application.  |
  
>|




Richard,

Please could you let the list know of the IBM answer when you get it.

Thank you,
Pavel



--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: How to compare message attributes

[Sreenivas.Checka]

Title: MQExplorer queue attribut layout changable?



Thanks 
for the response.  I was able to get a good comparison between messages 
using the suggestions below.
 
Checka Software 
Architect 314 923 6708 [EMAIL PROTECTED] 

  -Original Message-From: Potkay, Peter M (PLC, IT) 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 09, 2002 
  9:42 AMTo: [EMAIL PROTECTED]Subject: Re: How to 
  compare message attributes
  Once 
  you get the 2 messages to 2 files, check this website out. It has a few file 
  compare utilities.
   
  http://connecticut.tucows.com/system/filecomp95_license.html
   
   
   
  Peter Potkay IBM 
  MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 
  77906 
  
-Original Message-From: Bullock, Rebecca (CSC) 
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 09, 2002 10:29 
AMTo: [EMAIL PROTECTED]Subject: Re: How to 
compare message attributes
Checka, 
you don't mention the platform you're on, so this has to be in the most 
general terms...
 
I'd dump 
the messages to a file. With Unix or NT, use amqsbcg and run the output 
to a file. With OS/390, use CSQUTIL and write to a file. And then run a 
file compare of the outputs.
 
Hope this 
gets you started -- Rebecca
 

Rebecca Bullock Computer Sciences Corporation 
Educational Testing Service Account 
Princeton, NJ 08541 
e-mail: 
[EMAIL PROTECTED][EMAIL PROTECTED] 
 
  

  -Original Message-From: Sreenivas.Checka 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 09, 2002 9:56 
  AMTo: [EMAIL PROTECTED]Subject: How to compare 
  message attributes
  Hi,
   
   
  I want to compare two messages and get a listing 
  of the attributes that differ.  Is there some utility that can easily 
  achieve this ?
   
  Thanks
  Checka Software Architect 314 923 
  6708 [EMAIL PROTECTED] 
   
** 

This e-mail and any files transmitted with it may contain 
privileged or 
confidential information. It is solely for use by the 
individual for whom 
it is intended, even if addressed incorrectly. If you 
received this e-mail 
in error, please notify the sender; do not disclose, copy, 
distribute, or 
take any action in reliance on the contents of this 
information; and delete 
it from your system. Any other use of this e-mail is 
prohibited. Thank you 
for your 
  compliance.This 
  communication, including attachments, is for the exclusive use of 
  addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all 
  copies.

Re: MQSeries Client Security - SSL

[Pavel Tolkachev]

Yes, please! :-)

Or if there is no document readily available, can someone who knows 5.3 share his or 
her knowledge about the following:

1. Is it possible to configure server end of the client channel to authenticate 
different identities based on MCAUSER field? Other fields? I mean: to be really useful 
SSL channel security should be integrated with MQ user name-based or group name-based 
access control architecture. I do not think the anonymous clients are really useful in 
secure environment unless you want to allow a separate port and channel process for 
each user or administrative group.

2. How do I configure the client end for SSL? Is this new API, new configuration file 
or what? Can I configure different identities on same client machine? Different 
identities for same user name on different machines? (e.g. user1@host1 and user1@host2 
to have different identities and therefore different rights)? My client and server 
platforms of interest are NT, Solaris, AIX, Linux.

Thank you in advance,
Pavel





  "Garcia Rich
  (SYS1RXG)"   To:   [EMAIL PROTECTED]
  <[EMAIL PROTECTED]>cc:
  Sent by: MQSeriesSubject:  Re: MQSeries Client Security 
- SSL
  List
  


  07/12/2002 09:02
  AM
  Please respond to
  MQSeries List






Is this security manual which you are referring too available now or is it
5.3 if it is can you please pass the link.

Thank you

-Original Message-
From: Morag Hughson [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 4:53 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security - SSL


SSL allows you to authenticate the parties concerned. Each queue manager or
client log-on gets a digital certificate, and these certificates are
authenticated when a channel, using SSL, is started between two queue
managers, or between a client and queue manager (you can choose to only
authenticate the responding end of the channel if you wish, allowing you to
effectively have anonymous initiators or clients). Once authentication has
been completed a secret key is set up to use to do encryption for the
lifetime of that channel instance.

There's more information about SSL in the new Security Manual.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  Tony Reddiough
   cc:
  Sent by: MQSeries   Subject:  Re: MQSeries
Client Security
  List
  <[EMAIL PROTECTED]
  C.AT>


  12/07/2002 08:59
  Please respond to
  MQSeries List





James,
 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided
>in the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive




--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of th

Re: MQSeries Client Security

[Beinert, William]

Wrote your own? My hat is off to you. I found the doc so obscure that I had
to put it aside till I had plenty of time.
I would dearly love to see a copy of yours...no substitute for sample
code...

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 7:53 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


I wrote my own ... it is currently written in OS/390 Assembler.  However, I
think that I also took a stab at writing it in 'C'.   You could have a copy
to look at/use  but be warned, it is cheap (free), and you get what you
pay for.  ;-)

Tom Malone

-Original Message-
From: Wesley Shaw [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 11 July, 2002 14:50
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


Who has the best and cheapest Security Exit Program ?

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: how to cleanly removed a crampy cluster on NT/2k?

[Quigley, Robert]

Title: how to cleanly removed a crampy cluster on NT/2k?



They
should go away after 90 days.  You could try RESET CLUSTER
(clusterName) QMNAME(yourQMgrName) ACTION(FORCEREMOVE) on a repository q
mgr.
 
-Rob
Quigley
Perot
Systems

  -Original Message-From: Benjamin Zhou
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 11, 2002 11:29
  AMTo: [EMAIL PROTECTED]Subject: how to cleanly
  removed a crampy cluster on NT/2k?
  Hi all, 
  after repeatedly encountering problems with clustering on
  NT/2k, we decided to get rid of it and use distributed queuing
  instead.
  I followed all the steps in the manual to remove qmgrs from
  the cluster, and did everything from command line. The resulting objects are
  clean.
  But I keep getting error messages from windows eventlog saying
  the following: 
  Channel program 'TO_QM_BROKER' started.  
  Channel not defined remotely.  There is no definition of channel 'TO_QM_BROKER' at the remote
  location.  Add an appropriate definition to the
  remote hosts list of defined channels and retry the operation. 
  Channel 'TO_QM_BROKER' not found.  The requested operation failed because the program could not find a
  definition of channel 'TO_QM_BROKER'.  Check that
  the name is specified correctly and the channel definition is available.
  
  Channel program ended abnormally.  Channel program 'TO_QM_BROKER' ended abnormally.  Look at previous error messages for channel program 'TO_QM_BROKER' in
  the error files to determine the cause of the failure. 
  ... 
  There is absolutely not such a channel, I deleted them one by
  one. Where else are such objects registered in MQ? Can they be cleanly
  removed? I can't afford recreating the queue managers, too many people are
  using them. 
  This is definitely bad bugs in the clustering mechanism, does
  anyone from IBM happen to know when the bug fix will be released? Several
  times, a newly created cluster worked fine in the evening, but stops working
  the next morning.
  I appreciate any hint on solving this problem or get around
  it. 
  thanks a lot, 
  Benjamin Zhou Princeton
  Financial 

Re: MQSeries Client Security - SSL

[Garcia Rich (SYS1RXG)]

Is this security manual which you are referring too available now or is it
5.3 if it is can you please pass the link.

Thank you

-Original Message-
From: Morag Hughson [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 4:53 AM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security - SSL


SSL allows you to authenticate the parties concerned. Each queue manager or
client log-on gets a digital certificate, and these certificates are
authenticated when a channel, using SSL, is started between two queue
managers, or between a client and queue manager (you can choose to only
authenticate the responding end of the channel if you wish, allowing you to
effectively have anonymous initiators or clients). Once authentication has
been completed a secret key is set up to use to do encryption for the
lifetime of that channel instance.

There's more information about SSL in the new Security Manual.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  Tony Reddiough
   cc:
  Sent by: MQSeries   Subject:  Re: MQSeries
Client Security
  List
  <[EMAIL PROTECTED]
  C.AT>


  12/07/2002 08:59
  Please respond to
  MQSeries List





James,
 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided
>in the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQ and Win2K load balancing w/ COM+

[Peter Larsson]

Hi Peter,

Don't know if this will be to any help for you or if it's just noise..anyway here 
are my thoughts.

I haven't been involved in any dev regarding  App Center, but..
My understanding of Component Load Balancing, which is the feature that does 
load-balancing of COM+ apps in App Center, is that it load-balances COM+ object 
creation. Which should mean that as long as
you're holding on to a object reference, it should be bound to the same server hosting 
that object-instance.
This should be true even if your COM-classes use Just-In-Time activation , however as 
I mentioned I haven't used it !
So it COULD be that i.e. JIT-activated objects not are bound to the same server for 
the object reference life-time, then you'll be stuck with using objects that don't 
deactivate between method call's
and thereby kills scalability (at least as MS says).
After reading your posting I looked around on the MS Site and there weren't any docs 
that clearly (deep tech) showed how it really works, but the text I found stated that 
subsequent request for an
already created object should be routed to the same server.

Regards,
Peter Larsson




Peter Heggie
   cc:
Sent by: MQSeriesSubject: MQ and Win2K load balancing 
w/ COM+
List



2002-07-11 21:04
Please respond to
MQSeries List






Has anyone gotten application load-balancing to work in a Windows
COM+/Application Center world? I'm thinking of a request/reply scenario,
where the replytoqueuemanager name is filled in dynamically, but the
application could be swapped between two machines..

Its hard for me to get a handle on the concepts - once an application calls
a COM+ component which performs MQ calls, will the application stay
connected to the same component (which is waiting for a reply)? Or is there
a chance that load balancing will move the application to a different
machine?

It seems to me that an application that performs a  Put (request), then a
Get (reply) w/Wait, will be fine.. but an application that performs the
Gets at a later time (disconnects and then later connects) runs the risk of
being load balanced to a different machine than the one where the reply may
be waiting.

If this is true, then application design will make or break the
request/reply process..

Peter

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Malone . TC]

I wrote my own ... it is currently written in OS/390 Assembler.  However, I
think that I also took a stab at writing it in 'C'.   You could have a copy
to look at/use  but be warned, it is cheap (free), and you get what you
pay for.  ;-)

Tom Malone

-Original Message-
From: Wesley Shaw [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 11 July, 2002 14:50
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


Who has the best and cheapest Security Exit Program ?

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: VB and message.PutDateTime w/GMT

[Peter Larsson]

Hi Peter,

I haven't written anything like that (especially not in VB since I'm C++), but I think 
that one way to go is to use win32 API's.
There are at least two ways of doing it, as usual on e quicker and dirtier and another 
heavier and more robust:


Quick and Dirty:
Call GetLocalTime() and GetSystemTime and calculate the difference between the two and 
then add or subtract that value from your PutDateTime-property.
Observe that these Api's uses a Win32 SYSTEMTIME-struct, that you have to define 
yourself in VB (shouldn't be so hard, I Hope).


Heavier and more Robust:
1. Call SystemTimeToFileTime()  with your PutDateTime-property expressed as a Win32 
SYSTEMTIME-struct, gives you a Win32 FILETIME-struct
2. Call FileTimeToLocalFileTime() with the received Win32 FILETIME-struct in step 1, 
which gives you a new Win32 FILETIME-struct.
3. Call FileTimeToSystemTime() with the received Win32 FILETIME-struct in step 2, 
which gives you a Win32 SYSTEMTIME-struct representing your PutDateTime-property 
formatted as a SYSTEMTIME-struct (in
LocalTime) which is a nice format to continue with.
Observe that these Api's uses Win32 SYSTEMTIME and FILETIME -struct's, that you have 
to define yourself in VB (shouldn't be so hard, I Hope).


The second alternative is what  I would go for if I were going to write such a GMT to 
local time converter in C++ !
It should also handle cases when messages were placed on the queue just before the DST 
(Daylight Savings Time) switch occurred and you're reading them afterwards, then 
you're going calculate the
actual local time when the message was placed on the queue, with the quick and dirty 
solution you're actually calculating the wrong time in that case

Hope this Helps !!

Regards,
Peter Larsson






Peter Heggie
   cc:
Sent by: MQSeriesSubject: VB and message.PutDateTime 
w/GMT
List



2002-07-11 21:09
Please respond to
MQSeries List






How can a VB program account for GMT in the message object's PutDateTime
property? On the mainframe there are functions I can call that tell me if
GMT is observed, and if so, what is the offset..

On Windows, using VB COM components, the message PutDateTime property
returns the time using GMT. I could just hardcode a value to subtract to
get the local time, but then when switching to or from Daylight Savings
Time, the hardcoded value would be wrong.

Has anyone developed a way to compensate for GMT?

I could just write a quick, non-persistent message with a short expiry, and
read it back in to the program and compare the current time with the
PutDateTime to get the offset, but that seems like overkill (and too much
overhead)..

Peter

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client on OpenVMS

[Enrique Irazábal]

Hi Jon,

there are two Mqseries clients for OpenVMS

MACQ: MQSeries Client for Compaq OpenVMS Alpha - V5.1
http://www-3.ibm.com/software/ts/mqseries/txppacs/macq.html

This SupportPac requires:
Compaq OpenVMS V7.2-1

and the
MA5K: MQSeries Client for Compaq (Digital) OpenVMS AXP

http://www-3.ibm.com/software/ts/mqseries/txppacs/ma5k.html

that requires:
OpenVMS AXP V6.2 or later V6, or V7.1 or V7.2

we use this lower version to connect to IBM AS400 MQseries Server from an
AXP-VMS box


the installation puts the mqicb.exe file in the sys$share directory, you
have to link your application with this library

it4s created a sample files directory
(SYS$SYSROOT:[SYSHLP.EXAMPLES.MQSERIES]), take a look there

I think that if you define a channel in the MQseries Queue Manager in the
server, we have it of  *SVRCN type, and you start a listener then you could
establish the connection from a client.

you may need to define the MQSERVER logical in the client machine
 eg: $ DEFINE MQSERVER "CHANNELn/TCP/AXPVMSxx"


I hope this helps


Enrique Irazabal
Madrid
Spain


-Mensaje original-
De: MQSeries List [mailto:[EMAIL PROTECTED]]En nombre de Reckard, Jon
Enviado el: viernes 28 de junio de 2002 16:12
Para: [EMAIL PROTECTED]
Asunto: MQSeries Client on OpenVMS


Does anyone have any experience setting up MQSeries Client on a DEC(Compaq
(HP?)) OpenVMS system, connecting to a Server on another OpenVMS?  The
"System Management Guide" for V2.2 has no client installation info, and the
"MQSeries Clients" manual doesn't even know how to spell VMS.  Yes, I know
V2.2 isn't supported after June 30, 2002.
Thanks for any help.
Jon Reckard
TradePoint Systems LLC
(603) 889-3200 ext. 2262

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Paul Clarke]

>James,
>I haven't got my hands on 5.3 yet.  I know it adds SSL but
>I thought this was only for encryption.  Does it help with authentication
as
>well ?

>I'd be interested in retrying my testing with 5.3 in that case.

>Thanks,
>Tony.

Tony,

Yes SSL provides for server or mutual authentication as well as encryption
and tamper proofing.
Cheers,
P.


Paul G Clarke
WebSphere MQ Development
IBM Hursley

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security - SSL

[Morag Hughson]

SSL allows you to authenticate the parties concerned. Each queue manager or
client log-on gets a digital certificate, and these certificates are
authenticated when a channel, using SSL, is started between two queue
managers, or between a client and queue manager (you can choose to only
authenticate the responding end of the channel if you wish, allowing you to
effectively have anonymous initiators or clients). Once authentication has
been completed a secret key is set up to use to do encryption for the
lifetime of that channel instance.

There's more information about SSL in the new Security Manual.

Cheers
Morag

Morag Hughson
WebSphere MQ for z/OS Development
Internet: [EMAIL PROTECTED]




  Tony Reddiough
   cc:
  Sent by: MQSeries   Subject:  Re: MQSeries Client 
Security
  List
  <[EMAIL PROTECTED]
  C.AT>


  12/07/2002 08:59
  Please respond to
  MQSeries List





James,
 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication
as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[James Kingdon]

Yes, SSL can be used to tackle the authentication problem via the use of
certificates. The queue manager can be configured to only accept
connections from clients which provide an appropriately signed
certificate during the SSL negotiation phase.

Regards,
James.

Tony Reddiough wrote:

>James,
> I haven't got my hands on 5.3 yet.  I know it adds SSL but
>I thought this was only for encryption.  Does it help with authentication as
>well ?
>
>I'd be interested in retrying my testing with 5.3 in that case.
>
>Thanks,
>Tony.
>
>Tony Reddiough
>Certified MQSeries Specialist
>Tel:   +44 (0) 1793 616100
>Mobile:  +44 (0) 7711 264281
>www.alphacourt.com 
>
>Alphacourt - "The Integration Practice"
>
>
>-Original Message-
>From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
>Kingdon
>Sent: 12 July 2002 07:59
>To: [EMAIL PROTECTED]
>Subject: Re: MQSeries Client Security
>
>
>You may be interested in the announcement at
>
>http://www.ibmlink.ibm.com/usalets&parms=H_202-074
>
>with particular reference to the bits about SSL.
>
>Regards,
>James.
>
>Wesley Shaw wrote:
>
>
>
>>Who has the best and cheapest Security Exit Program ?
>>
>>Instructions for managing your mailing list subscription are provided in
>>the Listserv General Users Guide available at http://www.lsoft.com
>>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>>
>>
>>
>>
>>
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Paul Clarke]

> Who has the best and cheapest Security Exit Program ?

A tricky question to answer but since you're interested in this area I
thought I might remind you that 5.3 has SSL security built in to the
channels for free.

Cheers,
P.

Paul G Clarke
WebSphere MQ Development
IBM Hursley

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Tony Reddiough]

Peter,
 no way that I know of although I'm not a Java guru.  I'm simply
quoting what IBM told me.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Potkay,
Peter M (PLC, IT)
Sent: 11 July 2002 18:34
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


"However, if you don't, Java cannot determine the signed on userid... "

Why? Is this just the way JAVA is? Or is there a way to configure your JAVA
environment so that it can get the ID?


Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906


-Original Message-
From: Tony Reddiough [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 1:21 PM
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


If you provide a userid (specified within the Java program itself) it will
be checked.  However, if you don't, Java cannot determine the signed on
userid and so passes nothing to the server.  In this case, the listener has
to either reject the channel start request or simply let it through.  IBM
chose to do the latter.  If you then look at the messages on the queue, in
the MQMD, you'll see the userid of the listener which is usually mqm or
MQUSR_ADMIN or something very powerful.

Of course you cannot rely on Mr Hacker to specify his userid from within his
Java program - he might not be that helpful !

I successfully managed to put a message to the SYSTEM.DEFAULT.LOCAL.QUEUE on
my clients production queue manager which he thought was well protected.  He
was not impressed !  Since then he has either deleted all SVRCONN channels
or disabled them by coding MCAUSER(wibble) where wibble has no authority.
This overrides all other userids but does mean everyone gets the same
treatment.

I was pretty shocked when I discovered this but IBM thought it was perfectly
acceptable.  They always recommend security exits anyway.

Hope this helps,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
Broderick
Sent: 11 July 2002 17:18
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


I have a question. How does the JAVA client application bypass the security
checking on the server. If the svrconn channel has blanks in the MCAUSER
attribute doesn't the server have to authenticate the userid in the message
against the server. We have JAVA apps here and that seems the way they
perform. Am I missing something??

   bobbee


>From: Tony Reddiough <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: MQSeries Client Security
>Date: Thu, 11 Jul 2002 15:20:15 +0100
>
>Bill,
>  I recently discovered a "limitation" with client security on the
>distributed platforms, not sure if it applies to OS/390 but I wouldn't be
>at
>all suprised.
>
>When a client attaches through the SVRCONN channel, the userid under which
>the client application is running will be assumed by the server end (i.e.
>OS/390 in your case).  So, if you client is an win2000 application running
>under userid "fred" then that user will be authenticated at the OS/390 to
>make sure it can connect to the queue manager, put messages on the specific
>queue etc.  So, the upshot is, you have to define "fred" to OS/390 and
>grant
>it permission to your queues.
>
>This is fine.  However, if the client application is written in Java, it
>manages to skip all this checking and can therefore access whatever it
>likes
>on your OS/390 queue manager.
>
>Ok, you say, my program isn't written in Java.  BUT you also have to worry
>about the mallicious guy who is hacking in - his program might be written
>in
>java.
>
>Bottom line, all SVRCONN channels provide access to the queue manager where
>they are defined without going through a securty check.  Since all queue
>managers define SYSTEM.DEFAULT.SVRCONN when they are created (and most
>people don't delete them), I reckon I could put a message onto most queue
>managers in the world unchallenged given access to the network.
>
>Bottom, bottom line, you need security exits !
>
>Tony Reddiough
>Certified MQSeries Specialist
>Alphacourt Limited
>Tel:   +44 (0) 1793 616100
>Mobile:  +44 (0) 7711 264281
>www.alphacourt.com 
>
>Alphacourt - The Integration Practice
>
>
>-Original Message-
>From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of
>Conklin, William
>Sent: 11 July 2002 13:33
>To: [EMAIL PROTECTED]
>Subject: MQSeries Client Security
>
>
>Hi All,
>I'm in the process of setting up a Windows 2000 MQSeries Client to access

Re: MQSeries Client Security

[Tony Reddiough]

James,
 I haven't got my hands on 5.3 yet.  I know it adds SSL but
I thought this was only for encryption.  Does it help with authentication as
well ?

I'd be interested in retrying my testing with 5.3 in that case.

Thanks,
Tony.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of James
Kingdon
Sent: 12 July 2002 07:59
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


You may be interested in the announcement at

http://www.ibmlink.ibm.com/usalets&parms=H_202-074

with particular reference to the bits about SSL.

Regards,
James.

Wesley Shaw wrote:

>Who has the best and cheapest Security Exit Program ?
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: MQSeries Client Security

[Tony Reddiough]

It's even sillier than that.  IBM told me to use security exits - fair
enough.  So, you put an exit at the server end.  Then you need one at the
client end as they usually work in pairs.

However, for Java, the only way to call a security exit is from within the
Java program.

We had MQSI 2.0.2 which means we have remote control centres which are java
clients.

I asked how I could get the control centre to use my security exit.  Oooops
they said, you can't.

So, bottom line, if you want a secure environment you need security exits
which means you can't use MQSI 2.0.2.

My customer was so pleased.

IBM's response - get MQSI 2.1 which was just coming out at the time.  That
has a place for you to specify an exit.

Tony Reddiough
Certified MQSeries Specialist
Tel:   +44 (0) 1793 616100
Mobile:  +44 (0) 7711 264281
www.alphacourt.com 

Alphacourt - "The Integration Practice"


-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
Broderick
Sent: 11 July 2002 21:42
To: [EMAIL PROTECTED]
Subject: Re: MQSeries Client Security


I just got back in from and upgrade and just followed up on this discussion.
I just have one thing to say. What IBM guy was over medicated the day he was
coding this little GEM in the MQSeries channel listener They must have
put the stuff in ALL the coolers at Hursely that day!! Are they kidding???
If I was designing something for a customer and instituted this I would
either be laughed at or fired!! Talk about breaking the model. I remember
being at a seminar and an IBM rep got up about how MQSI was better than
other brokers because they would not break their model to satisfy a
particular community. HUM...sort of the pot calling the kettle black. (I
don't care this time to know where this euphemism comes from!!).

bobbee


>From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: MQSeries Client Security
>Date: Thu, 11 Jul 2002 13:33:58 -0400
>
>"However, if you don't, Java cannot determine the signed on userid... "
>
>Why? Is this just the way JAVA is? Or is there a way to configure your JAVA
>environment so that it can get the ID?
>
>
>Peter Potkay
>IBM MQSeries Certified Specialist, Developer
>[EMAIL PROTECTED]
>X 77906
>
>
>-Original Message-
>From: Tony Reddiough [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, July 11, 2002 1:21 PM
>To: [EMAIL PROTECTED]
>Subject: Re: MQSeries Client Security
>
>
>If you provide a userid (specified within the Java program itself) it will
>be checked.  However, if you don't, Java cannot determine the signed on
>userid and so passes nothing to the server.  In this case, the listener has
>to either reject the channel start request or simply let it through.  IBM
>chose to do the latter.  If you then look at the messages on the queue, in
>the MQMD, you'll see the userid of the listener which is usually mqm or
>MQUSR_ADMIN or something very powerful.
>
>Of course you cannot rely on Mr Hacker to specify his userid from within
>his
>Java program - he might not be that helpful !
>
>I successfully managed to put a message to the SYSTEM.DEFAULT.LOCAL.QUEUE
>on
>my clients production queue manager which he thought was well protected.
>He
>was not impressed !  Since then he has either deleted all SVRCONN channels
>or disabled them by coding MCAUSER(wibble) where wibble has no authority.
>This overrides all other userids but does mean everyone gets the same
>treatment.
>
>I was pretty shocked when I discovered this but IBM thought it was
>perfectly
>acceptable.  They always recommend security exits anyway.
>
>Hope this helps,
>Tony.
>
>Tony Reddiough
>Certified MQSeries Specialist
>Tel:   +44 (0) 1793 616100
>Mobile:  +44 (0) 7711 264281
>www.alphacourt.com 
>
>Alphacourt - "The Integration Practice"
>
>
>-Original Message-
>From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
>Broderick
>Sent: 11 July 2002 17:18
>To: [EMAIL PROTECTED]
>Subject: Re: MQSeries Client Security
>
>
>I have a question. How does the JAVA client application bypass the security
>checking on the server. If the svrconn channel has blanks in the MCAUSER
>attribute doesn't the server have to authenticate the userid in the message
>against the server. We have JAVA apps here and that seems the way they
>perform. Am I missing something??
>
>bobbee
>
>
> >From: Tony Reddiough <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: MQSeries Client Security
> >Date: Thu, 11 Jul 2002 15:20:15 +0100
> >
> >Bill,
> >  I recently discovered a "limitation" with client security on
>the
> >distributed platforms, not sure if it applies to OS/390 but I wouldn't be
> >at
> >all suprised.
> >
> >When a client attaches through the SVRCONN channel, the userid u

Re: TCP/IP services required by MQ to function

[Michael F Murphy/AZ/US/MQSolutions]

I am no network wizard either, but I have worked in environments where everything was blocked and you had to create openings to let anything through.  For MQSeries I could open a port, say 1414, to the target machine from only a specific IP address and tell the firewall to "allow established connection" (or something like that) and it would work.  The connection from the sender channel originates from a random, next available, port greater than 1023.  Each connection uses a different originating port, so you can't specify the port the connection comes from.  The receiver channel will call back to the sender using the port the sender connected to, like 1414, and call the port that the sender originated on.  That's where this "allow established connection" bit comes into play.  Whatever this does, it allows this two way conversation to take place.  If you can't do that, you need rules to allow a whole range of ports to be
open which is bad.  I have never had to open a UDP port for MQ but I can't say for sure it isn't used.  There is a supportpac on firewalls available but I think it may be old.  There is an environment variable I think MQTCPSDRPORT ?? that can be used to limit the originating port to a certain range.  This helps but what if some other application also selects the next available port and uses yours all up?  It can be too restrictive.

Mike Murphy
Sr. Middleware Consultant
MQ Solutions, LLC
http://www.mqsolutions.com



Enrico Strydom <[EMAIL PROTECTED]> wrote:



Date Recieved:

07/11/2002 12:13:34 AM


To:

[EMAIL PROTECTED]


cc:




Bcc




Subject:

TCP/IP services required by MQ to function

One of our clients had a security audit - from that they decided to
"tighten-up" everything.

One of the areas of concern is "no filtering of services on routers" on the
WAN, and the recomendation from the experts is (and I quote)  "... carefully
consider which TCP/IP services and protocols should be allowed through ..."

I use TCP/IP for client and qmgr-to-qmgr connections (MQ5.2 on Win NT/2000
and HP-UX) .

I know little about networking. I have heard things like UDP and ICMP
mentioned. What TCP "services" are there, and which do I need
(alternatively: which can be filtered without breaking my comms)


Regards

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive