Re: MQSeries Client Security

[James Kingdon]

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

Re: Running a stand alone MQ Java client application

[Michael F Murphy/AZ/US/MQSolutions]

That 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 Murphy
Sr. Middleware Consultant
MQ Solutions, LLC
http://www.mqsolutions.com



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

Hi,

I have developed a stand alone application using the Ma88 support pac.
The documentation says I can run the application as a client application if
it 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 Ma88
installed 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.

Thanks

Bushra

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

[Roger Lacroix]

Hi,

You must set the following variables of the MQEnvironment class:

e.g.
MQEnvironment.channel = "CHAN1";
MQEnvironment.hostname="192.168.10.12";
MQEnvironment.port = 1414;

later
Roger...


At 11:54 AM 7/11/2002, you wrote:
>Hi,
>
>I have developed a stand alone application using the Ma88 support pac.
>The documentation says I can run the application as a client application if
>it 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 Ma88
>installed 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.
>
>Thanks
>
>Bushra
>
>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: Wanted: beta testers for MQ Visual Edit

[Roger Lacroix]

Update:

There have been some issues with users connecting locally (binding mode)
using MQ Visual Edit.

Binding mode refers to connecting to a local queue manager WITHOUT
specifying Channel Name, Hostname and Port #.

If you want to connect to a local queue manager using binding mode then the
following 2 items are required:

1. IBM's MQSeries "MA88" SupportPac MUST be installed on the box where you
are running MQ Visual Edit.
2. The following jar files MUST be in your classpath (from MA88) on the box
where you are running MQ Visual Edit:
  com.ibm.mq.jar
  com.ibm.mq.iiop.jar
  com.ibm.mqbind.jar


This should resolve the issue of MQ Visual Edit not connecting (not
responding).

Later
Roger...


At 01:24 AM 7/10/2002, you wrote:
>All:
>
>Anybody interested in beta testing a new Java application that I
>have written?
>
>The MQ Visual Edit beta v0.1 application allows the user to view,
>edit, insert and delete messages from a queue of a MQSeries queue
>manager.  MQ Visual Edit presents the data in an easy to use
>format similar to a database utility or spreadsheet program.
>
>MQ Visual Edit can run on any platform that supports Java v1.3.
>This includes:  AIX, HP-UX, Linux, OS/2 Warp, Sun Solaris, and
>Windows 95/98/ME/NT/2000.  MQ Visual Edit is able to connect to
>local queue managers (residing on the same box) or to any remote
>queue manager(s).
>
>The remote queue managers can be on any platform that supports
>distributed queuing including:  AIX, HP-UX, Linux, OS/2 Warp,
>OS/390 (MVS), OS/400, Sun Solaris, and Windows NT/2000.
>
>You can download MQ Visual Edit at:
>http://www.capitalware.biz/beta.html
>
>Note:  This is an on-going project, so please comments and / or
>complaints to me.
>
>later
>Roger Lacroix
>Enterprise Architect
>Capitalware Inc.
>http://www.capitalware.biz
>
>IBM Certified Specialist - MQSeries
>IBM Certified Developer - MQSeries
>IBM Certified Solutions Expert - MQSeries
>
>
>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

Client connection failover with JMS

[Stefan Sievert]

Hello all,
in order to achieve 'automatic' MQ client failover in case of a queue
manager failure, one can define multiple channels in a client channel table
file and handle 2009 return codes by just re-connecting to the next entry
with the same queue manager (alias) name in the table file.

Now, my question is: How would you do this in a JMS environment, where you
don't have a client channel table, but JNDI entries for your connections to
queue managers? Is there a similar feature to define multiple entries in
that way, which the provider classes can iterate through during connection
to a queue manager?
Any input on this is much appreciated.
Thanks and have a nice day,
Stefan



_
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

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: CSD4 MQ5.2 on Sun - huge memory usage

[Ruud van Zundert]

Just as a final comment, the trace we sent to IBM showed that
the reason this huge memory was being allocated was due to
a setting in the qmstatus.ini file :

