Author |
Message
|
_Angus_ |
Posted: Wed May 18, 2011 1:37 am Post subject: PCF from v7 to v6 on z/OS |
|
|
 Acolyte
Joined: 25 Apr 2005 Posts: 54 Location: Edinburgh
|
Hi guys,
I have a couple of QueueZee customers in the US having problems connecting to a version 6 z/OS from QueueZee v2.1 that uses MQ v7 Java classes – this works fine from QueueZee v1.3 that uses the MQ v6 Java classes and is the same PCF connection code:
PCFMessageAgent agent = new PCFMessageAgent (host, Integer.parseInt(port), channel);
PCFMessage request = new PCFMessage (CMQCFC.MQCMD_INQUIRE_Q);
request.addParameter (CMQC.MQCA_Q_NAME, "*");
request.addParameter (CMQC.MQIA_Q_TYPE, CMQC.MQQT_ALL);
request.addParameter (CMQCFC.MQIACF_Q_ATTRS, new int []
{ CMQC.MQCA_Q_NAME, CMQC.MQIA_Q_TYPE });
PCFMessage responses[] = null;
responses = agent.send (request);
for (int i = 0; i < responses.length; i++)
{
if (responses[i].getCompCode() != CMQC.MQCC_FAILED)
{
_qNameList.add((responses[i].getStringParameterValue (CMQC.MQCA_Q_NAME)).trim());
_qTypeList.add(new Integer(responses[i].getIntParameterValue (CMQC.MQIA_Q_TYPE)));
}
}
I’ve stripped out my error processing code etc. to just show the important bits – basically in the scenario described above it blows up on the red highlighted line with this:
QueueZee ~ Copyright © 2008-2010, AngusSoft - v2.1 [27-09-2010]
[May 17, 2011 9:30:51 AM] Connecting to Queue Manager CSQ6 (172.29.127.116) ...
[May 17, 2011 9:31:06 AM] Caught MQ Exception: MQRCCF_CFST_PARM_ID_ERROR
[May 17, 2011 9:31:06 AM] Failed (Failed to get Queue list!).
QueueZee: (May 17, 2011 9:29:46 AM) Auto-connecting to Queue Managers if required (use -x to skip this) ...
[QueueZee: STACK-TRACE: May 17, 2011 9:31:06 AM: com.ibm.mq.pcf.PCFException: MQJE001: Completion Code '2', Reason '3015'.
at com.ibm.mq.pcf.PCFMessage.getStringParameterValue(PCFMessage.java:748)
at uk.angussoft.qz.QZQueueManager.getQueueList(QZQueueManager.java:392)
at uk.angussoft.qz.QZQueueManager.connect(QZQueueManager.java:109)
at uk.angussoft.qz.QZMain$QMConnectDialog$ProcessThread.run(QZMain.java:7418)
(extract from the customers QZ command log and debug console)
I’ve trawled the web without much success and without a z/OS QM to test against I’m a bit stuck so if any of the above is something obvious to any of you I would very much appreciate your help
Thanks in advance,
Angus _________________ *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
Back to top |
|
 |
_Angus_ |
Posted: Wed May 18, 2011 7:10 am Post subject: |
|
|
 Acolyte
Joined: 25 Apr 2005 Posts: 54 Location: Edinburgh
|
Oops, just noticed the red highlight didn't happen! The highlighted line is this one:
_qNameList.add((responses[i].getStringParameterValue (CMQC.MQCA_Q_NAME)).trim()); _________________ *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
Back to top |
|
 |
mqjeff |
Posted: Wed May 18, 2011 7:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
What happens if you replace the symbolic constant with the actual correct value? |
|
Back to top |
|
 |
_Angus_ |
Posted: Wed May 18, 2011 8:13 am Post subject: |
|
|
 Acolyte
Joined: 25 Apr 2005 Posts: 54 Location: Edinburgh
|
I'm afraid I don't follow you - why is the constant value wrong in the results list?
I understand the error is complaining about the parameter indicating it's returned more than I bargained for but I'm trying to figure out what that might be and why it's different in z/OS. _________________ *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
Back to top |
|
 |
mqjeff |
Posted: Wed May 18, 2011 8:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
the MQRC says that the CFST parm ID is invalid...
Given that there are a large number of reorganizations and changes/updates to the PCF libraries in v7, it might be that the Java libraries are not resolving constants under CMQC the correct way - perhaps to something that ends up getting endian-swapped when talking to zed...
So using the literal constant *might* avoid that.
otherwise, take a mq client trace and a server trace and examine the message data... could just be a bug in the command server on zed as well.
or, again, the v7 libraries could be putting stuff into the command message that's not valid on v6 zed. |
|
Back to top |
|
 |
_Angus_ |
Posted: Wed May 18, 2011 8:29 am Post subject: |
|
|
 Acolyte
Joined: 25 Apr 2005 Posts: 54 Location: Edinburgh
|
Ah gotcha, that makes perfect sense now and would explain why the result is not the attribute I'm expecting. I was thinking along the lines of another parameter being introduced rather than the originals being parsed incorrectly.
Many thanks for your suggestion - I'll swap in the literals and get my helpful z/OS customer to test  _________________ *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
Back to top |
|
 |
_Angus_ |
Posted: Thu Feb 02, 2012 7:41 am Post subject: |
|
|
 Acolyte
Joined: 25 Apr 2005 Posts: 54 Location: Edinburgh
|
For all interested parties - I have fixed this in QueueZee v2.8 which will be available from http://www.AngusSoft.co.uk sometime next week. _________________ *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Angus Cooke ~ AngusSoft
Integration Development Tools
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
|
Back to top |
|
 |
|