Re: Making sense of 4-byte binary fields

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

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  / \
--------------------------------------------------------------------