[EMAIL PROTECTED]=2403899684

MQ V5.2 uses this field to allocate the appropriate memory
the next time the queue manager is started. When we finally
did get it to work, it showed

[EMAIL PROTECTED]=7372032

I believe it was the upgrade process that somehow increased
this value. Our contact at IBM stated that CSD2 introduced some
code related to the qmstatus.ini file, but although other
customers have suffered similar problems, IBM have not been
able to get to the bottom of it.

I've agreed to close the pmr, but asked IBM what additional info
to capture if it were to happen again: prior to upgrading to
CSD4 (maybe even a prior version) take a copy of your qmstatus.ini
file, and compare it afterwards.

One final word of caution for users of the Candle agent for MQ.
The trace we sent IBM had some 'bad MQ return codes' in it which
were being issued by the agent. We're currently awaiting info
from Candle to ensure that the agent's code (and library files)
are compatible with CSD4.

Regards ... Ruud

-Original Message-
From: Ruud van Zundert [mailto:[EMAIL PROTECTED]]
Sent: 22 June 2002 17:54
To: MQSeries List
Subject: RE: CSD4 MQ5.2 on Sun - huge memory usage


Thanks, Jim - looks like we're not alone. I'll check that
Apar you mentioned.

Anyone else seen this as well?

Anyone from IBM like to comment?

Cheers ... Ruud

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Jim
Ford
Sent: 22 June 2002 16:40
To: [EMAIL PROTECTED]
Subject: Re: CSD4 MQ5.2 on Sun - huge memory usage


I had this exact problem on CSD3 for Solaris. IBM spent 6 weeks
"investigating" it, and eventually wanted me to put on an efix. But it was
our most important production box that was getting the worst of the
problem, and actually crashing every 6-8 hours. So I had long since backed
off CSD3 and gone back to CSD1. We haven't had any problems at this level
whatsoever, before or since.

I believe that the APAR that IBM said described the problem was IY29497,
but I'm not 100% certain. Like I said, we took the coward's way out and
retreated. I do see that IY29497 is fixed on CSD5, so that would indicate
that you're running with this exposure.

Hope this helps.




  Ruud van Zundert
  <[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  OM>  cc:
  Sent by: MQSeriesSubject:  CSD4 MQ5.2 on Sun -
huge memory usage
  List
  


  06/22/02 03:56 AM
  Please respond to
  MQSeries List






Dear all - we're currently rolling out CSD4 for MQ 5.2
onto our Sun, AIX and Windows servers; we were running
without any maintenance.

Progress has been good, and I'm particularly pleased
that the MQ shutdown problems we had on our Sun boxes
has been cured.
No problems have been encountered in the DEV and UAT
environments.

We have just started to upgrade the production Sun boxes,
and when the queue manager was restarted, the listener
soon failed ('could not bind to port 1414'). An FDC was
created around the same time stating 'no memory'.
The IPCS command showed that MQ had allocated a huge
amount of memory, with one segment being over 2GB!!!
(Apologies for not having all the details, but I'm
 writing this away from the client site).

One Sun box was rebooted, and this 'cured' the problem.
A second box was rebooted, but the 2GB memory was
allocated again.

Please note that only one queue manager runs on each
box, and the kernel settings are as per the Quick
Beginnings guide.

Anyone seen this before?

Regards ... Ruud

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]

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

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

[Benjamin Zhou]

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





Hi Garry,


thanks for pointing it out. I got different messages. But anyway, it doesn't work either. I eventually run the command:
reset cluster(my_cluster) qmname(to_be_removed_qmgr) action(forceremove).


the event msg dissappeared afterward, although a few cluster queue stayed a garbig which cannot be removed. but they are not relevant, not nerving the admins anymore.

thanks a lot,


Benjamin Zhou
Princeton Financial


