Author |
Message
|
hhoang |
Posted: Thu Jan 05, 2006 2:19 pm Post subject: CompCode: 2, Reason: 2035 |
|
|
Novice
Joined: 14 Nov 2002 Posts: 21
|
I am trying to send a message to the mainframe. MQ Server is also installed on the mainframe. I installed the latest MQ Client software on my Windows XP development box. I added my user account to the mqm group also.
Here is my C# Code - I am using Windows Application
try
{
MQMessage message = new MQMessage();
message.Format = MQC.MQFMT_STRING;
MQQueueManager queueManager = new MQQueueManager(queueMgrName,channelName, mqServerName);
message.WriteString(DateTime.Now.ToLongDateString());
MQQueue queue = queueManager.AccessQueue(queueName, MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING);
queue.Put(message);
queueManager.Disconnect();
}
catch(Exception ex)
{
throw ex;
}
Here is the error code return:
CompCode: 2, Reason: 2035
Here is the error on the mainframe:
+CSQX208E -QETA CSQXRESP Error receiving data, 625
channel CLIENT.TO.QETA,
connection 110.192.8.164
(queue manager ????)
TRPTYPE=TCP RC=00000461
+CSQX599E -QETA CSQXRESP Channel CLIENT.TO.QETA ended abnormally
Our MCAUSER id set to blank.
MCA user ID . . . . . . . . :
I used the same code above to send message to another system without any problems.
I have another java apps that has no problem of either sending or receiving message to and from the same queue.
Can you please help. |
|
Back to top |
|
 |
EddieA |
Posted: Thu Jan 05, 2006 3:28 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Have you tried searching for 2035. You'll find all the information you need.
Cheers _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
kevinf2349 |
Posted: Thu Jan 05, 2006 3:55 pm Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
If the 'mainframe' you are trying to communicate with is z/OS then once you have resolved the 2035 you may want to chack that you have the Client Attach Facility installed or you ain't going to succeed anyway.  |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Jan 05, 2006 4:59 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
kevinf2349 wrote: |
If the 'mainframe' you are trying to communicate with is z/OS then once you have resolved the 2035 you may want to chack that you have the Client Attach Facility installed or you ain't going to succeed anyway.  |
Wouldn't the fact that he gets a 2035 prove the CAF is there? Otherwise he would get a 2059. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
kevinf2349 |
Posted: Thu Jan 05, 2006 5:32 pm Post subject: |
|
|
 Grand Master
Joined: 28 Feb 2003 Posts: 1311 Location: USA
|
Quote: |
kevinf2349 wrote:
If the 'mainframe' you are trying to communicate with is z/OS then once you have resolved the 2035 you may want to chack that you have the Client Attach Facility installed or you ain't going to succeed anyway.
Wouldn't the fact that he gets a 2035 prove the CAF is there? Otherwise he would get a 2059. |
Whoops....You are probably correct.  |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jan 05, 2006 7:49 pm Post subject: Re: CompCode: 2, Reason: 2035 |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
hhoang wrote: |
Here is the error code return:
CompCode: 2, Reason: 2035
Here is the error on the mainframe:
+CSQX208E -QETA CSQXRESP Error receiving data, 625
channel CLIENT.TO.QETA,
connection 110.192.8.164
(queue manager ????)
TRPTYPE=TCP RC=00000461
+CSQX599E -QETA CSQXRESP Channel CLIENT.TO.QETA ended abnormally
Our MCAUSER id set to blank.
MCA user ID . . . . . . . . :
I used the same code above to send message to another system without any problems.
I have another java apps that has no problem of either sending or receiving message to and from the same queue.
Can you please help. |
Unlike java c# really uses the C implementation under the covers.
What does this mean?
THERE IS NO SECURITY HOLE WITH A BLANK MCAUSER in C.
The C client will pass the Logged in (Windows) user anyway.
You will need to set the MCAUSER on the channel to make it work.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
EddieA |
Posted: Thu Jan 05, 2006 11:31 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Quote: |
You will need to set the MCAUSER on the channel to make it work |
And open up the "security hole" to everyone who uses the channel. Come on now, fjb_saper, make people think about the "real" way to handle security.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Jan 06, 2006 4:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
EddieA wrote: |
make people think about the "real" way to handle security. |
I think getting into SSL and client certs is a little much for the original poster at this stage in their learning... And I'm sure proper network access controls are way outside their responsibility, too. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
zpat |
Posted: Fri Jan 06, 2006 5:35 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Make sure the Windows userid name is set up as a RACF id on the mainframe.
Make sure that RACF id has the necessary MQ resource access on RACF.
The security rules (resulting in a 2035) are checked on the server, not the client.
Look at the z/OS system log for ICH408I messages. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jan 06, 2006 12:55 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
jefflowrey wrote: |
EddieA wrote: |
make people think about the "real" way to handle security. |
I think getting into SSL and client certs is a little much for the original poster at this stage in their learning... And I'm sure proper network access controls are way outside their responsibility, too. |
Thanks Jeff, my sentiments exactly.
I did not tell him to make the MCAUSER be MQM. Any Zos user with the correct authority (no more, no less) would do (you need to set up the security for that user obviously). And it would avoid the nightmare of setting up the windows user in Zos.
I did not specify which channel. An intelligent approach is to create a dedicated channel for the app. The MCAUSER on the channel has just the authority needed to run the app.
Of course it will allow any body else using the channel to run the app but you do not need to broadcast which channel you are using...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
oz1ccg |
Posted: Sat Jan 07, 2006 5:30 am Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
Maybe it would be a wise idea to protect the SVRCONN with a security exit.....
There are various ways of strengths from SSL, userid/password to just filtering.... and various products some for free and some that require a lot of $$$...
Have a look on BlockIP2 and the description
BlockIP2 manual
-- Lock it or Lose it --  _________________ Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
Back to top |
|
 |
