| Author |
Message
|
| kuruks |
 Posted: Fri Jul 30, 2021 10:11 am Post subject: Creating COBOL COMP field |
 |
|
Newbie
Joined: 30 Jul 2021
Posts: 5
|
Hi,
I have a requirement that I need to call the CICS program using the CICS Request node with a COBOL copybook by creating a DFDL.
The COMP field status is showing like PICS9-Comp-short and length is 2 bytes.
When I send the request to CICS with 01 as the data to the COMPM field, when we expedite the CICS program we are seeing +0256 as the data.
Is there something that we need to set at the DFDL properties or can we do anything using SQL to send the exact same data to the CICS?
Thanks in Advance. |
|
| Back to top |
|
 |
| timber |
| Posted: Sat Jul 31, 2021 2:47 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| Is there something that we need to set at the DFDL properties |
Yes, you need to set the byteOrder property.
| Quote: |
| or can we do anything using SQL to send the exact same data to the CICS |
In other integration products that might be the correct answer. In IIB/ACE you should always use the parser to parse/write the data format. ESQL is just for mapping/transformation of the logical values. |
|
| Back to top |
|
|
| kuruks |
| Posted: Mon Aug 02, 2021 5:48 am Post subject: |
|
|
Newbie
Joined: 30 Jul 2021
Posts: 5
|
Hi,
Thanks for your reply.
I tried Byte Order property by changing both littileEndian and bigEndian but no luck. I am seeing the same +0256 as the data in CICS.
Is there any specific DFDL Expression do we need to provide?
Thanks in Advance. |
|
| Back to top |
|
|
| timber |
| Posted: Mon Aug 02, 2021 9:21 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
I would be very surprised if byteOrder is not the solution.
Have you tested the DFDL schema using the DFDL Test perspective? That will be a lot faster than performing end-to-end tests using the CICS program, and will allow you to experiment until you get the correct output. |
|
| Back to top |
|
|
| kuruks |
| Posted: Mon Aug 02, 2021 12:48 pm Post subject: |
|
|
Newbie
Joined: 30 Jul 2021
Posts: 5
|
Yes, When I tested it in Test Perspective, I am getting below error and the value is showing as '12337' for '01' as input.
| Code: |
CTDN3073E: Value '12337' is not facet-valid with respect to maxInclusive '9999' for element 'R113_BOD_LVL'.
ParsedDataRegion[SimpleContent, startOffset = 853, length = 2, scd = #xscd(/type::WSAPPLREQUESTAREA/model::sequence/schemaElement:
:R00113_APPL_AREA/type::0/model::sequence/schemaElement::R00113_BOD_POINTS_TBL/type::0/model::sequence/schemaElement::R113_BOD_LVL)] |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 03, 2021 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This might be a dumb question, but did you ingest the cobol copy book to create your DFDL schema?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kuruks |
| Posted: Tue Aug 03, 2021 11:47 am Post subject: |
|
|
Newbie
Joined: 30 Jul 2021
Posts: 5
|
Hi,
@fjb_saper
Ya, that's obvious, I also feel the same for others' questions if I don't know the solution.
Yes, I created the DFDL by importing the copybook and I am testing it in Test Perspective. I tried by with both bigEndian and littleEndian but didn't work.
Below are the results from different combinations for '01' as the input.
ByteOrder ::::::: Number_Represenatation ::::::: OutPut_Value
littleEndian :::::: binary :::::::::::::::::::::::::::: 12592
littleEndian :::::: ibm4690Packed:::::::::::::::::: 3130
bigEndian :::::::: binary ::::::::::::::::::::::::::: 12337
bigEndian :::::::: ibm4690Packed ::::::::::::::::: 3031
Please let me know if you need any other info. Thanks in advance!! |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Aug 04, 2021 1:07 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Is the data '01' you are providing a numeric value or a character value?
12337 is hex 3031 which is ASCII characters of '01'
12592 is hex 3130 which is ASCII characters of '10'
This seems to suggest you are supplying character data.
Your initial post when you got +0256 at the CICS side, that is hex 0100, which just looks like you gave it little-endian and it expected big-endian.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| kuruks |
| Posted: Fri Aug 06, 2021 6:06 am Post subject: |
|
|
Newbie
Joined: 30 Jul 2021
Posts: 5
|
For testing in DFDL TEST Perspective, I am sending the entire string in a Text file. I am not sure whether it is treating it as a numeric or Character value.
But when I test from the Application, if I send two bytes of data '01' and casting as Integer, I am seeing +256 in CICS, and if I see it in Hex its value showing as 0100 as you mentioned.
my requirement is to see +001 if I send '01' which is equitant to 0010 in hex. How to achieve this? Thanks!! |
|
| Back to top |
|
|
| timber |
| Posted: Fri Aug 06, 2021 7:28 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Bytes are the not the same as characters!
Your testing in the DFDL perspective is not valid unless you testing with exactly the same bytes as the application sends. The DFDL perspective allow you to control the bytes that you send (I don't remember exactly how). Or, a good text editor allows you to create files that contain specific byte sequences.
Please believe me..this is almost certainly a byte order problem. You just haven't found a way to prove it yet. |
|
| Back to top |
|
|
|
|