-Original Message-
From: Gorse, Darry [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 11:40 AM
To: [EMAIL PROTECTED]
Subject: Re: how to cleanly removed a crampy cluster on NT/2k?



You could try support pac MS0G... That's if you can get it to work. I been
trying to and have not been able to get past.
An error occurred whilst converting CHECK
correlid:java.io.UnsupportedEncodingException: Cp850
An error occurred whilst reading the message
buffer:java.io.UnsupportedEncodingException: Cp850
An error occurred whilst converting OBJECT
correlid:java.io.UnsupportedEncodingException: Cp850
An error occurred whilst reading the message
buffer:java.io.UnsupportedEncodingException: Cp850


Cheers,
Darry
-Original Message-
From: Benjamin Zhou [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 10: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: MQ and Win2K load balancing w/ COM+

[Larry.McCord]

We are doing a proof of concept project with Application Center. From what I
understand one of the requirements for the Application Center Load Balancing
is a stateless application. You may have to switch from a request/reply
model to a send/receive model where the state information for the
transaction is saved to a DB or a clustered queue.
Thanks Larry
Larry McCord
Blue Cross and Blue Shield of Missouri
314.923.4432
[EMAIL PROTECTED]


 -Original Message-
From:   Peter Heggie [mailto:[EMAIL PROTECTED]]
Sent:   Thursday, July 11, 2002 2:04 PM
To: [EMAIL PROTECTED]
Subject:MQ and Win2K load balancing w/ COM+

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

VB and message.PutDateTime w/GMT

[Peter Heggie]

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

MQ and Win2K load balancing w/ COM+

[Peter Heggie]

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

Re: Queue manager not connecting through MQExplorer(local) but co nnecting remotely thru MQExplorer

[Philip, Aby]

Hi Neil,

Know what? Till now all the things we were trying on the local machine was
through terminal server service. I went to the physical machine and tried
out creating the queue manager there and there everything is OK. It is only
when I try running these commands through terminal sevices that we have this
strange problem.

So looks like that is OK although it would be interesting to find out why
doing this through Terminal services has all these strange problems???


Thanks very much for the help Neil.

Kind Regards
Aby

-Original Message-
From: Taylor, Neil
To: [EMAIL PROTECTED]
Sent: 7/11/02 7:02 AM
Subject: Re: Queue manager not connecting through MQExplorer(local) but
connecting remotely thru MQExplorer

Aby

Very strange.

Can you prove the following on the local machine:

Go to the cmd line and enter the following:
crtmqm ABY
strmqm ABY
runmqsc ABY
dis ql(*)
end

You should see all the default queue objects (SYSTEM.), correct?
Now when you go to explorer you may need to refresh (F5) the display of
QMGRS, ABY should appear and you have access to view all the q's and
channels etc, not that there are any non-system objects defined yet.
BTW - you need to select the Show/Hide System Objects button to be able
to view the queues displayed above.

If this works without error then things apprear ok.

If not can you provide more details:

1) Which tool did you use to create the local QMGR - runmqsc or Explorer
2) Which user-id do you login as locally?
3) What is that user-id's Group and domain membership?
4) What user-id do you login as on the remote machine?
5) Are there any MQ user (including yours) or MQ product error entries
in the System Log in the local Event Viewer?  For example, DCOM.
6) What version of MQSeries are you using?
7) You mention you can't see Queues or Advanced - do these folders not
exist?  If they exist, what happens when you click on them?  Any errors
or just a blank right column.  Can you view other local Qmgrs Q's etc
via explorer
8) The "Qmgr not available" indicates that it either does not exist or
is not started.  Are the qmgrs started on the local machine?  (Green
up-arrow in explorer).
9) What are the qmgr names involved?
10) Try using runmqsc -w from the remote machine

Neil


-Original Message-
From:   Philip, Aby [mailto:[EMAIL PROTECTED]]
Sent:   Wed 10/07/2002 14:20
To: [EMAIL PROTECTED]
Cc:
Subject: Queue manager not connecting through
MQExplorer(local) but connecting remotely thru MQExplorer
Hi Neil,
I tried creating my own queue manager on the same machine. And it seems
that
I am not able to see the "Queues" folder or the "Advanced" folder for
the
same queue manager on the MQExplorer which is on the same machine as the
server. Now the funny part is that i can administer the queues from
another
machine's MQExplorer.

