Re: CAT bug in ILE RPG

>>Has anyone else run across bugs with the CAT operation code in RPG IV? 
>>Using CAT in some situations gives us unpredictable results, such as 
>>fields being concatenated in the wrong order.  (However, if instead we use 
>>EVAL and the plus sign on these same fields to concatenate them, the 
>>program works fine!)
>>
>> field1  CAT  field2:0   resultfld
>>          CAT  field3:0   resultfld
>>             .
>>             .
>>             .
>>          CAT  field9:0   resultfld
>>
>>The above does not work!! 
>>
>>But the following does work (we use %trimr because all 9 fields have 
>>trailing blanks):
>>
>>         EVAL     resultfld=%trimr(field1)+%trimr(field2)+ ...
>>+%trimr(field9)
>  >>
>  >Each of the nine fields that I am concatenating is a 4-byte character 
>  >string containing zero, one, or two numeric characters left-justified, 
>  >and then padded on the right with blanks.  The result field is a 
>  >16-character blank field.
>  >(It just so happens that the 3rd and 9th fields are always blanks.)
>  >In this example, in the interest of simplication, I have represented the
>  >numeric contents of the 9 fields with uppercase alphabetic characters, 
>  >and represented the blanks with lowercase "b"s.
>  >
>  >Abbb  CDbb   bbbb   EFbb   GHbb   JKbb   LMbb   NPbb   bbbb
>  >
>  >Per this example, the result field will always contain the following:
>  >
>  >ACDbbGHJKLMNPEFG
>  
______________________________________________________________
>  I have some converted code that uses lots of CATs so I was interested in 
>  this. 
>  When I run this example, my results turn out properly.  I've never had 
>  operations like this go "out of order".   Just to satisfy my curiosity, 
>  I recompiled my code at OPTIMIZE(*FULL) and tried again: worked fine.  
>We're at V4R3, ptf level 98279.  This is clearly an example (i.e.
>  not your production code.)  Are you certain that the fields in your 
>  production code are being CATted in the order you think?  Did the compile 
> fail, and your object code doesn't match the source you're looking at?  
> Dumb questions, but I've only found one compiler bug in 20 years.
>  I always think of the code having a problem before I think of the compiler 
>  having a problem...
>  
>  Buck Calabro
_________________________________________________________________
Thanks, Buck for your response, and that certainly was the prudent thing to do
-- i.e., test your programs given that you use CAT so extensively.  Your
questions are not dumb at all -- my having been in product development for 22
years myself, those would be my first questions too.  But the answer is that
we have concatenated the fields in the correct order, compiled the programs,
switched back to using the EVAL with plus sign, and back again to CAT, several
times.  Always the results are good with EVAL and incorrect with CAT.  And we
have had other problems with CAT in the past that we dismissed at the time,
and/or for expediency's sake had to work around with some other method.  The
BIG difference between your system and ours, it seems, is that we are still on
a CISC box, using V3R2...  By the way, there are several compiler bugs we've
uncovered over the years, especially when I was leading a software development
team for an IBM Business Partner, and so even though compiler/operating system
bugs are always the LAST things we consider in our troubleshooting, it has
happened enough times for me that I never discount it.  

Anyone else who has experienced CAT problems??  We haven't been able to find
any PTF's that address such a bug...
________________________________________________________________
> 
>  I asked around here yesterday to see if any of
>  my colleagues was aware of any problem with CAT,
>  but no-one knew of any.  But today, Barbara came
>  back to me with a possible problem.  What release
>  are you running?  Could you clarify exactly how
>  the fields are declared?  Do any of the fields
>  overlap in any way with field RESULTFLD?  Are
>  some fields declared local to a procedure and
>  other declared global?  Are any fields defined
>  as varying length?
>  
>  BTW, you may be better off anyways using the +
>  operator in an EVAL since it performs much better
>  than a sequence of CATs.
>  
>  Cheers!  Hans
>  
>  Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
___________________________________________________________________
Thanks, Hans for your response.  None of the fields overlap with the result
field.  None of the fields are varying length, and they are all declared
within the RPG program by external file definitions.  I.e., the 9 input fields
come from one file and each is defined as 4A in DDS specs, and are being
output to another file to the 16A field also defined in DDS.  Did I answer
your question sufficiently?  If not, I will be happy to elaborate or clarify.

Also, we are not using any pre-compile utility (such as RPG Free) or /COPY
code in the program -- in fact it is a fairly simple, short program.  We are
at V3R2, at PTF level 97321, and we are current on all hiper PTFs, and we have
performed all procedures necessary for PTFs in error.

John R.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---