| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| DFDL parser for unbounded records with delimited fields |
« View previous topic :: View next topic » |
| Author |
Message
|
| timber |
 Posted: Thu Jan 02, 2020 8:58 am Post subject: |
 |
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
re: your previous question:
| Quote: |
| the requirement for me is to define a variable length amount field which would be followed by amount sign i.e. + or -. Padding of 0s at the front is also not accepted, so the only way to identify that the amount has ended is by the way of it's sign |
That answer worries me. COBOL never expects the programmer to search for a delimiter - it always defines the data type so that it is obvious, or else defines the length. DFDL supports all of the COBOL datatypes, including all of the platform-specific variants so it should be possible to work out which COBOL type this is, and specify that data type for the field.
I strongly advise you to stop trying to work out what the rules are. You will never succeed by looking at example messages. Instead, ask the system owners tell you what the rules are, and get them to sign off that specification. The ideal way (as Vitor and fjb_saper have said) is to get the copybook. Second best is to get a written specification for the format, including all parsing rules. |
|
| Back to top |
|
 |
| rahulk01 |
| Posted: Thu Jan 02, 2020 10:24 am Post subject: |
|
|
Apprentice
Joined: 26 Dec 2019
Posts: 35
|
| timber wrote: |
| Quote: |
I have used the check as
{./RECORD_IDENTIFIER eq 'B' AND fn:contains(./ANTALL_BYTES, '082') ne TRUE}
but I am getting an error saying Xpath exression ... contains a path location that does not resolve to an element in th schema. |
I think it is risky to write that expression without parentheses to force your intended evaluation order. I would write it thus:
| Code: |
| {./RECORD_IDENTIFIER eq 'B' AND (fn:contains(./ANTALL_BYTES, '082') ne TRUE)} |
Also, most programmers would use the NOT function instead of writing ' ne TRUE'. |
Not to offend anyone here, I'll rephrase myself: Old cobol code being supported by new team who does not have any idea where the copybook is and not too familiar with the standards on their messages. So basically due to absence of copybook, we are building and defining the standards of these messages as we go. We have been given a specification for the message, but it not very elaborate.
{./RECORD_IDENTIFIER eq 'B' AND (fn:contains(./ANTALL_BYTES, '082') ne TRUE)} does not work either, still getting the same error as what I wrote earlier. I used NOT initially but that was throwing error, so thought of using 'ne'. I don't know if this kind of statement is even allowed within a discriminator.
My current statement looks like '<dfdl:discriminator>{./RECORD_IDENTIFIER eq 'B' AND (fn:contains(./START_OF_RECORD/ANTALL_BYTES, '082') ne TRUE)}</dfdl:discriminator>' but it does not work.
Well, there is one more thing I need help with. This DFDL will be used to validate the message generated by IIB before sending it out to Mainframe.
One of the DateTime field is being mapped in IIB as Integer in DDMMYY format, but is expected in Mainframe as a S9(7) comp-3. Is it something I can achieve using DFDL? If yes, how?
This forum has been a great help so far and I appreciate all the inputs. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 02, 2020 11:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rahulk01 wrote: |
Not to offend anyone here, I'll rephrase myself: Old cobol code being supported by new team who does not have any idea where the copybook is and not too familiar with the standards on their messages. So basically due to absence of copybook, we are building and defining the standards of these messages as we go. We have been given a specification for the message, but it not very elaborate.
|
Ok, so I'll just add an opinion here for the record.
You're doomed.
If the supporting team are so unfamiliar with their application (and I accept they didn't write it but they are responsible for it so bad form from them to not get all the documentation and source code from the old team), then it's massively unlikely that they know enough to be able to generate a complete set of possible message formats for you to reverse engineer. At some point (maybe not today, maybe not tomorrow but soon) it's going to spit out something different and your DFDL will either blow or give the wrong results. For which you will be blamed.
It's therefore essential to get sign off from this new team that:
- they don't know how their application works
- they don't know what all the possible message types look like
- if the DFDL blows it's their fault for not doing their jobs properly and getting adequate hand over from the old team.
Take several copies, put one in a safety deposit box and one under the nose of each project manager / project sponsor. One under the supporting team's manager might be fun as well.
| rahulk01 wrote: |
Well, there is one more thing I need help with. This DFDL will be used to validate the message generated by IIB before sending it out to Mainframe.
One of the DateTime field is being mapped in IIB as Integer in DDMMYY format, but is expected in Mainframe as a S9(7) comp-3. Is it something I can achieve using DFDL?
|
Yes.
| rahulk01 wrote: |
If yes, how?
|
S9(7) is a mainframe COBOL number; COMP-3 is just the storage method used (COMP-3 is used in 99.99999% of all cases and indicates the number is stored one digit per half byte - often called a nibble!). This example is a decimal 7 digits long with no implied decimal point, i.e. an integer. The conversion is automatic given the equivalence of type, but COBOL of that age should expect YYMMDD, so a spot of transformation may be needed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| timber |
| Posted: Thu Jan 02, 2020 1:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| Not to offend anyone here, I'll rephrase myself |
Not a problem here. We tend to give offence, not take it 
re: the discriminator XPath, the only rules are that the expression must return a Boolean value. Yours does, so it's valid. The problem seems to be that DFDL cannot resolve the path ./ANTALL_BYTES. I cannot comment on that because the XSD snippet that you posted does not show that field. Feel free to supply the missing info and I'll see whether I agree with your XPath.
Alternatively, you could try putting a different path in that position (temporarily) to check whether this is just a misleading error message.
Or again, you could try using an absolute path from the root of the message. I know you tried that at first and failed...but I suspect that you just got the path wrong. Try using the expression builder in the IIB toolkit instead of writing the expression manually.
I will post separately re: the date format issue...I remember that being a specific case that DFDL was designed for. |
|
| Back to top |
|
|
| timber |
| Posted: Thu Jan 02, 2020 1:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
For the date field, you need to
- Change the data type of the field to xs:date
- Change dfdl:representation to 'binary' ( it defaults to 'text' )
- Set binaryCalendarRep as described in the DFDL spec section 13.13
- Set calendarPatternKind to 'explicit'
- Set calendarPattern ( maybe to 'ddMMyy', but please put some thought into that and check the spec)
- Set calendarCheckPolicy to 'strict'
That's off the top of my head, and untested. You may encounter some errors asking you to set other properties when you try this out. If so, check the DFDL spec if necessary and set them to some value that is either useful or harmless
Keep in mind that DFDL can definitely parse this format so don't give up if it doesn't work first time. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
