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



<<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?

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.

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!

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.

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 took to set
that pointer. How could I have digressed so badly? :)

Sheesh, Chuck!

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"For a moment, nothing happened. Then, after a second or so, nothing
continued to happen."
-- The Hitchhiker's Guide to the Galaxy



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.