Hello,
While developing and testing an open-source IBM i code coverage extension, I came across a behavior in the IBM i `QDEVTOOLS/CODECOV` command that I would like to understand better.
The issue occurs when code coverage is generated using `*SOURCE` as the source option.
### Environment
* `QDEVTOOLS/CODECOV`:
* Source compiled with `DBGVIEW(*SOURCE)`
* Coverage generated using `CODECOV`
* Job CCSID: [65535] Inherited from the QCCSID system value
### Steps to reproduce
1. Create an RPG program/source member whose source name contains a character that is not represented the same way in the job CCSID. For example, a source name containing `ñ`. `ÑRPGSRC`
2. Compile the program with `DBGVIEW(*SOURCE)`.
3. Execute the program/tests normally. `CALL PGM(TEST_PGM)`
4. Run `QDEVTOOLS/CODECOV`, specifying `*SOURCE` so that the coverage information is associated with the original source: `CODECOV CMD(CALL PGM(TEST_PGM)) MODULE((TEST_PGM *PGM *ALL)) CCVIEW(*SOURCE)`
5. Inspect the generated `.cczip` file.
### Actual result
The `CODECOV` command completes without reporting an error, but the resulting `.cczip` does not contain the ` src` folder with the coverage information. It does not contain the expected coverage information.
This is particularly difficult to diagnose because the command appears to complete successfully; there is no obvious error indicating that the source name or CCSID caused the coverage data generation to fail.
### Workaround
I found that changing the job CCSID to 37 before running `CODECOV` allows the coverage data to be generated correctly.
For example:
CHGJOB CCSID(37)
After doing this, the character in the source name is converted and the `.cczip` is generated correctly.
However, I don't consider this a safe general workaround.
Changing the job CCSID can also affect character conversion within the application being tested. In some programs, this can cause characters in business logic/data to be converted unexpectedly and can even result in application errors.
Therefore, changing the job CCSID is not something I can reliably do before every coverage execution.
### Expected result
I would expect `CODECOV` to either:
1. correctly generate the coverage data when `*SOURCE` is specified, regardless of special characters in the source name, or
2. provide a clear diagnostic if the source name cannot be resolved because of a CCSID/character conversion issue.
Silently producing an `.cczip` file without `src` folder makes the problem particularly difficult for consuming tools to detect.
### Question
Is this a known limitation or issue with `CODECOV` when using `*SOURCE` and source names containing characters that are not represented in the job CCSID?
Could the source name be handled using the CCSID associated with the source rather than the job CCSID, or is there another recommended configuration for this scenario?
I'm happy to provide additional reproduction information or test results if useful.
Thanks!