| Author |
Message
|
| rkford11 |
 Posted: Mon Jan 25, 2016 9:27 am Post subject: COMMAREA for variable length message |
 |
|
Partisan
Joined: 06 Jun 2004
Posts: 316
|
We are running IIB v9 fix pack 2 broker and using CICS request node for call to back end service. Response copybook has OCCURS DEPENDING ON field, which sends back a Variable length COMMAREA based on the number of occurrences. If we define a fixed length COMMAREA, response message is throwing parsing errors. How do we define COMMAREA length on the CICS request node for Variable length message.
Thanks |
|
| Back to top |
|
 |
| maurito |
| Posted: Mon Jan 25, 2016 11:30 pm Post subject: Re: COMMAREA for variable length message |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
| rkford11 wrote: |
We are running IIB v9 fix pack 2 broker and using CICS request node for call to back end service. Response copybook has OCCURS DEPENDING ON field, which sends back a Variable length COMMAREA based on the number of occurrences. If we define a fixed length COMMAREA, response message is throwing parsing errors. How do we define COMMAREA length on the CICS request node for Variable length message.
Thanks |
it has been a long time since I used the CICS request node , and indeed CICS. But probably you need to specify a fix length COMMAREA large enough to accommodate the largest response you can get. Then in the 'Response Message Parsing' specify the message properties, for example DFDL, and the model should be such that can cater for variable length messages. |
|
| Back to top |
|
|
| timber |
| Posted: Mon Jan 25, 2016 11:43 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
| Quote: |
| If we define a fixed length COMMAREA, response message is throwing parsing errors. |
Please quote the parsing errors, in full.
Are you sure that the parsing errors are related to the OCCURS DEPENDING ON? I'm no expert on the CICSRequest node, but I would expect that you would do the normal COBOL thing; set the size of the COMMAREA to the maximum you will ever require. The DFDL model ( are you using DFDL? ) will work out the length of the actual data using occursCountKind='expression'. |
|
| Back to top |
|
|
| rkford11 |
| Posted: Tue Jan 26, 2016 8:56 am Post subject: |
|
|
Partisan
Joined: 06 Jun 2004
Posts: 316
|
| timber wrote: |
| Quote: |
| If we define a fixed length COMMAREA, response message is throwing parsing errors. |
Please quote the parsing errors, in full.
Are you sure that the parsing errors are related to the OCCURS DEPENDING ON? I'm no expert on the CICSRequest node, but I would expect that you would do the normal COBOL thing; set the size of the COMMAREA to the maximum you will ever require. The DFDL model ( are you using DFDL? ) will work out the length of the actual data using occursCountKind='expression'. |
Have defined the Maximum length for the COMMAREA Length field, and DFDL for Response Message parsing along with occursCountKind='expression', but still getting
DFDL parsing errors have occurred message
This is occurring in the last record of the Message. Three records above this record in the copybook and which has OCCURS DEPENDING ON are getting parsed fine.
Please let me know what am i missing in the message parsing configuration
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 26, 2016 8:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Use the DFDL tester to examine how the parsing occurs, and what the errors are.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rkford11 |
| Posted: Tue Jan 26, 2016 12:48 pm Post subject: |
|
|
Partisan
Joined: 06 Jun 2004
Posts: 316
|
| mqjeff wrote: |
| Use the DFDL tester to examine how the parsing occurs, and what the errors are. |
DFDL parser parsed data correctly until it encountered Null values (unused COMMAREA section). Message can be parsed without errors if we can dynamically define the commarea, can we do that?
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 26, 2016 12:54 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rkford11 wrote: |
| DFDL parser parsed data correctly until it encountered Null values (unused COMMAREA section). |
Share or debug the error messages you get when it reaches the null values.
Give us some better idea of how your DFDL model is constructed.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| timber |
| Posted: Tue Jan 26, 2016 11:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
Please quote the full text of the error that you are receiving
Have you tried to parse your data using the DFDL Test perspective in the toolkit?
Have you examined the DFDL Trace? ( it is available in the DFDL Test perspective, and from the runtime via a debug-level user trace ) |
|
| Back to top |
|
|
| rkford11 |
| Posted: Wed Jan 27, 2016 1:17 pm Post subject: |
|
|
Partisan
Joined: 06 Jun 2004
Posts: 316
|
| timber wrote: |
Please quote the full text of the error that you are receiving
Have you tried to parse your data using the DFDL Test perspective in the toolkit?
Have you examined the DFDL Trace? ( it is available in the DFDL Test perspective, and from the runtime via a debug-level user trace ) |
The DFDL parser signalled that a processing error occurred.
The message from the DFDL parser is:
'CTDP3002E: Unexpected data found at offset '1647' after parsing completed. Data: '0x00...'.'
Parsing error started after data section, (remaining COMMAREA length after cics data ).
cics data length DEPENDING OCCURS ON in this test case = 1647.
Thanks
Rama Krishna |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 1:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The DFDL trace should show you the complete set of steps leading up to the error. It will tell you the last element successfully parsed. This will allow you to determine what element's configuration is failing to match your data.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rkford11 |
| Posted: Wed Jan 27, 2016 1:37 pm Post subject: |
|
|
Partisan
Joined: 06 Jun 2004
Posts: 316
|
| mqjeff wrote: |
| The DFDL trace should show you the complete set of steps leading up to the error. It will tell you the last element successfully parsed. This will allow you to determine what element's configuration is failing to match your data. |
All the elements are getting successfully parsed, it's the COMMAREA space after the last element (remaining space that had been allocated by COMMAREA Length setting on the CICS node) that's causing the parsing errors.
Thanks |
|
| Back to top |
|
|
| timber |
| Posted: Thu Jan 28, 2016 12:04 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
That's easy to fix, then. Add one more element to the end of your model ( i.e. make it the final child of the root element ). Set its Length Kind to 'Delimited' so that it consumes the remainder of the data.
( I would advise you to set Length Kind to 'End of data' but I don't think that option is supported in IBM DFDL ) |
|
| Back to top |
|
|
| rkford11 |
| Posted: Thu Jan 28, 2016 8:48 am Post subject: |
|
|
Partisan
Joined: 06 Jun 2004
Posts: 316
|
| timber wrote: |
That's easy to fix, then. Add one more element to the end of your model ( i.e. make it the final child of the root element ). Set its Length Kind to 'Delimited' so that it consumes the remainder of the data.
( I would advise you to set Length Kind to 'End of data' but I don't think that option is supported in IBM DFDL ) |
Thanks Timber, that fixed the issue.
Thanks |
|
| Back to top |
|
|
|
|
