TRANSFORM_LIST to generated CSVs in the IFS

[stevelee67]

i use the TRANSFORM_LIST to generate CSVs that get emailed to users all the time. it's a pretty amazing BIF and it works on both 'doze and IBMi (must be an RDMLX function/component to do this). been doing this since probably version 11.3 or 5. on the IBMi, there was always a conversion step (EBCDIC to UTF8 or ASCII) but i've got some utilities i've written to do that.

well, sometime between 12.1 and 14.1 lansa made these even more useful - they added to ability to force the output to UTF8. non-issue on windoze, but really nice on the IBMi. put a "U" after many of the types (A, O, T, C, and D) and viola, you can skip the conversion step.

i.e.:
USE TRANSFORM_LIST WITH_ARGS(#WL_OUTPUT #W_OUTFILE A) TO_GET(#RECODE)
<call to a utility to code to convert>

can now be done like this:
USE TRANSFORM_LIST WITH_ARGS(#WL_OUTPUT #W_OUTFILE AU) TO_GET(#RECODE)

except...
this doesn't quite work the way i expect with columnar (CU or DU) output.
for some reason - and according to Lansa support, this is by design - the output doubles the size of the output fields...
so, if i have a 5 byte field, the CU or DU output would represent it as a 10 byte field.
example:
working list with 2 fields, on a single byte field, the other a 5 byte field
as a type C, this USE TRANSFORM_LIST WITH_ARGS(#WL_OUTPUT #W_OUTFILE C) TO_GET(#RECODE) gives me the following
AABCDE

as a type CU, this USE TRANSFORM_LIST WITH_ARGS(#WL_OUTPUT #W_OUTFILE CU) TO_GET(#RECODE) gives me this (dots represent blank spaces):
A.ABCDE.....

it doesn't do this with any of the other UTF8 outputs.

so my questions are:

• does this make any sense?
• am i the only person that uses the BIF like this, so i'm the only person that has noticed it?

note that there is a way around it - generate it as a type C and convert it, but it just seems... odd that it works this way.