| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Client connection from Windows 2000 to MQSeries server on OS |
« View previous topic :: View next topic » |
| Author |
Message
|
| calauza |
 Posted: Tue Jan 13, 2004 5:35 am Post subject: Client connection from Windows 2000 to MQSeries server on OS |
 |
|
Newbie
Joined: 13 Jan 2004
Posts: 6
|
Hi All,
I am trying to connect from Windows 2000 MQSeries client 5.2 to MQSeries Server 5.2 on mainframe (OS/390), but the operation fails with the reason code 2059.
I've checked on the CHIN log on the mainframe and I found "CSQXGIP Client attachment feature available" entry, so I'm covered.
My goal is to connect directly the client to the server, without using a MQSeries Server on Windows, that's the beauty of MQSeries, cross-platform connections.
I've tryied also a sample supplied by the client installation, AMQSCNXC, and I got connected to the server using the channel SYSTEM.DEF.SVRCONN, but this channel is of type SVRCONN allowing only inquiry, (I've managed to get the queue manager name from the inquiry), but when I'm trying to open the channel for writing, it fails with 2059. The same reson code I got when trying to connect to all other channel types (RECEIVER, REQUESTER, SENDER, SERVER).
Please advise on what actions can be done in order to connect to a channel of WRITE and READ type.
Thank you all. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jan 13, 2004 5:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Please don't post the same question twice.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| calauza |
| Posted: Tue Jan 13, 2004 5:57 am Post subject: |
|
|
Newbie
Joined: 13 Jan 2004
Posts: 6
|
| Sorry about that, I thought this channel is most appropriate for my post. Can U help me here? |
|
| Back to top |
|
|
| RatherBeGolfing |
| Posted: Tue Jan 13, 2004 6:28 am Post subject: |
|
|
Centurion
Joined: 12 Nov 2002
Posts: 118
Location: Syracuse, NY, USA
|
You didn't mention it, but I assume you have either specified an MQSERVER environment variable on your W2K machine or created a client channel table and specified the MQCHLLIB/MQCHLTAB variables?
The MQSERVER variable or the AMQCLCHL.TAB must refer to the SVRCONN channel you have defined on the mainframe. Also, I believe you need to run RACF (or whatever security you use) commands to grant connect authorities to the queue manager(s), and put/get/whatever authorities to the queues that the client programs will be using...
Have you tried using the AMQSPUTC program from a CMD prompt on the W2K box?
C:\> AMQSPUTC qname qmgrname
_________________
Cheers,
Larry
MQ Certifiable |
|
| Back to top |
|
|
| calauza |
| Posted: Tue Jan 13, 2004 10:00 pm Post subject: |
|
|
Newbie
Joined: 13 Jan 2004
Posts: 6
|
Hi Larry,
1. From cmd on winnt 2000 box, I set the MQSERVER=NT.TWD.INP.T1/TCP/ip_address, and after that, in the same window, run the AMQSPUTC qname qmgrname, but MQCONN fails with 2059, and in the AMQERR01.LOG I got:
01/14/2004 08:31:24
AMQ9547: Type of remote channel not suitable for action requested.
EXPLANATION:
The operation requested cannot be performed because channel 'NT.TWD.INP.T1' on
the remote machine is not of a suitable type. For example, if the local
channel is defined as a sender the remote machine must define its channel as
either a receiver or requester.
ACTION:
Check that the channel name is specified correctly. If it is, check that the
remote channel has been defined correctly.
The NT.TWD.INP.T1 was defined as receiver, sender, server type, either one give 2059.
2. I've compiled amqscnxc.c file provided as sample, and run it in debug step by step. For connection is using MQCONNX function, where in second parameter, Connect_options, you may specify the channel_name, ip_address of the server and the queue manager name. The function works only if I specify the channel name as SYSTEM.DEF.SVRCONN. The next function is MQOPEN to open the queue manager object, with the third parameter as "MQOO_INQUIRE + MQOO_FAIL_IF_QUIESCING" and it was OK. The third function is MQINQ and from this one I got the queue manager name.
So far so god. But when I changed the name of the channel to NT.TWD.INP.T1, the MQCONNX fails with reason 2059. I've defined the NT.TWD.INP.T1 as RECEIVER, SENDER, SERVER, but I got the same result:2059.
At this point I've concluded that it might be something wrong with the definition of the NT.TWD.INP.T1 channel on the Mainframe.
Do you have any other clues?
Thaks a lot,
Gabriel. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 14, 2004 5:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Client connections are made using "Server Connection" (SVRCONN) channels.
They are not made with Sender, Receiver, or any other kind of channel.
Client Connection channels can also be created, as templates for useage on the client side. You can use them instead of using the MQSERVER environment variable, or you can use MQCONNX.
But you still need to point to a SVRCONN channel on the server side.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RatherBeGolfing |
| Posted: Wed Jan 14, 2004 5:29 am Post subject: |
|
|
Centurion
Joined: 12 Nov 2002
Posts: 118
Location: Syracuse, NY, USA
|
So, bottom line - log onto your mainframe system and create a SVRCONN channel with the name NT.TWD.INP.T1, using SYSTEM.DEF.SVRCONN as an example and you should be all set.
You got your sample pgm to work precisely becaused you specified SYSTEM.DEF.SVRCONN as the channel on the mainframe end. If you delete channel NT.TWD.INP.T1 on the mainframe and recreate it as a channel type SVRCONN, you will be successful.
_________________
Cheers,
Larry
MQ Certifiable |
|
| Back to top |
|
|
| calauza |
| Posted: Wed Jan 14, 2004 7:33 am Post subject: |
|
|
Newbie
Joined: 13 Jan 2004
Posts: 6
|
Hi All,
First, thank a lot for your support, I've resolved the problem with your help.
But I discovered a very funny thing, let me explain the whole process:
I've created again the NT.TWD.INP.T1 as SVRCONN channel type and with MQCONNX I got connected to it. After that I tried to open a queue using MQOPEN with option set for input and output, but failed with 2035, security problem. OK, I used MQOO_ALTERNATE_USER_AUTHORITY parameter in MQOPEN, specifying in the object descriptor for the queue (second parameter for MQOPEN) one RACF user (SYSXXXXX) that have authority to do anything in the mqst on the mainframe. It fails again with 2035.
I've checked again the documentation and I discovered a tiny little statement :
"This indicates that the AlternateUserId field in the ObjDesc parameter contains a user identifier that is to be used to validate this MQOPEN call. The call can succeed only if this AlternateUserId is authorized to open the object with the specified access options, regardless of whether the user identifier under which the application is running is authorized to do so. This does not apply to any context options specified, however, which are always checked against the user identifier under which the application is running."
I've checked the EFTTMSTR - JESMSGLG log and I saw that the MQOPEN was still calling on behalf of the user id that I was currently logged on the NT machine, for example USER1. I've created a local user named SYSXXXXX, got logged on as it on NT, and try again. It worked!!....I was able to put and get messages on the queue.
But if I think twice, this it's odd. The z/OS is checking only the user name (max 8 chars) and NOT from where the user is coming from or at least the password.
Bottom line: I think this is a security breach, because if I know only the user name of a power operator on z/OS (without password), I define it on my local machine and I will be able to connect to z/OS MQ! In my opinion, the queue manager on mainframe SHOULD check also the other credentials of the user (as for instance user domain (group) and /or password).
z/OS assumes that, in a client-server design, the user of the application is a RACF user, on which, of course, you may set up any limits you like. But what if the user is on a NT machine? Plus: what if the application is not running on a client context, as for example a service on NT?
Thank you again,
Gabriel |
|
| Back to top |
|
|
| RatherBeGolfing |
| Posted: Wed Jan 14, 2004 7:59 am Post subject: |
|
|
Centurion
Joined: 12 Nov 2002
Posts: 118
Location: Syracuse, NY, USA
|
Gabriel,
Glad you got things working. Regarding the security issues. I'm no security guru and we don't connect to our mainframe with clients any longer, however the way we "got around" the security issues was to assign a generic ID that the client apps would use when dealing with MQSeries calls, say GENID1. Then, on the SVRCONN channel on the host (mainframe), I'd put GENID1 in the value of MCA user ID field. Finally, I'd have the RACF guys run commands to grant the connect, get, etc authorities to GENID1 against the various profiles for the queue manager and queue aliases.
This is probably not a very secure arrangement, since anyone who knew the generic id could code a program to access the mainframe queue manager and objects, even though he would be limited to what he could do once connected. However, it was an easy way the get the apps working quickly, and over the past few years the name of the game was speed-speed-speed!
_________________
Cheers,
Larry
MQ Certifiable |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Jan 14, 2004 8:14 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| RatherBeGolfing wrote: |
...however the way we "got around" the security issues was to assign a generic ID that the client apps would use when dealing with MQSeries calls, say GENID1. Then, on the SVRCONN channel on the host (mainframe), I'd put GENID1 in the value of MCA user ID field...
... since anyone who knew the generic id could code a program to access the mainframe queue manager and objects, even though he would be limited to what he could do once connected... |
No need to know about GENID1, just the name of the SVRCONN, Hostname and port the listener runs on is enough...
Michael |
|
| Back to top |
|
|
| calauza |
| Posted: Fri Jan 16, 2004 9:55 pm Post subject: |
|
|
Newbie
Joined: 13 Jan 2004
Posts: 6
|
Larry,
Thank you for your remarks, it's a good idea to specify a dedicated user id for the MCA user ID field on the mainframe definition of the channel. Thank you very much for your help, good luck.
Kind regards,
Gabriel |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
