×
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.
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.
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.
midrange.com
