两个RPGLE里面比较“邪门”的问题

yoyoage

TechTip: RPG Gotchas!
  by Jeff Olen


Caution: Strange program behavior ahead.



Published March 2004

For the better part of two decades, I have been working with RPG. For the most part, I have not run into many really   
strange problems related to the language. I have seen plenty of strange occurrences due to programmer error (and even more due to user error) but not many related to RPG itself. However, in the last few months I've run across two idiosyncrasies (dare I call them bugs?), and I felt they warranted being passed on.



Binary Field Handling (or Lack Thereof)
For those of you who have used or are thinking of   
using binary field types in your RPG programs and/or iSeries files, I would suggest that you think twice. RPG does not handle binary fields well. Take the code below, for instance:





d BinaryFld1      s              9b 0 inz(10)           
c     *like         define    BinaryFld1    BinaryFld2  
c                   eval      BinaryFld2 = BinaryFld1   

When this code is executed, you would expect to have two 4-byte binary fields with the value X'0000000A' in them. But you're going to be disappointed. The actual result of the code is one binary field (BinaryFld1) with the value X'0000000A' in it. The other field (BinaryFld2) will be a 5-byte packed field containing X'000000010F'. This may not seem like a problem at first, but what if you are passing a binary field as a parameter to another program (an API for instance)? Not the end of the world but definitely problematic.

So what about binary fields defined in files? Not any better. If a file field is defined as a binary field, RPG will define it internally as a packed field. Again, consider trying to use a field from a file as a parameter on a call. By the way, this is a very difficult problem to debug because everything looks correct.

Since I feel certain that someone will tell me that I should read the manual, here is a bit of documentation from IBM regarding the binary field handling.

MOVEing on Up (or Down?)
The MOVE opcode is perhaps the most misused opcode of all. There are probably many stories out there of strange behavior. Here's mine.


d Char10a         s             10a   inz('12345ALPHA')      
d Char10b         s             10a   inz('12345STEEP')      
d Signed5a        s              5s 0                        
d Signed5b        s              5s 0                        
c                   movel     Char10a       Signed5a         
c                   movel     Char10b       Signed5b         

So when the code above is executed, you would expect that the SIGNED5A and SIGNED5B fields would both contain the value 12345, right? Wrong. The SIGNED5A field does, but the SIGNED5B field contains -12345. Why? I had to scratch my head for awhile before I figured out what was happening here. RPG is evaluating the entire string as signed numbers. Therefore, if the last character in the string evaluates to a negative number, the result of the MOVE operation will be a negative number. The only alpha characters that evaluate to negative numbers are the capital letters J through R.

Idiosyncrasies or bugs? You decide.