| Author |
Message
|
| dieter |
 Posted: Mon Jul 01, 2002 11:53 pm Post subject: RCD Version 2.1 |
 |
|
Newbie
Joined: 01 Jul 2002
Posts: 6
|
 We are currently using MQSI 2.01 and are trying to convert our flows to Version 2.1!!!
The different behavior of WMQI in parsing MRM's is causing us problem's. Currently the RCD node will parse a message and will either pass it thru the out terminal (when successful) or the failure terminal. Where successful means the message has the right length and the fields are matching the right properties(Integer, string etc). But under 2.1 the RCD node accepts anything accept false node properties. If I try to address a field in a following node WMQI will only check that field. Do I have to check every field in a compute Node to be sure that I process the right message set ??? |
|
| Back to top |
|
 |
| CodeCraft |
| Posted: Tue Jul 02, 2002 3:47 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
Okay, so you have message X. You put it through an RCD to convert it to message Y. You now want to parse Y against definition MRM.Y to ensure that bitstream for Y is valid for MRM.Y?
To force a full parse, you could try:
a) A trace of ${Root}
b) A second RCD node. Before the second RCD node, change the Properties.CodeCharSetId to something different (you can change it back later). This will mean the RCD would have to completely reparse and rewrite the message contents and will therefore identify any issues with it.
You are falling foul of the 2.1 lazy parsing which will only parse what it needs, not everything in the message. |
|
| Back to top |
|
|
| dieter |
| Posted: Tue Jul 02, 2002 3:08 pm Post subject: |
|
|
Newbie
Joined: 01 Jul 2002
Posts: 6
|
Our procedure is Input Node, RCD (reset all properties), jump to Label (SubFlow), RCD (in Subflow), Compute Node, OutputNode. The first RCD node is required to reset content to BLOB. The second RCD is setting the properties for MRM.Y but it could be MRM.YY.
A trace ${Root} is not practical we would write to much data to a file/log and we are already doing your second option without success!! |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Jul 02, 2002 5:17 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
You can get rid of the first RCD node. Change your MQInput node to read messages as BLOB.
So your message flow would look like this,
MQInput (read as BLOB)->SubFlow->RCD(MRM)->Compute->MQOutput
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| dieter |
| Posted: Tue Jul 02, 2002 5:29 pm Post subject: |
|
|
Newbie
Joined: 01 Jul 2002
Posts: 6
|
| This is not possible because we are using RFH2 |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Jul 02, 2002 6:32 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
May be I am missing something. Do you have following processing:
1. Your input message has MQRFH2 header. (First message format definition embeded)
2. Your MQInput node is configured to read message as ??
3. In first RCD node you reset domain to BLOB. (Remove first message format definition?)
4. In second RCD node, in a subflow, you change values for MessageSet,...etc (apply second format).
5. Another Compute node. (doing message transformation to Third message format?)
6. MQOutput node writing to output queue.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| dieter |
| Posted: Tue Jul 02, 2002 7:16 pm Post subject: |
|
|
Newbie
Joined: 01 Jul 2002
Posts: 6
|
kirani,
Yes that is exactly our processing
1. This is a reply from the host (Cobol program can't access RFH2 header) with an RFH2 header that has the wrong message type. Reply with original RFH2 header send to HOST
2. Because RFH2 header present WMQI is not looking for the input Message domain.
3. Yes we are resetting to BLOB (could be removed in 2.1)
4. True
5. Yes, translating the message for client (XML). We will only access those fields which the client requires
6. True |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Tue Jul 02, 2002 11:30 pm Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
Dieter,
as CodeCraft suggested, use Trace node with trace pattern=${Root} to force parsing of the entire message. Set trace destination=None - so no output will be created.
Another way to force parsing is to refer to the very last field in the message, for example in a Filter node. |
|
| Back to top |
|
|
| dieter |
| Posted: Wed Jul 03, 2002 12:17 am Post subject: |
|
|
Newbie
Joined: 01 Jul 2002
Posts: 6
|
Miriam,
Thanks, I think "destination=None" will do the job.
The behavior of 2.01 and 2.1 is not compatible and that is the real problem !!
Thanks again |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Wed Jul 03, 2002 2:11 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
Dieter,
in principle, late parsing is a good thing because it speeds up performance. But documentation should detail this behaviour and what needs to be done to get the same results as in previous releases! |
|
| Back to top |
|
|
|
|
