| Author |
Message
|
| lung |
 Posted: Mon Jan 16, 2012 7:38 pm Post subject: Default value in HexBinary |
 |
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Hi,
I am trying to figure out what kind of values are acceptable in the default value box for HexBinary type.
(Properties -> Logical Properties -> Local Element)
I have tried 00, x'00', <U+00>, all of them do not seem to work.
(Broker will throw exception type mismatch)
Anyone?
Thanks! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jan 16, 2012 8:44 pm Post subject: Re: Default value in HexBinary |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| lung wrote: |
Hi,
I am trying to figure out what kind of values are acceptable in the default value box for HexBinary type.
(Properties -> Logical Properties -> Local Element)
I have tried 00, x'00', <U+00>, all of them do not seem to work.
(Broker will throw exception type mismatch)
Anyone?
Thanks! |
Have you tried '00' ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lung |
| Posted: Mon Jan 16, 2012 10:03 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Yep, tried that as well.
Anyway I read from here
http://www-01.ibm.com/support/docview.wss?uid=swg1IC43680
That default values are not supported for HexBinary type... But this article is from WMB5, any idea if it has changed?
EDIT: Another issue I am facing now is, if the HexBinary is defined as 2 bytes, but in the ESQL I am only mapping 1 byte, WMB will throw an exception and unable to automatically pad x'00' as the remaining byte.
This happens only in TDS, in CWF it will automatically pad.
Need help!  |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 17, 2012 3:01 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
There is a reason why the MRM parser does not support default values for hexBinary - it is very rarely required. There is usually an alternative solution.
What exactly does your message flow do? Why do you need a default value for this hexBinary field? |
|
| Back to top |
|
|
| lung |
| Posted: Tue Jan 17, 2012 3:32 am Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Hi,
The message flow is actually parsing from XML to MRM, where the receiving program is residing on a mainframe.
The program is receiving an amount field in hex format, where for example the field is 4 bytes in length, and if I send over 10 dollars it should appear as x'00000010'.
The simple solution is to just define this field as a HexBinary type, and in the ESQL we can just map directly.
However, the problem arise when I need WMB to automatically pad the x'00' values in the event that the front end sends in the value without the leading zeroes because:
1) In TDS, HexBinary does not support default values
2) In CWF, HexBinary will automatically pad x'00' but as trailing zeroes
A workaround will be define the field as STRING, then in the ESQL, CAST it in the appropriate CCSID (500 for mainframe).
In this case, another problem arise here is that in the event there is no value sent over, I still need WMB to pad x'00' values, and I have no idea how to put this in the default value box? (If I put x'00', it will come out as exact text "x'00")
Sorry for the long winded explanation, please help. 
Thanks! |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 17, 2012 3:54 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
That's a very fragile way to send data - as you are finding out. Some questions for you:
a) This hexBinary field looks like a BCD number. Where is it coming from? Do you have a specification for that incoming hexBinary field?
b) ...and are you sure that a direct conversion to a BLOB on the output side will always work?
| Quote: |
| The simple solution is to just define this field as a HexBinary type, and in the ESQL we can just map directly. |
Actually it is not really very simple, as you are finding out.
| Quote: |
| A workaround will be define the field as STRING, then in the ESQL, CAST it in the appropriate CCSID (500 for mainframe). |
No! This is *binary* data. How do you know that is can be converted to a string without causing a data conversion error? If it is a string, then make the sender send it as a string.
Bottom line: you should ask the sending application to send this amount as a properly formatted text number. (like '10'). Then configure your MRM physical format to write it out as a 4-byte BCD ( or whatever ) number. |
|
| Back to top |
|
|
| lung |
| Posted: Tue Jan 17, 2012 5:29 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Hi,
a) The amount example is just an example, there are other fields which has similar requirements to be sent in hexBinary format, eg. an ID number sent in from front end as "123A" will need to be sent to the back end as x'123A'.
b) The CAST solution has been working fine over the years, because the receiving programs are always on the same machine (CCSID 500), but you are correct that if the message is to route to another system, then the 'hardcoding' of the CCSID will need to be changed. This is what I am trying to avoid.
I am unable to send as STRING because the requirement is to send as hex format. The receiving programs are all very old and the client side has stated that they will not alter their program to accommodate this.
Also, there are over 1000 messages with these fields, so I do not have the luxury of time to separate which field is 'amount' and which is for other purposes. Basically I need a 'one size fits all' solution for this.  |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jan 18, 2012 2:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Thanks for the explanations. It makes a little more sense now.
Correct me if I am wrong, but this is what I think you are saying:
- There is a legacy mainframe application that wants to communicate with another legacy mainframe application on another machine
- Currently, the sending application ( or some other 'adapter' application ) is dividing the COBOL records into fixed-length BLOBs, turning the BLOBs into text and creating XML messages from the text BLOBs
If that is true then it is a fragile and unmaintainable solution.
Almost everyone else does it this way:
1. sending application sends the COBOL records direct to WMB
2. WMB message flow developer imports the COBOL copybook to create a message definition for the incoming record.
3. The input node uses the MRM parser + message definition to parse the incoming COBOL record
4. The message flow adds or changes the message tree according to the business requirements
5. The message flow developer creates a message definition for the receiving COBOL application in the same way as in step 2.
6. The output node converts the message tree to a properly-constructed COBOL record using the MRM parser and the output message definition. |
|
| Back to top |
|
|
| lung |
| Posted: Wed Jan 18, 2012 4:40 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Hi,
No, that is not what I meant...
Actually the incoming msgs are XML, it is the outgoing msgs that is going to legacy.
And in these outgoing messages, there are fields in hex format which can be used for Amount, ID, and etc.
Also, the incoming length for these fields may be shorter than the defined length in the MRM.
Basically the problem is:
When I use TDS with fixed length, and I need WMB to automatically pad the remaining length... How do I do it? As far as I know, HexBinary does not support default values.
Sorry if this is getting confusing, the more I think of this the more I am confused myself  |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jan 18, 2012 11:17 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The second part of Kimbert's last reply still holds true.
Get the copybook that the Legacy system is expecting. Import it and create a messageset from it.
Then you will be able to see exactly what those 'hex' fields mean in terms of Legacy Cobol Speak.
As alluded to earlier if they are an amount then that are probablt BCD encoded. This will show up in the definitions contained in the copybook.
What does EBCIDIC stand for?
EBCDIC = Extended Binary-Coded Decimal Interchange Code
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 19, 2012 3:58 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Actually the incoming msgs are XML, it is the outgoing msgs that is going to legacy. |
I know. But it looks as if they are coming from a legacy system. Somebody seems to have had the ( not very clever ) idea that it makes sense to send unconverted binary data via an XML message.
If I'm right, then you are now paying the price for that decision.
| Quote: |
| And in these outgoing messages, there are fields in hex format which can be used for Amount, ID, and etc. |
Except that they can't be used directly - and the fix-up is proving very tricky. You see my point?
I repeat my previous advice. If at all possible, change the sending application so that it sends text numbers and text strings in normal XML Schema lexical formats. Get ( or create ) the copybooks for the receiving application, import them to create a message set, and use the message set for the output side. |
|
| Back to top |
|
|
| lung |
| Posted: Thu Jan 19, 2012 4:18 am Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Hi,
The incoming message is actually XML in clear text, for example:
<XML>
<FieldA>123</FieldA>
</XML>
It is the receiving program that is expecting hexBinary form.
Still have yet to get the copybook from the client, I am curious myself as to how they check the message. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 19, 2012 4:37 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Ah! My apologies. I completely misunderstood your description of the input XML format.
In that case your flow is a perfectly straightforward XML -> COBOL transformation.
- Stop all of this hexBinary trickery - CWF can do all that stuff automatically.
- Parse the input using XMLNSC. Ideally, get or create an XSD to describe the input XML and enable validation.
- Create the copybook for the receiver and import it. Or else set up the CWF physical format to do what you require.
- Set the fields in OutputRoot.MRM and let CWF do all of the logical value->physical format conversions for you.
Report back with any issues that you encounter. |
|
| Back to top |
|
|
|
|
