ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Creating a Cobol Comp-3 field from esql

Post new topic  Reply to topic Goto page 1, 2  Next
 Creating a Cobol Comp-3 field from esql « View previous topic :: View next topic » 
Author Message
rahulk01
PostPosted: Fri Jan 10, 2020 4:07 am    Post subject: Creating a Cobol Comp-3 field from esql Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jan 10, 2020 6:19 am    Post subject: Re: Creating a Cobol Comp-3 field from esql Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jan 10, 2020 6:20 am    Post subject: Reply with quote

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
View user's profile Send private message
timber
PostPosted: Sat Jan 11, 2020 1:22 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

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
View user's profile Send private message
rahulk01
PostPosted: Sun Jan 12, 2020 1:32 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Sun Jan 12, 2020 6:05 am    Post subject: Re: Creating a Cobol Comp-3 field from esql Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
rahulk01
PostPosted: Sun Jan 12, 2020 9:42 am    Post subject: Re: Creating a Cobol Comp-3 field from esql Reply with quote

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
View user's profile Send private message
timber
PostPosted: Mon Jan 13, 2020 2:23 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

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
View user's profile Send private message
rahulk01
PostPosted: Mon Jan 13, 2020 2:56 am    Post subject: Reply with quote

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
View user's profile Send private message
timber
PostPosted: Mon Jan 13, 2020 4:06 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

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
View user's profile Send private message
rahulk01
PostPosted: Wed Jan 15, 2020 1:10 am    Post subject: Reply with quote

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
View user's profile Send private message
timber
PostPosted: Wed Jan 15, 2020 2:56 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

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
View user's profile Send private message
rahulk01
PostPosted: Tue Jan 21, 2020 2:25 am    Post subject: Reply with quote

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
View user's profile Send private message
timber
PostPosted: Tue Jan 21, 2020 5:26 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1280

You are struggling because you do not properly understand the difference between a byte and a character. I strongly suggest that you read this excellent blog by Joel Spolsky: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

I can solve your problem, but first I need to you to explain why you believe this statement is true:
Quote:
But I have to use 1208
I find that a rather surprising requirement. Do you understand why? (hint: what is the difference between UTF-8 and ASCII?)
Back to top
View user's profile Send private message
rahulk01
PostPosted: Tue Jan 21, 2020 7:30 am    Post subject: Reply with quote

Apprentice

Joined: 26 Dec 2019
Posts: 35

timber wrote:
You are struggling because you do not properly understand the difference between a byte and a character. I strongly suggest that you read this excellent blog by Joel Spolsky: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

I can solve your problem, but first I need to you to explain why you believe this statement is true:
Quote:
But I have to use 1208
I find that a rather surprising requirement. Do you understand why? (hint: what is the difference between UTF-8 and ASCII?)


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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Creating a Cobol Comp-3 field from esql
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.