| Author |
Message
|
| mverh |
 Posted: Wed Mar 13, 2002 9:46 am Post subject: |
 |
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
| I have a requirement to map a data field from a Cobol MRM message to a element in an XML message but the data field contains illegal XML characters. To get around this I propose I xform the data field to it's hex equivalent. To do this I need a hex function or ESQL that does this...does anyone have an example...I want to avoid a plugin node if at all possible... |
|
| Back to top |
|
 |
| jfluitsm |
| Posted: Thu Mar 14, 2002 1:37 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
When you does mean with illigal XML characters the tag characters (<>&" and '), I would expect that the parser would translate these to their &..; values, apparently it doesn't.
It looks like the only thing you can do is breaking down the old string and building a new string with these charaters replaced.
Does anyone know whether IBM knows about this shortcoming of the XML parser?
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| mverh |
| Posted: Thu Mar 14, 2002 11:06 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
By illegal characters I don't mean & < ' > etc...I mean x'00' x'OC' and numerous others that are EBCDIC related...
My problem is I have a 50 byte key that is in a MRM format that is a reply from a CICS txn...these 50 bytes may contain many char, packed decimal, binary data fields...the permutations are many...their purpose is to allow a continuation of a search...we don't need to manipulate them but rather send them to the requester in the XML response so they can echo them back if they choose to continue the search...so what I would like to do is get the HEX eqivalent of these 50 bytes put them in the XML response sent to the requester and then if they echo them back in order to continue the search I can go from the 100 HEX to the original 50 bytes... |
|
| Back to top |
|
|
| Coz |
| Posted: Thu Mar 14, 2002 11:06 pm Post subject: |
|
|
Apprentice
Joined: 20 Feb 2002
Posts: 44
Location: Basel CH
|
| Have you tried simplay CASTing the field as a String? I ask this because it sounds similar to the way I handle the MSGId and CorrelId which are 48Byte Streams. Try a trace and see if the field in the trace is represented by HEX if it does chances are this will work the same way as the Correl Id and Msg Id do. |
|
| Back to top |
|
|
| jfluitsm |
| Posted: Fri Mar 15, 2002 7:25 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
Interesting problem you have here. As I am also interested in Mainframe/MQSI problems, I tried some options and think I have the solution.
I have the following topology:
AS/400 with MQ V5.2, remote Q to input queue on W2K broker
W2K with MQ V5.2.1 and WMQI V2.1
I defined a message set with CWF and XML bindings.
I defined a message with 2 fields:
Field1 binary, 10 bytes.
Field2 string, 10 bytes.
In a ComputeNode I transformed the message from CWF to XML (for some reason this doesn't work with a RCD).
Input message on AS/400 was:
AAAAAAAAAABBBBBBBBBB
Output message on NT was:
<?xml version="1.0"?>
<!DOCTYPE MRM PUBLIC "www.mrmnames.net/DO3JLMK082001" "DO3JLMK082001">
<!--MRM Generated XML Output on :Fri Mar 15 16:06:57 2002-->
<MRM xmlns="www.mrmnames.net/DO3JLMK082001">
<Message>
<Field1><![CDATA[c1c1c1c1c1c1c1c1c1c1]]></Field1>
<Field2>BBBBBBBBBB</Field2>
</Message>
</MRM>
I don't know whether something simular can be done in V2.0.
Please let me know if this will help you with this problem.
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| mverh |
| Posted: Fri Mar 15, 2002 4:23 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
Thanks for the replies...the CAST I'll try it and see what I get since my MRM field is a COBOL PIC X of field I am curious as to how WMQI will manipulate it...I would be surprised since if does the same as it does with the MsgId and CorrelId since they are MQBYTE which is equivalent to a BINARY field in COBOL...the second post makes sense since the MRM field was defined as binary...this makes me think if I redefine the search keys in the copybook as binary then I may get around the need for the HEX function...question is how do I go back from the HEX representation to the binary...
I have also looked at storing the search keys in a database and generating a unique key using the UUIDASCHAR function and sending this to the requester...however I am hesitent since this will impact my throughput... |
|
| Back to top |
|
|
| jfluitsm |
| Posted: Sat Mar 16, 2002 6:01 am Post subject: |
|
|
Disciple
Joined: 24 Feb 2002
Posts: 160
Location: The Netherlands
|
I didn't tried to send the key back, but I suppose it will work ok.
The WMQI BINARY field is not the same as a COBOL BINARY field.
The WMQI BINARY field is a field of x bytes containing data which shouldn't be converted to other CCSID's.
The COBOL BINARY field is a field of 2, 4 or 8 bytes representing a numeric value and can be converted from little-endian to big-endian vv.
See 'Working with messages' chapter 5 for default mappings for COBOL.
_________________
Jan Fluitsma
IBM Certified Solution Designer WebSphere MQ V6
IBM Certified Solution Developer WebSphere Message Broker V6 |
|
| Back to top |
|
|
| mverh |
| Posted: Mon Mar 18, 2002 9:16 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
| If there is no equivalent to the MQBYTE datatype in Cobol then I don't see how the suggestion above would work. WMQI and MQ treat MQBYTE datatypes as you state WMQI returning hex representation and MQ doing no conversion in DQM. What I would need is to have WMQI treat my search key as MQBYTE which seems something that won't be achievable. I will go down the UUID and database road now. |
|
| Back to top |
|
|
| mverh |
| Posted: Thu Mar 28, 2002 2:29 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
| Update to let everyone know I resolved this problem quite easily...the field was defined in the cobol copybook as PIC X(nn)...this is interpretted by WMQI as a STRING datatype which by definition has constraints on the set of characters that may be in the field...our m/f guys were not playing by these rules (see earlier posts)...so I went into the MRM and redefined the datatype to BINARY and as a result WMQI treated the contents as a BLOB...so it didn't try and convert it and when I copied it to an XML element WMQI gave me the hex representation which is valid XML...thanks to evryone who responded... |
|
| Back to top |
|
|
|
|