Now the QM.TEST queue manager was created using MQExplorer on the server
machine. I tried running runmqsc on that machine and it tells me that
the
"Queue manager not available". Although I am able to access it from
another
machine's MQExplorer.

I tried removing and adding the MQSeries snap in and there was no
effect.

There was one more funny thing I observed. Sometime back I was not an
administrator on the server machine and when I tried to connect remotely
through MQExplorer i had the access not authorised 2035. But later on i
was
made a part of the admnistrators group on that machine and it was only
then
that i was able to access the queue manager remotely.

What puzzles me is that we cannot administer the queue managers locally
through the local MQExplorer.

One thing strange might be that the MQSeries installation is done on C:.
D:.
E: drives. For MQ on NT there is the option to put the log files on one
directory and another part on another directory and so on. I don't think
that this has anything to do with this. but just thought that i would
put
this in.

Any ideas?

Thanks in advance for the help.
Kind Regards
Aby Philip

-Original Message-
From: Taylor, Neil
To: [EMAIL PROTECTED]
Sent: 7/3/02 3:50 PM
Subject: Re: Queue manager not connecting through MQExplorer

Aby

Very strange.  How was the qmgr deleted, re-created and started - I
presume not using Explorer/ Services?  In which case I suspect that
Explorer, which is a Microsoft snap-in, is still displaying the deleted
QM1, but it cannot connect now as it does not exist.  Has explorer been
re-started since the new Qmgr was created?

What does MQServices show on the local machine for this qmgr?  Is the
Qmgr actually started - can you use runmqsc successfully?

One work around you can try is to select Add/Remove Snap-in from
Explorer.  Remove MQSeries Explorer.  Then add it again.  This should
effectively force a re-set.  Note that with this option you lose all
remote connections, so would need to redefine connections to remote
Qmgrs.

HTH

Neil

-Original Message-
From: Philip, Aby [mailto:[EMAIL PROTECTED]]
Sent: Wed 0

Re: MQSeries Client Security

[Wesley Shaw]

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

Re: MQSeries Client Security

[Pavel Tolkachev]

Java can,

for example

System.getProperty("user.name");

This is just not the way how MQSeries classes for Java works. In fact, that MCA user 
name per se does not provide any security -- one has to authenticate the name passed 
in the Exit to decide if s/he wants to trust it.

Pavel






  "Potkay, Peter M
  (PLC, IT)" To:   [EMAIL PROTECTED]
  Subject:  Re: MQSeries Client Security
  Sent by: MQSeries
  List
  


  07/11/2002 01:33 PM
  Please respond to
  MQSeries List






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

Re: MQSeries Client Security

[Potkay, Peter M (PLC, IT)]

"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 a
>single q on OS/390 using one qmgr. (we use Top Secret as our mainframe
>security package). I want to be able to secure the q so that only one
>application can access it.  In the manual they discuss Transport level
>security, Channel security exits, and Identification passed to a channel
>exit.  Or, should I look at the OAM (Object Authority Manager) as a way of
>securing this? Several users will be accessing the application with
>specific
>and generic user ids.
>
>Thanks a MILLION in advance for 

Re: MQSeries Client Security

[Tony Reddiough]

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 a
>single q on OS/390 using one qmgr. (we use Top Secret as our mainframe
>security package). I want to be able to secure the q so that only one
>application can access it.  In the manual they discuss Transport level
>security, Channel security exits, and Identification passed to a channel
>exit.  Or, should I look at the OAM (Object Authority Manager) as a way of
>securing this? Several users will be accessing the application with
>specific
>and generic user ids.
>
>Thanks a MILLION in advance for any ideas you may have on the topic.
>
>Bill C.
>
>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

[Gorse, Darry]

