Re: Making sense of 4-byte binary fields -- RPG400-L


On 10/03/2005, at 3:48 PM, James H. H. Lampert wrote:

Anybody have any idea what the RPG designers were smoking when they decided to make it the number of decimal digits, and to actually generate the extra code to clamp it to that specified number of decimal digits?


Two reasons:
        1) Existing data type
        2) Existing precedent

Data type: ----------- Database supports a binary data type as a value with decimal places. It is this same data type that RPG exposes via the B data type. So RPG is just ensuring that it can handle the DB data types in the same manner. B, S, and P data types are defined using digits notation because that makes sense for decimal numbers (and these are all decimal data types). Defining 5 digits with 2 decimal places is easier than the alternative of bytes (which would require each data type to be defined differently). Most RPG III programmers screw up defining packed decimal in a data structure the first time they do it. Imagine the mess if they had to count three different kinds of byte lengths?

Ensuring that values for a B field do not exceed the number of digits specified is exactly the same behaviour as shown by zoned and packed fields. Consistency again.

Why did database decide that binary data types should be decimal? God knows.

Precedent: ---------- When RPG IV came along and they added true binary (i.e., integer) they maintained the tradition of using digits notation. This would have seemed a good idea during design meetings--all numeric fields in RPG would use digits notation. Very consistent. But they forgot about floating point where digits notation is fairly pointless (although DDS gives it a good try). Thus the inconsistency we now see.

Yes, it would have been better to define integers using length notation but they didn't so accept it and get on with things.

The API documentation explains how to code the various API data types in each language but since nobody bothers to read it properly they make mistakes and as long as it "works for me" life goes on--fat, dumb, and happy.

For those who are truly bothered by the current behaviour; when the next RPG IV survey is issued spend some of your $100 on providing dual support. It would be possible for the compiler to support: D tiny S 1I0 D tiny_u S 1U0 D short S 2I0 D short_u S 2U0 D long S 4I0 D long_u S 4U0 D longlong S 8I0 D longlong_u S 8U0

in addition to the current digits notation. No ambiguity between the different syntax (but probably will confuse developers). Waste of development dollars if you ask me but I spent my $100 on overloaded procedures so what would I know.

Just love the C names: we've got short and long (plus char which is really an integer-duh!) so what do we call the next size integer? Well it's a long number but that's taken and it's longer than the long so let's call it a longlong. Puke!

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------