Re: Overlaying a DS Array In a LIKEREC DS

On 06-Jul-2010 15:56, Dennis Lovelady wrote:

<<SNIP>>

I would use Simon's suggestion with a (very) minor twist:

fafile uf e disk prefix('C.') usropn
:
d c ds likerec(rafile)
D @array S * Inz(%Addr(c))
d array ds likeds(ctlds) dim(20) based(@array)
:
Read afile c;

The two approaches are functionally equivalent, and which
version one prefers is merely a matter of taste. The two
approaches are functionally equivalent, and which version one
prefers is merely a matter of taste.

FWiW: Although both an INZ(%ADDR(C)) in a declaration of the
pointer and an assignment of the pointer to the %ADDR(C)
during runtime have the same effect, there are valid reasons
[which IMO are beyond simply one's personal taste] with regard
to which method of setting the pointer is chosen. If the INZ is
used, then the pointer is set in the first instruction of
program processing, irrespective of any eventual use, so the
cost of setting the pointer is always incurred during program
start.

Yowzie, Chuck, you're going to use THAT as an argument? You have
FAR too much time on your hands! Or maybe too little if you
couldn't come up with a better complaint than that! Come on, now,
what is the cost of this??!?!!
What is the cost of a million of these?

Hmmm... Just how does one state any clearer that I understand INZ() can be insignificant. However a million versus none, I will *not* admit is insignificant in just about any code. To suggest otherwise IMO is little short of justifying bloatware.

It's personal taste. Maybe I want to make sure that pointer is
set before I use it... and to help the next person to come along
and muck up the logic without noticing the pointer hadn't been
set yet.

But my point was that the person so oblivious as to not notice the pointer was not set would be the same person to not notice that the pointer was set but to uninitialized data. So who is more helpful? The person who ensures the poor coding effects MCH3601 and thus failure, or the person who assists the coder in seeing incorrect output?

While I concede setting just one pointer is insignificant, the
possibility does exist to prevent unnecessarily setting the
pointer if the array will not be referenced. Functionally
however, choosing to not set the pointer until the data will be
referenced ensures a "pointer not set" condition for misuse,
thus exposing failed assumptions in the code.

Ummmm.. it is not a failed assumption if it is true, Chuck!

The "failed assumption" is that the storage is available for reference for its intended purpose when in fact it is not. If in fact the data is not available but able to be addressed, then the assumption that the data is available is a "failed assumption".

If the pointer is set since the first instruction, then any
statement in the program is allowed to reference potentially
uninitialized "data" in the array; i.e. to reference the data
in the array even if no open has transpired, or even if no READ
has populated the array.

So to avoid someone changing it, name the pointer
pDont_Change_Me_ever. Or use the popular 'constant' convention
(borrowed from C, by the way - I might as well aggravate Simon
also...) : name it P_DONT_CHANGE_ME_EVER. It's not like you need
to refer to it or anything. What you say above is true of ANY
pointer no matter how it's initialized; wouldn't you agree? BTW:
you seem to think that open of the file will matter here. It
won't.

I never said anything about changing the pointer or its address to something other than the location where the data will reside. I clearly stated the effect is the *same*, as in regardless of *when* the pointer is set, the address is the same. It is the *when* that is relevant for any code that might *assume* the location is validly addressable.

Thus if the file is never opened and\or never read, or even
perhaps if no row was found, possibly the pointer need never
have been set.

I'm shaking in my boots to think of all the power and time it
tookto set that pointer. How could I have digressed so badly? :)

Sheesh, Chuck!

I can only infer you have never coded for an OS. To each his own.

As I started my response very clearly... FWiW.

I just happen to understand that many tens [probably hundreds] of defects had been coded to such false assumptions in the OS [causal analysis], and I am not ashamed of warning others against such programming which allows so easily falling into the same trap. I intend to help others just as you seem to intend... and I do not feel someone belittling my attempts to do so is any more beneficial than if I were to belittle yours. The aim is to complement suggestions or provide valuable insight as to why they are not of benefit... such as one might do to provide a critical review.

Regards, Chuck