Did you make sure that the connection.jar was in your class path?

Cheers,
Darry

-Original Message-
From: Bushra Mohammad [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 10:54 AM
To: [EMAIL PROTECTED]
Subject: Running a stand alone MQ Java client application


Hi,

I have developed a stand alone application using the Ma88 support pac.
The documentation says I can run the application as a client application if
it 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 Ma88
installed 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.

Thanks

Bushra

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: Queue manager not connecting through MQExplorer(local) but co nnecting remotely thru MQExplorer

[Philip, Aby]

Hi Paul,

Right, these queue managers were created using the Terminal server session.

Regards
Aby

-Original Message-
From: Paul Meekin
To: [EMAIL PROTECTED]
Sent: 7/11/02 7:39 AM
Subject: Re: Queue manager not connecting through MQExplorer(local) but
connecting remotely thru MQExplorer

Just another thought - the new QMgr wasn't created from within a
Terminal
Server session, was it? We have had a couple of instances where QMgrs
were
created in this way - the symptoms are pretty much what you are
describing
here.

Cheers,
Paul Meekin
Middleware Consultant - Application Messaging and Integration
Internal *120 6758  External +44 (0) 118 944 6758






"Taylor, Neil" <[EMAIL PROTECTED]>
COMMERCEQUEST.COM
Sent by: MQSeries List <[EMAIL PROTECTED]>
11/07/02 12:02
Please respond to MQSeries List




To:
[EMAIL PROTECTED]
cc:



Subject:
Re: Queue manager not connecting through MQExplorer(local) but
connecting
remotely thru MQExplorer



-Original Message-
From: Philip, Aby [mailto:[EMAIL PROTECTED]]
Sent: Wed 03/07/2002 14:57
To: [EMAIL PROTECTED]
Cc:
Subject: Queue manager not connecting through MQExplorer



Hi everyone,

There was a particular problem which a group here is facing.
There was a
queue manager QM1 which went down. It was running on port 1416.
The person
in charge created another queue manager(same name) after
deleting the first
manager. The new one is running on port 1414. Now what happened
is that the
guys there are able to start the queue manager but when they try
to use
MQExplorer on the machine on which the manager is connected,
there is no
response. They see the queue manager name and it is listed as
'LOCAL' but
the status is 'Not connected'. Now when they try to right click
and
'Connect' they are not able to.

Funny part is that on the same server machine when they try to
connect
through it remotely that is using the 'Show queue manager' and
then specify
the queue manager name and the connection they are able to view
all the
objects in it.

Is there any difference in the MQExplorer being able to connect
to a queue
manager on the same machine as 'Local' and 'Remote'. Any
pointers?

Thanks in advance for the help.

Kind Regards
Aby

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

"{--?~
jvx2
j)b b.n +bvz'^v)  ???K n?i^jm6 %r?b?m?f  ? Izr

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

[Robert Broderick]

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 a
>single q on OS/390 using one qmgr. (we use Top Secret as our mainframe
>security package). I want to be able to secure the q so that only one
>application can access it.  In the manual they discuss Transport level
>security, Channel security exits, and Identification passed to a channel
>exit.  Or, should I look at the OAM (Object Authority Manager) as a way of
>securing this? Several users will be accessing the application with
>specific
>and generic user ids.
>
>Thanks a MILLION in advance for any ideas you may have on the topic.
>
>Bill C.
>
>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




_
Send and receive Hotmail on your mobile device: http://mobile.msn.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

Running a stand alone MQ Java client application

[Bushra Mohammad]

Hi,

I have developed a stand alone application using the Ma88 support pac.
The documentation says I can run the application as a client application if
it 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 Ma88
installed 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.

Thanks

Bushra

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?

[Gorse, Darry]

