| Author |
Message
|
| philip.baker |
 Posted: Mon Sep 09, 2002 3:27 pm Post subject: Problem getting WMQIV2.1 flow to accept MQSIV1.1 message. |
 |
|
Voyager
Joined: 21 Mar 2002
Posts: 77
Location: Baker Systems Consulting, Inc. - Tampa
|
I am trying to replace MQSIV1.1(NEON) processing with WMQIV2.1 flows without requiring any changes to the frontend or backend system programs.
WMQI Unit test of a message placed on the queue using the RFHUTIL utility with an RFH1 header works fine with the WMIQV2.1 flow. (Everything done from Windows.)
The current MQSIV1.1 flow receiving a live message from the MainFrame works fine (running in a V2.0.1 environment from the MQSIRuleng.exe).
WMQIV2.1 flow receiving a live message from the MainFrame gets put back on the Input Queue. (Message is routed to the InputNodes failure terminal but can not be placed on the Output Queue.)
Using MQV5.2.1 CSD04 and WMQIV2.1 CSD02 and a couple of e-fixes.
All MQSI/WMQI processing is being done in Windows 2000. (NEON is not configured in the latest environment.)
For some reason, WMQI is having a problem after taking the message off the Input Queue. The first node wired to the Out teminal of the InputNode is a ComputeNode that is to DETACH the RFH1 as its not needed. But, the following trace indicates the flow does not get to the ComputeNode.
I have nothing set in the InputNode expect for the Input Queue name.
I have played with setting the Convert option and different combos of Encoding and CCSIDs and Message Domains (Using nothing or BLOB).
The same message structure that works being sent from the MainFrame to the currently running NEON processing, will not even start to be processed by WMQIV2.1.
First I get error 2110 - MQRC_FORMAT_ERROR and after the BackoutThreshold of the Input Queue is exceeded and the message is routed to the Failure teminal, it gets error 2334 - RFH_ERROR. The message then goes and is placed back on the Input Queue and the backout count is incremented. (There is no Backout Requeue queue defined.)
I simply want the WMQIV2.1 flow to drop the RFH1, set a message set with a RCD and perform some other processing. I have been able to do this before with RHF1 input messages coming from a UNIX machine. Not sure where the problem is here.
Trace node placed between the InputNode and Output node wired to the failure terminal of the InputNode follows: (${Root})
---------------Beginning of Trace Output
(
(0x1000000)Properties = (
(0x3000000)MessageSet = 'D451-APPL'
(0x3000000)MessageType = 'IF-TME-MAINT-REC'
(0x3000000)MessageFormat = ''
(0x3000000)Encoding = 785
(0x3000000)CodedCharSetId = 0
(0x3000000)Transactional = TRUE
(0x3000000)Persistence = FALSE
(0x3000000)CreationTime = GMTTIMESTAMP '2002-09-09 19:02:29.880'
(0x3000000)ExpirationTime = -1
(0x3000000)Priority = 0
(0x3000000)ReplyIdentifier = X'000000000000000000000000000000000000000000000000'
(0x3000000)ReplyProtocol = 'MQ'
(0x3000000)Topic = NULL
)
(0x1000000)MQMD = (
(0x3000000)SourceQueue = 'BAC.D451.MAINT.MQSI'
(0x3000000)Transactional = TRUE
(0x3000000)Encoding = 785
(0x3000000)CodedCharSetId = 500
(0x3000000)Format = 'MQHRF '
(0x3000000)Version = 2
(0x3000000)Report = 0
(0x3000000)MsgType = 8
(0x3000000)Expiry = -1
(0x3000000)Feedback = 0
(0x3000000)Priority = 0
(0x3000000)Persistence = 0
(0x3000000)MsgId = X'c3e2d840d4d8e3f14040404040404040b834bf202eee9542'
(0x3000000)CorrelId = X'000000000000000000000000000000000000000000000000'
(0x3000000)BackoutCount = 534
(0x3000000)ReplyToQ = 'BAC.D401.INQ.FROMTS2 '
(0x3000000)ReplyToQMgr = 'FEN2TMQ1 '
(0x3000000)UserIdentifier = '$krh '
(0x3000000)AccountingToken = X'0ff8f0f0f1fff9f7fffffffff0f0f0f100000000000000000000000000000000'
(0x3000000)ApplIdentityData = ' '
(0x3000000)PutApplType = 2
(0x3000000)PutApplName = '$KRHBAC5 '
(0x3000000)PutDate = DATE '2002-09-09'
(0x3000000)PutTime = GMTTIME '19:02:29.880'
(0x3000000)ApplOriginData = ' '
(0x3000000)GroupId = X'000000000000000000000000000000000000000000000000'
(0x3000000)MsgSeqNumber = 1
(0x3000000)Offset = 0
(0x3000000)MsgFlags = 0
(0x3000000)OriginalLength = -1
)
(0x1000000)MQRFH = (
(0x3000000)Version = 1
(0x3000000)Encoding = 785
(0x3000000)CodedCharSetId = 0
(0x3000000)Format = 'MQSTR'
(0x3000000)Flags = 0
(0x3000000)OPT_APP_GRP = 'D451-APPL'
(0x3000000)OPT_MSG_TYPE = 'IF-TME-MAINT-REC'
)
(0x1000000)NEON =
------------------End of trace output
Thanks in advance for any input or thoughts.
Regards,
Phil |
|
| Back to top |
|
 |
| vmcgloin |
| Posted: Mon Sep 09, 2002 11:53 pm Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Hi, I think the 2334 (MQRC_RFH_ERROR) is to do with letting something (the RFH CCSID?) default to a value that is now invalid (0?). Have you upgraded MQ too. We had this problem when moving from MQ 5.1 to MQ5.2, and had to change apps to setup this field correctly.
I am not sure if that is exactly your problem but that is where you should start looking...
Regards,
Vicky |
|
| Back to top |
|
|
| jhalstead |
| Posted: Mon Sep 09, 2002 11:55 pm Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
This could be down to the CCSID value '0' in the MQRFH header. As of version 5.2 of MQSeries the old '0' default is no longer acceptable. Instead -2 is required to inherit the ccsid of the local qmgr...
The latest csd04 fixes this by implementing the following.
IY25774 - MQSeries Integrator requires that an RFH can have a
CCSID of 0 under certain circumstances. This apar
allows this to occur by using an environment variable
"AMQ_NO_CHECK_RFH_CCSID".
Probably worth shot?!
Jamie |
|
| Back to top |
|
|
| jhalstead |
| Posted: Mon Sep 09, 2002 11:56 pm Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
| Beat me to it by 2 minutes Vicky! |
|
| Back to top |
|
|
| philip.baker |
| Posted: Tue Sep 10, 2002 9:09 am Post subject: |
|
|
Voyager
Joined: 21 Mar 2002
Posts: 77
Location: Baker Systems Consulting, Inc. - Tampa
|
Thanks much Vicky and Jamie. Good catch. 
Looks like this may fix my issues since the old system the V1.1 stuff is running on is using MQSeries V5.1.
I found the APAR listed in the memo.ptf file of MQV5.2.1 CSD04 and would like to set the variable on the Windows machine as a System Variable.
I found no other doc. about using AMQ_NO_CHECK_RFH_CCSID.
What do you suggest the Value be for this variable? T or 1 or Y?
I can't simply add the Variable name without a value.
Regards,
Phil |
|
| Back to top |
|
|
| pauline_coffey |
| Posted: Thu Dec 05, 2002 3:24 am Post subject: |
|
|
Novice
Joined: 05 Dec 2002
Posts: 15
Location: Dublin, Ireland
|
Philip,
Did using this environment variable fix the problem? I have just encountered the same issue having updraded MQSeries from 5.1 to 5.2.
Thanks,
Pauline. |
|
| Back to top |
|
|
| philip.baker |
| Posted: Thu Dec 05, 2002 10:11 am Post subject: |
|
|
Voyager
Joined: 21 Mar 2002
Posts: 77
Location: Baker Systems Consulting, Inc. - Tampa
|
Pauline,
Yes, adding the Variable Name AMQ_NO_CHECK_RFH_CCSID to the environment (from Control Panel->System->Advanced Tab-> Environment Variables->System Variables) and setting the Variable Value to 1 has resolved the issue I was having. This was done on all Brokers running on Windows 2000 platforms.
_________________
Regards,
Phil |
|
| Back to top |
|
|
|
|