hhoang |
Posted: Mon Jan 09, 2006 9:40 am Post subject: CompCode: 2, Reason: 2173 |
|
|
Novice
Joined: 14 Nov 2002 Posts: 21
|
The MQ Admin put his user ID in the MCA user field and now I am able to access the queue. Now, I have a problem putting the message to the queue. Do you have any ideas?
Here is the code:
Code: |
try
{
MQMessage message = new MQMessage();
message.Format = MQC.MQFMT_STRING;
MQQueueManager queueManager = new MQQueueManager(queueMgrName,channelName, mqServerName);
MQQueue queue = queueManager.AccessQueue(queueName, MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING);
message.WriteString(DateTime.Now.ToLongDateString());
MQPutMessageOptions options = new MQPutMessageOptions();
options.Options = MQC.XYZ;
//error occurred right here.
queue.Put(message, options);
queueManager.Disconnect();
}
catch(Exception ex)
{
throw ex;
} |
Here is the error I get: CompCode: 2, Reason: 2173 error
I have used all of the following field for the options but nothing works.
MQC.MQPMO_DEFAULT_CONTEXT Associate default context with the message.
MQC.MQPMO_FAIL_IF_QUIESCING Fail if the queue manager is quiescing.
MQC.MQPMO_LOGICAL_ORDER* Put logical messages and segments in message groups into their logical order.
MQC.MQPMO_NEW_CORREL_ID* Generate a new correlation id for each sent message.
MQC.MQPMO_NEW_MSG_ID* Generate a new message id for each sent message.
MQC.MQPMO_NONE No options specified. Do not use in conjunction with other options.
MQC.MQPMO_NO_CONTEXT No context is to be associated with the message.
MQC.MQPMO_NO_SYNCPOINT Put a message without syncpoint control. Note that, if the syncpoint control option is not specified, a default of no syncpoint is assumed. This applies to all supported platforms.
MQC.MQPMO_PASS_ALL_CONTEXT Pass all context from an input queue handle.
MQC.MQPMO_PASS_IDENTITY_CONTEXT Pass identity context from an input queue handle.
MQC.MQPMO_SET_ALL_CONTEXT Set all context from the application.
MQC.MQPMO_SET_IDENTITY_CONTEXT Set identity context from the application.
MQC.MQPMO_SYNCPOINT Put a message with syncpoint control. The message is not visible outside the unit of work until the unit of work |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jan 09, 2006 9:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Did you verify the things listed in the description for the 2173 return code?
Did you try figuring out, from the descriptions of the MQPMO options, which ones were the ones that made sense for your application? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
hhoang |
Posted: Mon Jan 09, 2006 10:27 am Post subject: |
|
|
Novice
Joined: 14 Nov 2002 Posts: 21
|
Quote: |
Did you verify the things listed in the description for the 2173 return code? |
I did this one but seem now help. Here is what the manual said "Put-message options structure not valid. " I don't understand this at all. The MQ admin told me to use this MQPMO_STRUC_ID as an option but this option is not available in MQC
Quote: |
Did you try figuring out, from the descriptions of the MQPMO options, which ones were the ones that made sense for your application? |
I have no clue...I just used all but nothing works. |
|
Back to top |
|
 |
javagate |
Posted: Mon Jan 09, 2006 10:29 am Post subject: |
|
|
 Disciple
Joined: 15 Nov 2004 Posts: 159
|
zpat wrote: |
Make sure the Windows userid name is set up as a RACF id on the mainframe.
Make sure that RACF id has the necessary MQ resource access on RACF.
The security rules (resulting in a 2035) are checked on the server, not the client.
Look at the z/OS system log for ICH408I messages. |
I second this. This sounds absolutely correct. _________________ WebSphere Application Server 7.0 z/OS &
MQ 6.0. I work with WebSphere in the real world not in some IBM lab. |
|
Back to top |
|
 |
|