You could try support pac MS0G... That's if you can get it to work. I been
trying to and have not been able to get past.
An error occurred whilst converting CHECK
correlid:java.io.UnsupportedEncodingException: Cp850
An error occurred whilst reading the message
buffer:java.io.UnsupportedEncodingException: Cp850
An error occurred whilst converting OBJECT
correlid:java.io.UnsupportedEncodingException: Cp850
An error occurred whilst reading the message
buffer:java.io.UnsupportedEncodingException: Cp850

Cheers,
Darry
-Original Message-
From: Benjamin Zhou [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 11, 2002 10: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

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

[Benjamin Zhou]

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

[Tony Reddiough]

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 a
single q on OS/390 using one qmgr. (we use Top Secret as our mainframe
security package). I want to be able to secure the q so that only one
application can access it.  In the manual they discuss Transport level
security, Channel security exits, and Identification passed to a channel
exit.  Or, should I look at the OAM (Object Authority Manager) as a way of
securing this? Several users will be accessing the application with specific
and generic user ids.

Thanks a MILLION in advance for any ideas you may have on the topic.

Bill C.

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

Ashok Agarwala/DTC is out of the office.

[Ashok Agarwala]

I will be out of the office from 07/11/2002 until 07/27/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

Java Object to XML Workflow message

[Raul Acevedo]

Does anyone have a Java class or any other way to convert Java objects to
XML Workflow messages to CreateAndStartInstance ?

Raul L. Acevedo
IT Architect
IBM Global Services
818-539-3203 Office (TL 396-3203) Glendale, CA
818-599-6626 Mobile
[EMAIL PROTECTED]

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: Connect CICS to MQSeries in another partition

[Curt Dolny]

BDY.RTF
Description: RTF file

MQSeries Client Security

[Conklin, William]

Hi All,
I'm in the process of setting up a Windows 2000 MQSeries Client to access a
single q on OS/390 using one qmgr. (we use Top Secret as our mainframe
security package). I want to be able to secure the q so that only one
application can access it.  In the manual they discuss Transport level
security, Channel security exits, and Identification passed to a channel
exit.  Or, should I look at the OAM (Object Authority Manager) as a way of
securing this? Several users will be accessing the application with specific
and generic user ids.

Thanks a MILLION in advance for any ideas you may have on the topic.

Bill C.

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: Queue manager not connecting through MQExplorer(local) but connecting remotely thru MQExplorer

[Paul Meekin]

Just another thought - the new QMgr wasn't created from within a Terminal
Server session, was it? We have had a couple of instances where QMgrs were
created in this way - the symptoms are pretty much what you are describing
here.

Cheers,
Paul Meekin
Middleware Consultant - Application Messaging and Integration
Internal *120 6758  External +44 (0) 118 944 6758






"Taylor, Neil" <[EMAIL PROTECTED]>
COMMERCEQUEST.COM
Sent by: MQSeries List <[EMAIL PROTECTED]>
11/07/02 12:02
Please respond to MQSeries List




To:
[EMAIL PROTECTED]
cc:



Subject:
Re: Queue manager not connecting through MQExplorer(local) but  connecting
remotely thru MQExplorer



-Original Message-
From: Philip, Aby [mailto:[EMAIL PROTECTED]]
Sent: Wed 03/07/2002 14:57
To: [EMAIL PROTECTED]
Cc:
Subject: Queue manager not connecting through MQExplorer



Hi everyone,

There was a particular problem which a group here is facing.
There was a
queue manager QM1 which went down. It was running on port 1416.
The person
in charge created another queue manager(same name) after
deleting the first
manager. The new one is running on port 1414. Now what happened
is that the
guys there are able to start the queue manager but when they try
to use
MQExplorer on the machine on which the manager is connected,
there is no
response. They see the queue manager name and it is listed as
'LOCAL' but
the status is 'Not connected'. Now when they try to right click
and
'Connect' they are not able to.

Funny part is that on the same server machine when they try to
connect
through it remotely that is using the 'Show queue manager' and
then specify
the queue manager name and the connection they are able to view
all the
objects in it.

Is there any difference in the MQExplorer being able to connect
to a queue
manager on the same machine as 'Local' and 'Remote'. Any
pointers?

Thanks in advance for the help.

Kind Regards
Aby

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

"{--?~
jvx2
j)b b.n +bvz'^v)  ???K n?i^jm6 %r?b?m?f  ? Izr

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: Queue manager not connecting through MQExplorer(local) but connecting remotely thru MQExplorer

