| Author |
Message
|
| MQMD1 |
 Posted: Mon May 06, 2013 10:33 pm Post subject: Binary to Decimal Conversion in WMB. |
 |
|
Novice
Joined: 06 May 2013
Posts: 20
|
| How many ways can we convert input binary representation into decimal representation in WMB for eg: 00110100 --> 52. Assuming length of the binary data would vary. |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue May 07, 2013 12:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| How many ways can we convert input binary representation into decimal representation in WMB |
There are several ways to do this. Please explain what your requirement is. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue May 07, 2013 12:32 am Post subject: Re: Binary to Decimal Conversion in WMB. |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Computers just know zeros (0) and ones (1). There is no conversion, the OP ist just talking about different presentations: base2 and base10.
Computers always use base2. Humans use base10. Broker' BLOB Parser represents HEX, which is base16, and makes sense to bring humans and computers closer together 
You likely want to know how to come from 00110100 (or 52) to lets say "A" (the character representation). That is done with code pages. E.g. a parser applies a code page.
Now parsers, that is kimberts main topic (I may hand you over to him from now on). But acutally: Do training, read the info center and the forum and get experienced consultants in.
_________________
Just use REFERENCEs
Last edited by mqsiuser on Tue May 07, 2013 12:45 am; edited 2 times in total |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 12:40 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
@mqsiuser: I think you are making a lot of assumptions there.
| Quote: |
| Broker uses HEX (BLOB), which is base8 |
I don't know what you are trying to claim, but that statement ( as written ) is nonsense. Please explain what you mean. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue May 07, 2013 12:42 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
ups... sorry, I mean RFH-Util uses HEX (which is base 16) (I hadn't finished fixing my post ) and the Broker's BLOB-Parser also does.
Oh, I am actually just writing about basics (of computers)... not so specific to Broker
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 12:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| OK - so back to the main point then. OP wants to know something about broker, but we don't know what the requirement is yet. |
|
| Back to top |
|
|
| MQMD1 |
| Posted: Tue May 07, 2013 12:49 am Post subject: |
|
|
Novice
Joined: 06 May 2013
Posts: 20
|
I want to come from 00110100 ( Binary Representation ) to 52 ( Decimal Representation ) . However , if i do Cast AS Character it gives 4 ( ASCII Representation ) . So
a) Should I write a converter.
b) Can I cast directly.
c) CAN DFDL Message Model be leveraged. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 12:59 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Good - that makes it a lot clearer. The short answers are:
a) no
b) no
c) probably
The binary value 00110100 is 0x34. In ASCII or UTF-8 that maps to the character '4'. So you must be getting a real binary value into your message flow ( not the string '00110100' ).
Please describe what your message flow is doing, and explain exactly where this binary value is coming from ( it is probably part of the input message, but I don't want to assume that ). |
|
| Back to top |
|
|
| MQMD1 |
| Posted: Tue May 07, 2013 1:15 am Post subject: |
|
|
Novice
Joined: 06 May 2013
Posts: 20
|
I have got the DFDL message model which is generating "string '00110100'".
Using ESQL I am converting the string to binary and then to ASCII.
SET B2 = 'B'||''''||InputRoot.DFDL.Message1.MSG_LENGTH||'''' ;
SET OutputRoot.DFDL.Message2.Section0.MSG_LENGTH = CAST (B2 AS CHARACTER CCSID 1208 );
However , Instead of ASCII , conversion needs to be in decimal Representation. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 1:57 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I have got the DFDL message model which is generating "string '00110100'". |
So you are already using DFDL? It would have been useful to tell us that in your first post!! We are not mind-readers, and we cannot see your screen.
It now seems that your input message contains the string value '00110100'. Again, that would have been really useful information for your first post.
DFDL can handle almost any numeric format, and it does read and write bit strings. It does not automatically convert a bit string that is represented as a string of characters into a number. That is a very rare requirement, because it is a very inefficient way to represent a number ( you will use at least 64 bits of data for every byte in the number ).
Your approach is nearly correct - you need to cast the string to the ESQL BIT data type, then cast the BIT to INTEGER. Like this:
| Code: |
DECLARE tempString CHARACTER 'B'||''''||InputRoot.DFDL.Message1.MSG_LENGTH||'''' ;
DECLARE tempBitString BIT CAST (tempString AS BIT );
SET OutputRoot.DFDL.Message2.Section0.MSG_LENGTH = CAST ( tempBitString AS INTEGER); |
One more thing: please can you give some more details about the data format that you are handling? It sounds ... 'interesting'. |
|
| Back to top |
|
|
| MQMD1 |
| Posted: Tue May 07, 2013 2:14 am Post subject: |
|
|
Novice
Joined: 06 May 2013
Posts: 20
|
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 2:39 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Thanks - very interesting.
One question: the 'BUFR' format looks like a normal, efficient binary format. So why is your message flow receiving a very inefficient string-ified version of ( at least one of ) the bit fields? |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 3:01 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Just discussing this with my colleagues; DFDL can handle this format without any need to post-process using ESQL. You need to set the properties of your integer value as follows:
| Code: |
dfdl:representation="text"
dfdl:lengthUnits="characters"
dfd:length="8"
dfdl:textStandardBase="2"
dfdl:textNumberPattern="00000000" |
Can you give it a try? |
|
| Back to top |
|
|
| MQMD1 |
| Posted: Tue May 07, 2013 7:22 am Post subject: |
|
|
Novice
Joined: 06 May 2013
Posts: 20
|
--Code Added --
DECLARE tempString CHARACTER 'B'||''''||InputRoot.DFDL.Message1.MSG_LENGTH||'''' ;
DECLARE tempBitString BIT CAST (tempString AS BIT );
SET OutputRoot.DFDL.Message2.Section0.MSG_LENGTH = CAST ( tempBitString AS INTEGER);
-- Code Ended --
Above code resulted in the below exception :
Unsuitable source bit array length to cast to integer : BIP3222
The operand of a casting operation was of an unsuitable length for it to be cast to the target data type. To cast a bit array to an integer the length of the array must be 64. ( Does this imply 8 bit can not be casted to Decimal ? )
Also dfdl:textStandardBase="2" property is present globaly in the GeneralPurposeFormat.xsd file and not localy. Even when I made the global change there was no impact on the running code. Not sure if the change in the setting was effective. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 07, 2013 7:36 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
Above code resulted in the below exception :
Unsuitable source bit array length to cast to integer : BIP3222
The operand of a casting operation was of an unsuitable length for it to be cast to the target data type. To cast a bit array to an integer the length of the array must be 64. ( Does this imply 8 bit can not be casted to Decimal ? ) |
No. The error message is quite clear. If you want to cast a BIT string to INTEGER then its length must be exactly 64 bits. You can take your 8-bit value and pad it using some ESQL code ( the BIT data type can be manipulated using various string-handling functions in ESQL ).
| Quote: |
| Also dfdl:textStandardBase="2" property is present globaly in the GeneralPurposeFormat.xsd file and not localy. Even when I made the global change there was no impact on the running code. Not sure if the change in the setting was effective. |
Please remember that I have never seen your DFDL schemas. I think you are saying that you already tried using textStandardBase="2". Is that correct?
Have you tested the DFDL model using the DFDL debugger in the toolkit? Did it work in the toolkit?
Have you tried setting the property on the element itself, rather than in the global format block? |
|
| Back to top |
|
|
|
|
