CPYTOIMPF with RMVBLANK(*BOTH) or RMVBLANK(*TRAILING) leaves a space

[SunShineCA]

We have a field defined as ALWNULL and we compiled our RPG/LE program
with ALWNULL(*USRCTL). If the field contains spaces, CPYTOIMPF with
RMVBLANK(*BOTH) inserts a single space rather than to trim all spaces
to make it null. We're using tilda (~) as a field delimeter, so
instead of seeing ~~ we get ~ ~. Can someone help us please? The
CPYTOIMPF we're using on V5R4 is: CPYTOIMPF FROMFILE(X) TOSTMF(Y)
MBROPT(*REPLACE) STMFCODPAG(*PCASCII) RCDDLM(*CRLF) STRDLM(*NONE)
RMVBLANK(*BOTH) flddlm('~')

[CRPence]

On 12/16/10 1:48 PM, SunShineCA wrote:
> <<SNIP off-topic mention of RPG/LE and ALWNULL>>

>
> If the field contains spaces, CPYTOIMPF with RMVBLANK(*BOTH) inserts
> a single space rather than to trim all spaces to make it null. We're
> using tilda (~) as a field delimeter, so instead of seeing ~~ we get
> ~ ~. Can someone help us please? The CPYTOIMPF we're using on V5R4
> is: CPYTOIMPF FROMFILE(X) TOSTMF(Y) MBROPT(*REPLACE)
> STMFCODPAG(*PCASCII) RCDDLM(*CRLF) STRDLM(*NONE) RMVBLANK(*BOTH)
> flddlm('~')

I am not sure of what should transpire, but I can see that there
would be a problem for the import if the export were allowed to pass the
expected ~~ [the null string delimited by tilde]; i.e. the ~~ indicates
"the NULL value" was exported from the database TABLE. If the data just
exported by a utility can not then be imported as the same set by the
same\partner import utility, then that would certainly be a problem;
i.e. seems likely, leaving the space\blank is the expected effect, to
ensure the import understands the export.

Regards, Chuck

[CRPence]

As I had alluded above, the "round-trip" would fail for the a
combination of export [CPYTOIMPF] and import [CPYFRMIMPF] if the blank
was omitted, thus causing the import to interpret the two delimiters
with no data as being the NULL value [versus being interpreted as the
null string].

See the APAR SE35948 with PTF SI33894 on c9321540 for how to enable
the added function of the export feature [using *DTAARA QCPZEROLEN] to
produce null-string output irrespective of effecting ambiguity for the
same effect for the database NULL value output:

http://www-01.ibm.com/support/docview.wss?uid=nas26b3c19fe077b70c2862575070042022c

Regards, Chuck