Glenn,
If all the people that know the cycle continue using the cycle, then you
will soon get something like what was was included in a section of the
company's CIO Newsletter 2007 that went out to thousands of employees
And what company was that? The one you work for? I don't use the cycle
often, but I am far from adverse to using it when the shoe fits. When there
is a tool in my toolbox which is made specifically for the task at hand and
can easily do it in a few lines of code, why should I choose the hard way to
do it?
The code that was included with this note is not structured and not
logical. It is crap IMHO (pardon the language).
In this context, what is your definition of structured? The fact it does
not do its own reads inside of DOx loops?
I already posted my revision of the original. Please post yours for
comparison. Enlighten us and show us how you think it should be done.
Is mine really that hard to follow? I don't care if the person never has
seen MR before. If handed the program to make some changes, do you really
think they have to throw it out and start over? IMHO, anyone should be able
to quickly determine which subroutine handles the case for a specific set of
conditions, or which "do nothing" WHEN clause to utilize should future
changes require tasks under those conditions. At that point, what else do
they need to know about MR?
I'm dead serious when I ask you to show us your version of how this should
be done, if MR is unacceptable in your shop.
Doug
midrange.com
