| Author |
Message
|
| shassey |
 Posted: Thu Jan 31, 2002 7:57 pm Post subject: |
 |
|
Apprentice
Joined: 25 Dec 2001
Posts: 25
Location: shassey
|
I have a flow which I am sending a file from a legacy system where the file contains detail records for which I have defined a message set and it has a trailer record which has a slightly different record layout though it is the same length - I have defined a message set for that also.
I am not sure what I am doing wrong
- the input node has the detail message set and type defined
- I first put the resetcontentdescriptor off the failure terminal of the input node assuming that it would sense the different layout. didn't work
- I then put a check node with the message set and type of the detail record in it's properties so if the input layout were the detail it should go through the match terminal and then I wired the check node's failure terminal with a reset content descriptor to handle the trailer record.
- What seems to be happening is the trailer record is flowing through these as if it were the detail and it flows to the compute node where I am parsing what I had hoped to be the detail record. What I had to do was put the resetcontentdescriptor node off the failure terminal of that compute node and then the trailer happily went that route and I was able to do with the trailer what I wanted. Unfortunately this also raises an exception that there is invalid data because the compute node wants it to be the detail format.
I am running mqsi version 2.02 with csd01 applied. What am I doing wrong? I suspect I am missing something but not sure what.
Thanks for any help or ideas you may have. |
|
| Back to top |
|
 |
| kirani |
| Posted: Thu Jan 31, 2002 8:44 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Do you have any field which tells you what is the record type in the message? Do you have MQRFH2 header in your message?
|
|
| Back to top |
|
|
| shassey |
| Posted: Fri Feb 01, 2002 5:45 am Post subject: |
|
|
Apprentice
Joined: 25 Dec 2001
Posts: 25
Location: shassey
|
No I don't have a MQRFH2 header but there are fields in the record which I can interrogate. I guess I don't understand how the resetcontentdescriptor or check node work - what does the check node do to check the format of the record?
Is it only in a compute node (or database etc) and you look at a field that mqsi knows that it isn't the right format?
I don't want to have to put a mqrfh2 on but what would that do for me?
Thanks for your input!! |
|
| Back to top |
|
|
| kirani |
| Posted: Fri Feb 01, 2002 10:27 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I have never used check node so I dont know much about it.
In your case, Lets say your record length is 99 bytes and first character will tell you the type of record (1- Header, 2-Detail and 3-Trailer). Your message flow will look like this,
MQInput1->Filter1(True terminal)->RCD1->Compute1->MQOutput1
Filter1(False terminal)->RCD2->Compute2->MQOutput1
In your MQInput node(MQInput1) read your message as BLOB. Attach a Filter node (Filter1) to the out terminal of MQInput1.
In Filter node (Filter1) checks for the Detail Record by typing following ESQL,
(SUBSTRING(CAST(Root."BLOB"."BLOB" AS CHAR) FROM 3 FOR 2) = '32')
32 is the HEX value for ASCII '2'.
Similarly you can check for Trailer record in Filter2 by typing following ESQL,
(SUBSTRING(CAST(Root."BLOB"."BLOB" AS CHAR) FROM 3 FOR 2) = '33')
33 is the HEX value for ASCII '3'.
True terminal of Filter1 node is connected to RCD1 node where you can apply actual MRM parser for Detail record. False terminal of Filter1 is connected to Filter2. True terminal of Filter2 is connected to RCD2 node where you parse your trailer record.
In Compute1 and Compute2 you can transform detail and trailer records respectively. Output of these nodes are connected to MQOutput1. This way you can apply different parsers for different records. There are many other ways of doing the same thing. I found this easier.
Hope this helps.
Kiran
|
|
| Back to top |
|
|
| Paul D |
| Posted: Mon Dec 09, 2002 6:23 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
FYI - This works well also and you can skip the ASCII values by converting it using the CCSID setting in the cast:
DECLARE theRawInd BLOB;
DECLARE theIND CHARACTER;
-- Code for using the message name element
SET theRawInd = SUBSTRING(Body."BLOB"."BLOB" FROM 1 FOR 4);
SET theInd = CAST(theRawID AS CHAR CCSID Root.MQMD.CodedCharSetId); |
|
| Back to top |
|
|
|
|
