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:
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 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


Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online