RE: Making sense of 4-byte binary fields

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> A poor design decision on IBM's part was in requiring the Integer data type
> to be coded as 3I, 5I, 10I or 20I is the root of the problem. It should have
> been 1I, 2I, 4I, and 8I.  IBM could add this capability without impacting
> existing code--and it would make things much easier to comprehend by those
> still using the "B" data type.

I don't buy this argument! Your whole argument is that the RPG language 
should've been designed to fit the API documentation.

Everywhere else, they refer to "32-bit integers" and "16-bit integers". 
The API docs are the only place I've seen this referred to by a number of 
bytes instead of bits.

Should the RPG team have done this, instead?

     D myNum           s             32I 0

Actually, that way makes more sense if you think about it. All RPG fields 
(except float) are declared according to the number of digits that fit in 
them. Since these are binary fields, 32 is the number of binary digits 
that are stored in them. (Indeed, "bit" is short for "binary digit")

In Windows, 16-bit integers are referred to as "words", and 32-bit 
integers are called "double words".  Maybe they should've made it look 
like this?

     D  myNum          s              WI
     D  myNum          s              DI

Personally, I think the method they chose (specifying the number of 
digits) is as good as any other method. It's probably better, since RPG 
programmers have always defined their fields according to the number of 
decimal digits stored in them.

IMHO, it's the API documentation that throws everyone off.