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



Peter,

I am not aiming to be "that wiseguy" in the bad meaning of the word, but
I'll philosophise on the subject anyway.

There is a difference between the concrete value of *HIVAL and *LOVAL in
particular situations and the meaning of *HIVAL and *LOVAL. What you are
pointing out is that *HIVAL in case of i-type fields have a concrete
value (which by the way is equal to all bits turned on, except perhaps
for the sign-bit). And that different field-types have different values
is logical, they have different number of bits. If you take a date-field
the *HIVAL would coincide with the value '9999-12-31' the point is that
the _meaning_ of that value is "no concrete value, but something very
high".

If IBM would have had the chance to re-invent the way these were set up
I believe that they would include a special set of bits containing the
indication whether the value is *LOVAL, *HIVAL and *NULL (comparable to
what they did for record-DSs when dealing with nullable fields in a
record). However... they haven't re-invented that so they have invented
the special values of *HIVAL, *LOVAL and in some cases *NULL to convey
the meaning of the value, instead of the concrete implementation of it.
This leaves room for improvement when (if ever) IBM decides to re-invent
EBCDIC and expand the size of bits a bit (3 actually ...pun intended...
You may laugh now).

Cor

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Peter.Colpaert@xxxxxxxxx
Sent: vrijdag 17 augustus 2007 10:13
To: RPG programming on the AS400 / iSeries
Subject: RE: *LOVAL in arithmetic expression

Cor,

I think that *HIVAL and *LOVAL have a very specific meaning in RPG.

Try this:

d hivalint s 10i 0 inz(*hival)
d lovalint s 10i 0 inz(*loval)
d hivalpack s 10p 0 inz(*hival)
d lovalpack s 10p 0 inz(*loval)
/free
Dsply hivalint;
Dsply lovalint;
Dsply hivalpack;
Dsply lovalpack;
Return;
/end-free

When you run this program, here's what you get:

DSPLY 2147483647
DSPLY 2147483648-
DSPLY 9999999999
DSPLY 9999999999-

So when talking about a 10i 0 variable, *HIVAL is not "something very
high", but 2.147.483.648 exactly.

Meaning that "*HIVAL - 1" is also an exact number (2.147.483.647)

Just trying to be a wise guy here ;-)

Peter Colpaert
Application Developer
PLI - IT - Kontich, Belgium
-----
Yoda of Borg are we. Futile is resistance, assimilated will you be.
-----



"Takken, Cor" <cor.takken@xxxxxxxxxxxxx> Sent by:
rpg400-l-bounces@xxxxxxxxxxxx
17/08/2007 10:01
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: *LOVAL in arithmetic expression






And casting *LOVAL or *HIVAL to a more meaningfull value is nonsense as
well, these values have the meaning of "something very high" or
"something very low" and making calculations is meaningless. Adding 1 to
*Loval is comparable to adding 1 to negative infinity: the outcome is
not usable since infinity is... well as the word suggests infinite,
never ending, not having a fixed value (otherwise the concept of
infinite has to be revised and the laws of physics will change beyond
recognition).

The question is: What would be gained by allowing calculations with
special values like *LOVAL and *HIVAL?

Cor


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.