Bugfix/LS24004106/MOVEA from Scalar to Standalone array

[davidepalladino-apuliasoft]

Description

This work adds the capability to use MOVEA from a scalar to a Standalone array declared as:

• decimal, with decimal digits greater than number of digits of scalar;
• decimal, with decimal digits lower than number of digits of scalar;
• integer;

Technical notes

Previous this fix, Jariko didn't take into consideration about result type when the second parameter of MOVEA was a scalar. For example:

     D A146            S             14  6 DIM(9) INZ
     C                   MOVEA     123           A146

It constructed the array as integer and not as decimal. More precisely, must be a decimal with number arranged from least significant digit. This problem covered MOVE, MOVEL and EVAL too.
So, now constructs the right array based of type.

Related to #LS24004106

Checklist:

• If this feature involves RPGLE fixes or improvements, they are well-described in the summary.
• There are tests for this feature.
• RPGLE code used for tests is easily understandable and includes comments that clarify the purpose of this feature.
• The code follows Kotlin conventions (run ./gradlew ktlintCheck).
• The code passes all tests (run ./gradlew check).
• Relevant documentation is included in the docs directory.

[lanarimarco]

What I don't like about this solution is that you are addressing, what might be a more serious issue, specifically for MOVEA. I recall seeing the same symptoms in #613, where you fixed the assignment logic in InternalInterpreter.set, which I found to be a good solution.

I'm concerned that if each operation code requires its own implementation for assignment logic from scalar to vector—which should be a common behavior in Jariko—it might take years to cover all possible use cases.

For this reason, you should also try with EVAL and all MOVEx operation codes.

[davidepalladino-apuliasoft]

What I don't like about this solution is that you are addressing, what might be a more serious issue, specifically for MOVEA. I recall seeing the same symptoms in #613, where you fixed the assignment logic in InternalInterpreter.set, which I found to be a good solution.

I'm concerned that if each operation code requires its own implementation for assignment logic from scalar to vector—which should be a common behavior in Jariko—it might take years to cover all possible use cases.

For this reason, you should also try with EVAL and all MOVEx operation codes.

I agree with you. I could check with EVAL and MOVEL too.