I confess to using %trim instead of %trimr. I suppose if I were in a different 
environment I would be more sensitive to performance. But when your largest master 
file is 13000 records, a 9999 record subfile loads in less than a second (no 
matter what kind of trim operation is used), and CPU usage might spike to at most 
20-25% during nightly processing, I find it hard to get excited about wasted CPU 
cycles.

ltrim(rtrim(var))

I think I had a problem with trim once -- not even sure what system it was on.
Since it was a test, I used what I knew would work.

Nice to know some people still care about performance and in my opinion just 
good coding habits.

I should have used rtrim, now that I think about it.

I should put on my glasses. :)
Yes, if you nest rTrim(lTrim(var)) you should consider using trim(var) instead.

Bob,

I agree in general. I was just trying to "K-map" this code:
coalesce(ltrim(rtrim(INVC.GREFDT))...

Chris

trim() should only be used if you specifically want to trim blanks from both sides.

RPG programmers tend to use the RPG equivalent %TRIM by justifying it the way
RPG programmers who continue to use Indicators justify using them, by being wrong.

%trim and SQL's trim use at least double the cpu cycles and often twice the
storage as the more accurate %TRIML and %TRIMR functions. That's not to say that
%TRIM doesn't have its place, it does. But I rarely find a situation where %TRIM
applies--"rarely" does not mean never--so I use %TRIMR mostly, %TRIML when
applicable and %trim only when I really do want to trim of both trailing and
leading blanks from a value.

Good to know. And why not use trim() instead of ltrim(rtrim())?

Muehe had it.

My COALESCE fields became variable length fields. 
I don't want variable length fields, so I CAST them.
Problem solved.

Thanks everyone!

Nothing jumps out at me. What is the CCSID of that field in the DB2 file? 37?

Chris

say you have a varible length field
60 varchar
you move a 50 into it (eval)
cpytoimpf will put 50 char in the result. (even with rmv trailing blanks)
trim, i always forget to trim.

try
coalesce(ltrim(rtrim(INVC.GREFDT)),'*** NOT DEFINED') INVTRY_CLASS_DESC,

As I said (maybe not clearly), the fields in the from file have trailing blanks.

Here's the COALESCE:
coalesce(INVC.GREFDT,'*** NOT DEFINED') INVTRY_CLASS_DESC,           

It seems to be working just fine - the field INVTRY_CLASS_DESC has valid data 
in it, followed by trailing blanks:

Invtry_class_desc                                             
LEGEND DRUG INJECTABLES                                       
DCCCDC4CDEC4CDDCCECCDCE444444444444444444444444444444444444444
35755404947095153312352000000000000000000000000000000000000000

But CPYTOIMPF, with the rmvblank(*trailing) keyword, translates those trailing 
blanks to x'00', but just for certain COALESCEd fields:
8500|0|1|LEGEND DRUG INJECTABLES|
FFFF4F4F4DCCCDC4CDEC4CDDCCECCDCE0000000000000000000000000000000000000004
8500F0F1F35755404947095153312352000000000000000000000000000000000000000F

Other fields populated through COALESCE with trailing blanks are processed 
correctly by CPYTOIMPF.

Can't figure it out...

Does the fromfile failing field have blanks or x'00' in it? Display it in hex.
And show us the COALESCE expression. Maybe it's flawed.

Chris

Given the following command:

cpytoimpf fromfile(&ffile) +    
          tofile(&tfile) +      
          rmvblank(*trailing) + 
          strdlm(*none) +       
          flddlm('|')           

It works for the most part, but I am having an issue with a couple of fields 
with trailing blanks.  These fields are not getting the trailing blanks 
removed, but rather each blank is getting replaced with x'00'.

The fields are not nullable.
The fields have valid data prior to the string of x'00' (or x'40'/blank in the 
input file).
These fields are populated through a COALESCE expression (from a LEFT OUTER 
JOINed file).
Other COALESCE fields work properly.
Other fields with trailing blanks are working properly.

What could cause this?