[Taylor, Neil]

Aby

Very strange.

Can you prove the following on the local machine:

Go to the cmd line and enter the following:
crtmqm ABY
strmqm ABY
runmqsc ABY
dis ql(*)
end

You should see all the default queue objects (SYSTEM.), correct?  Now when you go 
to explorer you may need to refresh (F5) the display of QMGRS, ABY should appear and 
you have access to view all the q's and channels etc, not that there are any 
non-system objects defined yet.  BTW - you need to select the Show/Hide System Objects 
button to be able to view the queues displayed above.

If this works without error then things apprear ok.

If not can you provide more details:

1) Which tool did you use to create the local QMGR - runmqsc or Explorer
2) Which user-id do you login as locally?
3) What is that user-id's Group and domain membership?
4) What user-id do you login as on the remote machine?
5) Are there any MQ user (including yours) or MQ product error entries in the System 
Log in the local Event Viewer?  For example, DCOM.
6) What version of MQSeries are you using?
7) You mention you can't see Queues or Advanced - do these folders not exist?  If they 
exist, what happens when you click on them?  Any errors or just a blank right column.  
Can you view other local Qmgrs Q's etc via explorer
8) The "Qmgr not available" indicates that it either does not exist or is not started. 
 Are the qmgrs started on the local machine?  (Green up-arrow in explorer).
9) What are the qmgr names involved?
10) Try using runmqsc -w from the remote machine

Neil


-Original Message-
From:   Philip, Aby [mailto:[EMAIL PROTECTED]]
Sent:   Wed 10/07/2002 14:20
To: [EMAIL PROTECTED]
Cc: 
Subject: Queue manager not connecting through MQExplorer(local) but 
connecting remotely thru MQExplorer
Hi Neil,
I tried creating my own queue manager on the same machine. And it seems that
I am not able to see the "Queues" folder or the "Advanced" folder for the
same queue manager on the MQExplorer which is on the same machine as the
server. Now the funny part is that i can administer the queues from another
machine's MQExplorer.

Now the QM.TEST queue manager was created using MQExplorer on the server
machine. I tried running runmqsc on that machine and it tells me that the
"Queue manager not available". Although I am able to access it from another
machine's MQExplorer.

I tried removing and adding the MQSeries snap in and there was no effect.

There was one more funny thing I observed. Sometime back I was not an
administrator on the server machine and when I tried to connect remotely
through MQExplorer i had the access not authorised 2035. But later on i was
made a part of the admnistrators group on that machine and it was only then
that i was able to access the queue manager remotely.

What puzzles me is that we cannot administer the queue managers locally
through the local MQExplorer.

One thing strange might be that the MQSeries installation is done on C:. D:.
E: drives. For MQ on NT there is the option to put the log files on one
directory and another part on another directory and so on. I don't think
that this has anything to do with this. but just thought that i would put
this in.

Any ideas?

Thanks in advance for the help.
Kind Regards
Aby Philip

-Original Message-
From: Taylor, Neil
To: [EMAIL PROTECTED]
Sent: 7/3/02 3:50 PM
Subject: Re: Queue manager not connecting through MQExplorer

Aby

Very strange.  How was the qmgr deleted, re-created and started - I
presume not using Explorer/ Services?  In which case I suspect that
Explorer, which is a Microsoft snap-in, is still displaying the deleted
QM1, but it cannot connect now as it does not exist.  Has explorer been
re-started since the new Qmgr was created?

What does MQServices show on the local machine for this qmgr?  Is the
Qmgr actually started - can you use runmqsc successfully?

