× 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: "Douglas Handy" <dhandy1@bellsouth.net>
To: <rpg400-l@midrange.com>
Sent: Wednesday, February 06, 2002 11:18 AM
Subject: Re: You know, I'm pretty sure it's zoned...


> >Fool me once, shame on you, fool me twice, shame on me.
> I think that's the bottom line. <g>

Maybe, but it's been more than just a couple of times and it's more than
just annoying after this many years.

> Aside from being historical and maintaining backward compatibility, it
will
> likely always continue to work this way simply because RPG allows you to
use the
> same field name in multiple files, and they all map to the same variable
within
> RPG.

Oh, it's likely to continue all right, but not for the reason you just
stated, although that's the party line.  ;-)

> You see, you did *not* explicitly show an intent for the RPG field to be
zoned
> -- you showed an intent for the *display file* field to be zoned.  Packed
fields
> really don't work very well with the 5250 data stream, or with users...
<g>

OH YES I DID! One declaration. And that's my issue.

> Forget display files for the moment.  Let's say you had two database files
> containing a customer number.  In one the field was declared as packed,
and the
> other zoned.  But each used the same field name.
>
> What should the compiler think is your EXPLICIT INTENT?  When either file
is
> read, the same RPG variable must be modified.  Should the field be zoned
or
> packed?  You can't have it both ways.

Fine, give me a warning. I can deal with discrepancies and conflicts between
fields, it's the single decalaration that gets modified that I have a
problem with. Generally I try to build and use one definition of any given
field, regardless of the name. (Reference files taught us that.) So...
social security number, referenced by any other files that contain it, are 9
digits. Funny, they don't need to be packed because I don't do math on those
numbers. But I sure do a lot of displaying and printing and updating.
And sorry, but the client won't let me forget display files.

> Unless you use an externally described data structure, the zoned/packed
choice
> of an external file (display or database) has no bearing on the program's
> internal storage format.  It has always been that way, and likely will
continue
> to be that way for time immortal.  In RPG II, the internal representation
would
> be zoned; in RPG III it would be packed.  In RPG IV, in the absence of a D
spec
> to state a preference, it would also be packed.

but then you repeat yourself... (see paragraph 2).

> Since when?  Since the beginning of RPG. <g>

Ditto. So why have free format? It wasn't there in the beginning.

> Because it is not "just so that the 39 processor can be more efficient".
It is
> because RPG doesn't use qualified names for fields from files, and thus
the same
> fields name can have multiple "explicit intents".

so, you must have had a different machine than me... <VBG>
No, the choice of packed decimal is a 38 thing. Again historical. The 38 had
a decimal processor and performed best with packed decimal arithmetic.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.