Record Generator not generating DAA-compliant code

Thank you for the update on 5/7/2020, and appreciate all the work/pre-work here. The link provided was where I wound up and was stuck on.

. Thanks for the reply. The com.ibm.jzos.fields.DatatypeFactory documents this function as follows: "Instances of this class or its subclasses will automatically construct instances of com.ibm.jzos.fields.daa classes if the com.ibm.jzos.fields.daa package is available at runtime" see https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.zsecurity.api.80.doc/com.ibm.jzos/com/ibm/jzos/fields/DatatypeFactory.html
However, we should also clarify this behavour for the IRG, and I have raised a work item to add this to our Knowledge Center and I suggest we use this RFE to track the requirement to provided byte[] get/setters for numeric fields, which is understood to be a useful optimisation for further integration with the DAA helper classes.

Thanks for the reply. Interestingly did not realize the class does 'leverage DAA under the covers'. So although the class 'get/put' are on BigDecimal objects, the byte conversions are using DAA when enabled.

Did I miss the 'under the covers' in some documentation somewhere? Pointing that out would be helpful to me and possibly others that go down this path.

Interesting second point of using the DAA methods while working with byte buffers, that would required get/set methods to work with the buffers directly, to open up use of DAA post-generation.
Sounds like that would help performance by avoiding BigDecimal math on objects within the generated class.
I currently do not have a use case so far, but over then next year or so there will be 100s of programs being converted and some may benefit from that enhancement.
Would that enhancement need a separate RFE?

Looking at the example supplied, the field IN-SALARY is a precision 17 packed decimal. The COBOLDatatypeFactory in the generated record will detect if DAA is available at runtime and if so will create a DAA-enabled set of instances from com.ibm.jzos.fields.daa package, which will leverage DAA under the covers to optimise the conversion of the byte array numerical fields to and from numerical Java objects. In this example com.ibm.dataaccess.DecimalData.convertPackedDecimalToBigDecimal() will be used to convert the packed decimal data in the byte array to a BigDecimal.
Is this the function that is desired, or do you require the Record Generator to build byte[] getters/setters for each numeric field? This would enable numerical data to be manipulated as byte arrays inorder to enable the DAA helper classes to perform optimised mathemetical functions on byte arrays, such as using com.ibm.dataaccess.PackedDecimal.addPackedDecimal() to add together two packed decimal fields. https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.api.80.doc/com.ibm.dataaccess/index.html

Sorry for the late response, very deep into coding for a major bank's COBOL to Java conversion.

My company will not allow an actual copybook to be shared. What should suffice is any copybook at all that contains COMP-3 data that would then be converted into a BigDecimal regardless of DAA availability via the record generator.

Simple copybook layout my manager put together, as an example contains a COMP-3 field:
01 WS-RECORD.
05 IN-Date PIC X(10).
05 IN-Last-Name PIC X(30).
05 IN-First-Name PIC X(30).
05 IN-SALARY PIC S9(15)V99 COMP-3.

Thanks.