| Author |
Message
|
| rahulk01 |
 Posted: Fri Jan 10, 2020 4:07 am Post subject: Creating a Cobol Comp-3 field from esql |
 |
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
Hi,
I have a requirement where I am generating a file for a COBOL application.
There is an integer field of length 6, which has to be converted to the type 'S9(7) comp-3' before sent out to zOS app.
In the DFDL parser this field has been defined as type <PICS9-Comp3_long> of length 6 and length units as Bytes.
Once this field has been mapped, do I need to convert it to the Comp3 format from the esql code before sending to the mapper to validate?
Thanks in advance... |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Jan 10, 2020 6:19 am Post subject: Re: Creating a Cobol Comp-3 field from esql |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rahulk01 wrote: |
| Once this field has been mapped, do I need to convert it to the Comp3 format from the esql code before sending to the mapper to validate? |
For one thing, I'm interested to know how you'd "convert" it in ESQL; the ESQL code can only see the internal message tree. The serialization according to the DFDL map is only performed on output. 
For another thing, you don't need to convert it. From the definition you've given, it sounds like the DFDL model was built by importing a COBOL copybook, so the serialization will be correct as long as you have z/OS as the target platform (set in the DFDL wizard during import).
I mention that only because (unless I need more  ) an S9(7) COMP-3 on z/OS is 5 bytes not 6.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 10, 2020 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Moved to correct section
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| timber |
| Posted: Sat Jan 11, 2020 1:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1290
|
| Quote: |
| Once this field has been mapped, do I need to convert it to the Comp3 format from the esql code before sending to the mapper to validate |
I think you are using the words 'mapper' and 'validate' in ways that do not make sense for IIB, but I may be missing something. Please can you explain what you mean by 'sending to the mapper to validate'.
As Vitor has already said, you do not need to construct the COBOL physical format in your ESQL. The DFDL parser can both read and write all of the COBOL types. Your ESQL (or your mapping node, or your Java etc) should construct a logical message tree with the correct values and let the DFDL parser construct the output format. |
|
| Back to top |
|
|
| rahulk01 |
| Posted: Sun Jan 12, 2020 1:32 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
| timber wrote: |
| Quote: |
| Once this field has been mapped, do I need to convert it to the Comp3 format from the esql code before sending to the mapper to validate |
I think you are using the words 'mapper' and 'validate' in ways that do not make sense for IIB, but I may be missing something. Please can you explain what you mean by 'sending to the mapper to validate'.
As Vitor has already said, you do not need to construct the COBOL physical format in your ESQL. The DFDL parser can both read and write all of the COBOL types. Your ESQL (or your mapping node, or your Java etc) should construct a logical message tree with the correct values and let the DFDL parser construct the output format. |
Sorry for not being too clear the first time. So basically I need to create an integer field with of length 6 (say it contains the value 123456). But this field in the DFDL parser is defined corresponding to S9(9) Comp 3 (using the copybook). Just wanted to check if my esql node sends out this field with value '123456' of length 6 and the parser will read it properly to validate? I hope I am making sense. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Jan 12, 2020 6:05 am Post subject: Re: Creating a Cobol Comp-3 field from esql |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Vitor wrote: |
| I mention that only because (unless I need more ) an S9(7) COMP-3 on z/OS is 5 bytes not 6. |
I believe that is 4 bytes, for a z/OS signed packed decimal (an entity unto itself) of length 7. Each digit takes up half a byte (3.5 bytes for length 7) and one more half a byte for the sign.
Why did the z/OS operating system feel bloated with memory? It kept packing on its binary integer data. 
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| rahulk01 |
| Posted: Sun Jan 12, 2020 9:42 am Post subject: Re: Creating a Cobol Comp-3 field from esql |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
| tczielke wrote: |
| Vitor wrote: |
| I mention that only because (unless I need more ) an S9(7) COMP-3 on z/OS is 5 bytes not 6. |
I believe that is 4 bytes, for a z/OS signed packed decimal (an entity unto itself) of length 7. Each digit takes up half a byte (3.5 bytes for length 7) and one more half a byte for the sign.
Why did the z/OS operating system feel bloated with memory? It kept packing on its binary integer data. |
You are right, my mistake. It is actually defined as S9(7) comp-3.
So now my question, do I need to do some conversion before sending out to the parser? The field is going to contain the value such as '123456'. Will it be read properly? |
|
| Back to top |
|
|
| timber |
| Posted: Mon Jan 13, 2020 2:23 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1290
|
Once again...DFDL handles the physical format for you. You do not need to do any conversion in your IIB code. Your ESQL simply needs to put the correct logical value in OutputRoot.DFDL.
Hopefully that answers your query. If not, please give an example of the 'conversion' that you are asking about. |
|
| Back to top |
|
|
| rahulk01 |
| Posted: Mon Jan 13, 2020 2:56 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
| timber wrote: |
Once again...DFDL handles the physical format for you. You do not need to do any conversion in your IIB code. Your ESQL simply needs to put the correct logical value in OutputRoot.DFDL.
Hopefully that answers your query. If not, please give an example of the 'conversion' that you are asking about. |
Thanks for your quick response. I am actually doing the entire development in the client VDI env and my development runtime is still getting fixed, because of which I am not able to do any testing/debugging at the moment.
I will go ahead as advised by you, and once my runtime issues are fixed, will do some test to see if it works.
Thanks again for your help |
|
| Back to top |
|
|
| timber |
| Posted: Mon Jan 13, 2020 4:06 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1290
|
| And I assume that you managed to get those COBOL dates parsed (http://www.mqseries.net/phpBB2/viewtopic.php?t=76938&postdays=0&postorder=asc&start=15)? |
|
| Back to top |
|
|
| rahulk01 |
| Posted: Wed Jan 15, 2020 1:10 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
| timber wrote: |
| And I assume that you managed to get those COBOL dates parsed (http://www.mqseries.net/phpBB2/viewtopic.php?t=76938&postdays=0&postorder=asc&start=15)? |
Thanks for all your help. My dev got fixed and just tested the parser against my esql generated output and it works.
This is another interface so I started another thread to discuss it. The other one (which you mentioned in your previous comment), is still not tested, as I had to move to another higher priority interface.
But with your inputs in that thread, I was able to create the parser and test against the sample message generated using a text editor, and that works as well.
I have one more thing to ask though.
My file is going to have to have header and a trailer record.
The first byte in the header record is supposed to contain Hex low value i.e. x00 and the first byte of the trailer record will contain hex high value i.e. xFF.
The field representing this byte in the DFDL parser is configured as a string of length 1 byte.
From esql, how do I set this field to Hex values so it gets parsed through the parser.
I have tried something like:
SET rTrailer.INDIKATOR = 0xFF;
SET rTrailer.INDIKATOR = CAST(0xFF AS BLOB);
But both of them failed at parsing, as the above Hex gets converted into a higher length string.
I even tried to define the parser field as hexBinary, but that did not work either.
Looking for your help again.
You guys rock!!!
Cheers |
|
| Back to top |
|
|
| timber |
| Posted: Wed Jan 15, 2020 2:56 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1290
|
Your INDIKATOR field is a string so the correct ESQL datatype for that element is CHAR. You need to specify its value to be a 1-character string with byte representation 0x00. This should work:
| Code: |
| SET rTrailer.INDIKATOR = CAST(x'00' AS CHAR CCSID OutputRoot.Properties.CodedCharSetId); |
Obviously, make sure that OutputRoot.Properties.CodedCharSetId is correctly set before trying that! |
|
| Back to top |
|
|
| rahulk01 |
| Posted: Tue Jan 21, 2020 2:25 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
| timber wrote: |
Your INDIKATOR field is a string so the correct ESQL datatype for that element is CHAR. You need to specify its value to be a 1-character string with byte representation 0x00. This should work:
| Code: |
| SET rTrailer.INDIKATOR = CAST(x'00' AS CHAR CCSID OutputRoot.Properties.CodedCharSetId); |
Obviously, make sure that OutputRoot.Properties.CodedCharSetId is correctly set before trying that! |
Thanks, and it works.
Now in one particular field, I have to set x'FF' and the CCSID being used is 1208. While casting, I am getting an error:
Text:CHARACTER:SET rFileTrailer.W_TRN_INDIKATOR = CAST(X'ff' AS CHARACTER CCSID 1208);
RecoverableException
File:CHARACTER:/build/slot3/S1000_P/src/DataFlowEngine/ImbRdl/ImbRdlTypeCast.cpp
Line:INTEGER:260
Function:CHARACTER:SqlTypeCast::evaluate
Type:CHARACTER:
Name:CHARACTER:
Label:CHARACTER:
Catalog:CHARACTER:BIPmsgs
Severity:INTEGER:3
Number:INTEGER:2521
Text:CHARACTER:Error while casting
Insert
Type:INTEGER:5
Text:CHARACTER:.Test821_Compute.MapFileTrailer
Insert
Type:INTEGER:5
Text:CHARACTER:5.39
Insert
Type:INTEGER:5
Text:CHARACTER:X'ff'
Insert
Type:INTEGER:5
Text:CHARACTER:CHARACTER
RecoverableException
File:CHARACTER:/build/slot3/S1000_P/src/CommonServices/ImbConverter.cpp
Line:INTEGER:637
Function:CHARACTER:ImbConverterCPP::internalToUnicode
Type:CHARACTER:
Name:CHARACTER:
Label:CHARACTER:
Catalog:CHARACTER:BIPmsgs
Severity:INTEGER:3
Number:INTEGER:2135
Text:CHARACTER:Unconvertable character
Insert
Type:INTEGER:5
Text:CHARACTER:ff
Insert
Type:INTEGER:5
Text:CHARACTER:ff
Insert
Type:INTEGER:2
Text:CHARACTER:1208
Just curious to know if x'FF' is not part of CCSID 1208 characters.
One more thing, this field is defined in the DFDL parser with length 1 byte, but it throws an error saying insufficient length. When I put the length to 2 byte, it works. All this works with CCSID 437. But I have to use 1208, with which it just doesn't work irrespective of the length.
Thanks |
|
| Back to top |
|
|
| timber |
| Posted: Tue Jan 21, 2020 5:26 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1290
|
|
| Back to top |
|
|
| rahulk01 |
| Posted: Tue Jan 21, 2020 7:30 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
Thanks for the hints, I was able to parse x'FF' with length 1 Character (changed it from byte), thanks for your hint.
But still not able to use x'FF' with CCSID 1208.
Actually we are replacing an existing old system sending feeds to some mainframe applications. We are building a new payments platform which is built on IIB. So we have been asked to use the same CCSID as other IIB flows while interacting with Mainframe. There are other IIB flows using 1208, so I thought of using the same CCSID. Hope it makes sense. |
|
| Back to top |
|
|
|
|
