RE: Overlaying a DS Array In a LIKEREC DS

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.

I overstated my point. I'll take insignificant.

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?

For reference (since I don't have good copy of the original likerec DS),
here's a reasonable facsimile:

D myRecord DS Qualified
D amount1 11P 2
D amount2 11P 2
D amount3 11P 2

D P_MY_RECORD_DONT_CHANGE...
D S * Inz(%Addr(myRecord))

D myRecord2 DS Based(P_MY_RECORD_DONT_CHANGE)
D amounts 11P 2 Dim(3)

Now, if I understand, you're saying that we're asking for trouble if we
don't control initialization of P_MY_.... And your main argument for this
is that the amounts array will have uninitialized data. So we need to
create a critical error if that uninitialized data is referenced. OK,
sounds good. But if we follow that logic, surely we should do the same for
amount1, amount2, and amount3. What suggestions do you have for that
protection?

Before, you had stated that perhaps this pointer should address the real
data only if a valid read (not EOF) had taken place. Now that I understand
more about your concern more clearly, are you suggesting that the pointer
should be set for each successful read, and reset for each unsuccessful
read, so that you can have this effect (unitialized = unset)? What will
that do to your performance, pray tell? And how about program maintenance?
And if we don't set/reset the pointer, then where (after the first I/O) is
that precious, required protection we're going to get by having it unset?
Your argument is far too weak and flawed to say that it overrides personal
preference, seems to me.

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

At the risk of redundancy, we have this situation all the time. I'd wager
there's not a program in your library that does I/O that doesn't have this
situation. So we avoid referencing data we haven't read yet, and we use
indicators (not necessarily numeric) to control whether we refer to them or
not. I see zero difference.

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.

Oh, I see: Since we have a difference of opinion regarding performance, I
obviously am not of the caliber to "code for an OS." On the contrary, I
suggest that your exposure to coding for an OS has damaged your ability to
reason as a real-world application programmer. Based on this message and
others I've seen like it, I infer that it was pride that finished the job.

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.

There is no trap here that has been introduced by the setting (or not) of
that silly pointer.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"We can't all be heroes, because somebody has to sit on the curb and clap as
they go by."
-- Will Rogers