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.
Jeff Olen is a member of the AS/400 development team at Gauss Interprise, a content management software company located in Irvine, California. He can be reached by email at jeff.olen@gaussvip.com.
|
