| Author |
Message
|
| alaychem |
 Posted: Wed Feb 10, 2016 5:39 am Post subject: Working with base64Binary on DFDL |
 |
|
Acolyte
Joined: 10 Feb 2016
Posts: 66
|
Hello all
In our company, we immigrated from WMB 7 to IIB 9.
On WMB, we have a MXSD containing a base64Binary field, that Message set field is used by MQ node to serialize BLOB field and send it to Z/Os.
I am having trouble with building an equivalent of this message set in DFDL (in the COBOL copy this field is PICX).
When trying with DFDL, I'm getting the BLOB hexa as string (f0f0f1f4 etc.) rather than getting it parsed.
I tried adding the xs: Binary or xs: hexBinary but the DFDL will not compile. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Feb 10, 2016 6:52 am Post subject: Re: Working with base64Binary on DFDL |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| alaychem wrote: |
Hello all
In our company, we immigrated from WMB 7 to IIB 9.
On WMB, we have a MXSD containing a base64Binary field, that Message set field is used by MQ node to serialize BLOB field and send it to Z/Os.
I am having trouble with building an equivalent of this message set in DFDL (in the COBOL copy this field is PICX).
When trying with DFDL, I'm getting the BLOB hexa as string (f0f0f1f4 etc.) rather than getting it parsed.
I tried adding the xs: Binary or xs: hexBinary but the DFDL will not compile. |
Why are you building the DFDL manually. Did you not import the COBOL copy book? HexBinary is exactly what you are getting ... that does not match your copy book that requires binary... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| timber |
| Posted: Wed Feb 10, 2016 8:36 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| When trying with DFDL, I'm getting the BLOB hexa as string (f0f0f1f4 etc.) rather than getting it parsed. |
It's difficult to display a string of raw bytes, so the debugger or a Trace node will display it as a string of hexadecimal numbers. That doesn't mean that it was parsed incorrectly.
Although...looking at your next comment, maybe you specfied it as xs:string, which would explain why it appears as a string in the message tree...
| Quote: |
| I tried adding the xs: Binary or xs: hexBinary but the DFDL will not compile. |
xs:hexBinary is supported by DFDL. Please quote the error that you are receiving. It will appear in the message tree as a BLOB.
xs:base64Binary is not supported by DFDL but you can easily convert from a BLOB to base64Binary. |
|
| Back to top |
|
|
| alaychem |
| Posted: Wed Feb 10, 2016 9:39 pm Post subject: |
|
|
Acolyte
Joined: 10 Feb 2016
Posts: 66
|
thank you for your replies
@ saper I do actually imported the copy. The thing is, that the copy is defined to the equivalent of string.
On WMB 7 some dude that worked in my spot ages ago defined manually the field as base 64 and it caused the MQ put node to "parse" the hex to chars.
I try to get the same effect from the DFDL, or alternatively do it manually.
I've tried to leave the DFDL field as string and cast the contant to CHARCTHER with ESQL but it didn't do the trick.
@ timber I still have the WMB 7 module running, and I get different output.
As I said to saper, on WMB the field is getting "parsed" while on DFDL it stays hex.
I didn't add "xs:string"...
"xs:hexBinary" is unrecognized and "xsd:hexBinary" gets "An element may not have both a type and anonymous type" |
|
| Back to top |
|
|
| timber |
| Posted: Thu Feb 11, 2016 1:28 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
OK - let's get the facts clear:
1. PICX is COBOL's representation of a string of characters. If you want to send base64 to/though a COBOL program then PICX is exactly the right choice, because base64 is text. So the DFDL COBOL importer is doing the best that it can do. It cannot know that the content of the PICX is base64.
2. The solution adopted for WMBv7 was correct. The MRM parser supports the use of base64Binary. That solution won't work in IIB because DFDL does not support the base64Binary type ( it's rare to find base64 data outside of XML these days ).
Now to deal with your specific points:
| Quote: |
| I try to get the same effect from the DFDL, or alternatively do it manually. |
Not possible. See 2. for the reason.
| Quote: |
| I've tried to leave the DFDL field as string and cast the contant to CHARCTHER with ESQL but it didn't do the trick. |
That sounds wrong. If it is xs:string in the schema then it should already be CHARACTER in the message tree. DFDL ensures that. Why did you think that the CAST was required?
| Quote: |
| "xs:hexBinary" is unrecognized and "xsd:hexBinary" gets "An element may not have both a type and anonymous type" |
You messed up while editing the schema. Nothing to do with DFDL. And you should either use 'xs:' or 'xsd:' consistently throughout your schema. No point in having both defined.
Your last post was hard to understand, btw. It makes sense to communicate clearly, especially when the concepts are tricky. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 11, 2016 5:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Ok so coming from the copy book the field is defined as PIC X(y).
What is the real content of the field: base64 information, binary information?
If the field does contain binary information switching it to xsd:hexBinary might work. If it does contain base64 information, leave it as xsd:string and you'd need to decode it to get to the binary content... (see how to do that in ESQL).
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| alaychem |
| Posted: Thu Feb 11, 2016 9:52 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2016
Posts: 66
|
@timber
| Quote: |
| That sounds wrong. If it is xs:string in the schema then it should already be CHARACTER in the message tree. DFDL ensures that. Why did you think that the CAST was required? |
Yes, you right. I wasn't clear enough. I was trying to get the effect with variuos CCSID casting.
| Quote: |
| You messed up while editing the schema. Nothing to do with DFDL. And you should either use 'xs:' or 'xsd:' consistently throughout your schema. No point in having both defined. |
Well, I've only added xsd:hexBinary to element tag, nothing more, honest.
@ saper
| Quote: |
| (see how to do that in ESQL) |
somehow I competely missed the BASE64ENCODE function, will try on sunday
thank you all |
|
| Back to top |
|
|
| alaychem |
| Posted: Sun Feb 14, 2016 5:43 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2016
Posts: 66
|
@saper
Still, no success, the BASE64ENCODE didn't got the same results as the WMB Messageset bas64binary definition
here is the DFDL element
| Code: |
<xsd:element default=" " dfdl:length="500000" name="fill_7">
<xsd:annotation>
<xsd:appinfo source="http://www.wsadie.com/appinfo">
<initialValue kind="SPACE"/>
</xsd:appinfo>
<xsd:documentation>PIC X(500000) display</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="dfdlCobolFmt:PICX__string">
<xsd:maxLength value="500000"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
|
where should I put xsd:hexBinary ?
Last edited by alaychem on Mon Feb 15, 2016 12:11 am; edited 1 time in total |
|
| Back to top |
|
|
| alaychem |
| Posted: Sun Feb 14, 2016 9:26 pm Post subject: |
|
|
Acolyte
Joined: 10 Feb 2016
Posts: 66
|
Nailed it
| Code: |
<xsd:element default=" " dfdl:length="500000" name="fill_7" lengthKind="delimited" dfdl:representaion="binary" type="xsd:hexBinary">
<xsd:annotation>
<xsd:appinfo source="http://www.wsadie.com/appinfo">
<initialValue kind="SPACE"/>
</xsd:appinfo>
<xsd:documentation>PIC X(500000) display</xsd:documentation>
</xsd:annotation>
</xsd:element>
|
Hoora!!   |
|
| Back to top |
|
|
|
|