One work around you can try is to select Add/Remove Snap-in from
Explorer.  Remove MQSeries Explorer.  Then add it again.  This should
effectively force a re-set.  Note that with this option you lose all
remote connections, so would need to redefine connections to remote
Qmgrs.

HTH

Neil

-Original Message-
From: Philip, Aby [mailto:[EMAIL PROTECTED]]
Sent: Wed 03/07/2002 14:57
To: [EMAIL PROTECTED]
Cc:
Subject: Queue manager not connecting through MQExplorer



Hi everyone,

There was a particular problem which a group here is facing.
There was a
queue manager QM1 which went down. It was running on port 1416.
The person
in charge created another queue manager(same name) after
deleting the first
manager. The new one is running on port 1414. Now what happened
is that the
guys there are able to start the queue manager but when they try
to use
MQExplorer on the machine on which the manager is connected,
there is no
response. They see the queue manager name and it is listed as
'LOC

WMQI Fix or workaround for: CWF Decimal with NullPadFill (defect 25949)

[Markus Sonderegger]

Does anybody know about a fix or workaround to the mentioned defect (readme
of WMQI CSD02)

8. CWF Decimal with NullPadFill (defect 25949)
There is a known defect with inputting an explicitly nulled Decimal
element that has Encoding Null set to "NullPadFill" for the CWF physical
wire format layer.

This defect came in with the new MRM Null Handling functionality in CSD02.

Any suggestions are very much appreciated.

Could we downgrade to CSD01 having the broker on Solaris and the ConfigMgr
on W2K by pkgrm/uninstalling CSD02 and pkgadd/installing CSD01 on the
respective platforms?

Thanks for sharing your knowledge and experience.

Regards

Markus

---
Dr. Markus Sonderegger
Bank Julius Baer & Co. Ltd., Zurich, Switzerland
Telephone: +41 58 887 7281, Mobile: +41 79 698 09 79, Telefax: +41 58 887
4475
[EMAIL PROTECTED], www.juliusbaer.com

*Disclaimer*
This message is for the addressee only and may contain confidential or
privileged information. You must delete and not use it if you are not the
intended recipient. It may not be secure or error-free. All e-mail
communications to and from the Julius Baer Group may be monitored.
Processing of incoming e-mails cannot be guaranteed. Any views expressed in
this message are those of the individual sender. This message is for
information purposes only. All liability of the Julius Baer Group and its
entities for any damages resulting from e-mail use is excluded. US persons
are kindly requested to read the important legal information presented
after clicking here: http://www.juliusbaer.com/maildisclaimer

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: PCF commands FROM OS/390 to Win2K

[Tony Reddiough]

The reply is sent to the reply to queue so you should be ok.

There is no reason why you can't generate PCF messages on OS/390 and read
the replies, they're only messages after all.  The only thing you can't do
is have the OS/390 queue manager process PCF messages for you by putting
them onto the command input queue.

As a starter for ten, and if you have Java available, the MS0B supportpac
makes creating PCF messages a bit easier.  Otherwise, have a look at MS02
which has some examples in it.  Creating them from scratch can be a bit
fiddly.

Tony.

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 Robert
Broderick
Sent: 10 July 2002 17:45
To: [EMAIL PROTECTED]
Subject: Re: PCF commands FROM OS/390 to Win2K


I have not played with PCF commands BUT..

I believe there is a SupportPac that gives you a PCF command examples and,
maybe, a program. But they are probably for the distributed platforms. I
would believe you could write them remotely to the command queue on the
Win2K box and specify your replyqueue on the OS390. There you could pick up
the response and parse it for what ever you need. You would of course have
to setup the communication between the Win2K and OS390. The only problem is
if the resulting message comming from the PCF command is written to a
specific queue and not a replyqueu specified in the message. (You could
always alias that queue to your remote queue coming back to the OS390. That
should screw up everyone on the Win2K box!! (teee hee hee...Remember it's
always easier to get forgiveness that permission!!)).

If I'm wrong I'm sure somebody will comment.


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




_
Send and receive Hotmail on your mobile device: http://mobile.msn.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