The transformed COMBTRAN.groovy is not as expected

Question

Problem: The transformed COMBTRAN.groovy is different from the solution. 
Step: Ad hoc Modifications, SORT symbols
Tranform version: 4.2.0

**Trasformed COMBTRAN.groovy:**
.fileSystem("SYSIN")
.stream(" SORT FIELDS=(TRAN-ID,A)                                                  ", getEncoding())
.build()

**Expected result (the solution of COMBTRAN.groovy):**
.fileSystem("SYSIN")
.stream(" SORT FILEDS=(1,16,CH.A)", getEncoding())
.build()

**Troublehshooting done**
1. I verified the version 1 COMBTRAN.jcl and TRANREPT.jcl are used ( not the version 0)
2. I tried to transform several times but had no luck.
3. I move forward on the next step Remove AIX from CICS configuration; I edited the CARDDEMO; the tranformed initJics.sql is missing those INERT INTO FILE TABLE, INSERT INTO PROGRAM.

I can't figure out what is wrong.

re:Post Agent · Answer

The issue you're experiencing with the COMBTRAN.groovy transformation is likely related to how the SORT fields are being interpreted during the transformation process. The difference between the transformed output and the expected result suggests that the transformation engine is interpreting the SORT fields differently than intended.

To address this issue, you might need to make some ad-hoc modifications to the COMBTRAN job or the transformation process:

1. Check the SORT statement in the original JCL to ensure it matches the expected format (SORT FIELDS=(1,16,CH,A)).

2. If the original JCL uses symbolic parameters or variables for the SORT fields, make sure these are properly resolved or handled during the transformation.

3. You may need to add a custom rule or override in the transformation engine to ensure it interprets the SORT fields correctly.

Regarding the missing INSERT statements in the initJics.sql file after editing CARDDEMO, this could be related to how the CSD (CICS System Definition) file is being processed. To resolve this:

1. Ensure the CARDDEMO file type is set to CSDCOMMAND instead of just CSD.

2. After changing the file type, try running the classification again for the entire project scope.

3. Then attempt the transformation process once more.

If these steps don't resolve the issues, you may need to consult with the AWS BluAge support team or the workshop facilitators for more specific guidance, as there might be version-specific considerations or workshop-specific configurations that need to be addressed.

**Sources**  
[AWS BluAge L3 Workshop - Execution - Batch Testing - COMBTRAN(SORT) - Issue | AWS re:Post](https://repost.aws/questions/QU6YFFigxpTrmjl_ZGNNcXcQ/aws-bluage-l3-workshop-execution-batch-testing-combtran-sort-issue)  
[AWS BluAge L3 Workshop - Execution - Test - Batch - COMBTRAN - Issue | AWS re:Post](https://repost.aws/questions/QUva3YLisBT76rDYH_fZ1-Wg/aws-bluage-l3-workshop-execution-test-batch-combtran-issue)  
[L3 Workshop. CSD does not get properly transformed. | AWS re:Post](https://repost.aws/questions/QUdSute3IVQF6JsrUCLCOHsw/l3-workshop-csd-does-not-get-properly-transformed)

Kelvin Yeung AWS · Answer

The problem was that the SORT statement still contained symbolic reference. I double check the COMBTRAN.jcl. I did not update the JCL correctly.

The csd is solved by launching a classification in code base. It is because there is some improvement in file type. Carddemo csd becomes CSDCOMMAD.

The transformed COMBTRAN.groovy is not as expected

Relevant content