× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, March 09, 2005 9:24 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Making sense of 4-byte binary fields


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


I think you have a good point about the misleading documentation.  Most
other languages specify the integer types by names--e.g. short, int,
long...and leave the number of bits to the implementation.  Fortunately,
it's mostly standardized. I still find myself calculating the number of
bits in an API 4 B to figure out what to use in RPG. (I know, I should
have memorized it by now.)

It's a matter of what you learned first.  I was taught to think of
maximum number you can use in a given signed integer type as
2^(number_of_bits -1).  It makes sense that someone who came up in RPG
would find it easier to think in terms of digits.  One caveat is that 3i
0 doesn't go up to 999 and likewise for the other integer types.  I
still count on my fingers sometimes to find the number of bytes in a
packed field. <g>

It's no worse than having to deal with passing other data types that
don't exist in RPG to another language.  We probably need the DWIM
paramater passing convention.

*****************************
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise 
recorded by
The Sharper Image corporate e-mail system and is subject to archival, 
monitoring,
and review by and/or disclosure to Sharper Image security and other management.
This message is intended only for the use of the addressee and may contain 
information
that is privileged and confidential.

The contents of this message may contain personal views which are not the views 
of The Sharper Image.
If you are not the intended recipient, dissemination of this communication is 
prohibited.
*****************************


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.