Re: %EOF, %FOUND and the infamous Dow loop

Joe,

>I guess I just can't explain my position to you: using an indicator, I had
>visibility, using a BIF I no longer do.  IBM wants me to use the BIF, but
>does not give me the visibility that I had with the indicator.  Can you see
>this point, or am I just not being clear?

I see your point, but just don't see the lack of visibililty as a big deal.
>From your original post the other day, you didn't even seem aware of it yet and
so were arguing from a theory viewpoint.  In practice, I just don't find it big
deal.  But then, that may be because of my style of coding, which may not match
yours.

> you have to add one INFDS for every file.  Even at a couple of
>minutes per change, modifying 1000 programs means dozens of hours of work.
>If you have a change management system, it's even more complex.  Saying
>"just add INFDS for every file" may be more work than you imagine.

But it is not like you would just go add it to every program as a project in and
of itself.  You would have no need to add it to every existing program.  In your
scenario it is only necessary for debugging.  Perhaps this is presumptious of
me, but I figure that means you are already making changes to the program.

After all, it seems like you do not use the BIFs in any existing code, or you
would have known this prior to this thread.  No matter what else you are doing
to the program, it seems to me the source would already be checked out in your
change mangement system and it is a siimple matter of adding a F-spec keyword
for the INFDS, and a single D-spec with an external DS and a unique Prefix().

In my DB paradigm, every file already has a unique prefix used on each fieldname
in the record format.  So it makes for a natural method to add a prefix to INFDS
fields.

I look at it this way -- you're already in the program making changes which need
testing.  So to me the change management impact is nill.  And the time to add
one F-spec keyword and one D-spec *is* trivial.  Maybe I type faster. <g>

I see absolutely no reason to go through 1000 existing programs which do not use
the BIFs just to add the INFDS.  But if I did, I'd write a program to do it for
me.  This is simple too, change management issues aside.

>This is exactly the point that I just don't seem to get across to you.  What
>you do is NOT what I do!  I do NOT do the single step.  And in fact, I may
>not have an IF immediately following my I/O operation.

Therein may lie the difference.  I consider it standard practice to ALWAYS test
completion codes immediately.  Just because a CHAIN to some file will "never"
fail is no excuse for not using defensive coding.

IMHO, every chain to a file should be followed by:

        Chain   filename
        If      Not %found( filename )
        Clear   *All    RecFmt
        Endif

except in those very rare circumstances where you *want* to retain the previous
field values when a Chain fails.  Likewise error conditions like record locks
should, IMHO, be tested *immediately* not somewhere else in the code.

>If I do not, then I
>have to wait until I get to the IF statement to see the results of my I/O
>operation, where I didn't have to before.  Can you NOT see that this is
>different?  The fact that it only matters slightly to you doesn't make it
>not different - it only makes it less important to YOU.

OK, you win.  It is not important to ME because I always test my I/O immediately
after the operation, not somewhere else in the code.  I also don't go changing
1000 programs unless I am already changing it.  And I also find adding a F-spec
keyword and one D-spec with Prefix() to take a trivial amount of time.  Note
that I don't even think adding the INFDS is really necessary.  I offered that as
a means for you to tell at any given breakpoint the status of a previous IO
operation to a file elsewhere in the program.

I don't find that a need in real life.  Perhaps you do.

>IBM is the vendor.  I am the customer.  If every time I made a change, my
>clients had to change how they ran their business, I suspect I would be out
>of clients very soon.

But IBM never said you "had to change" how you coded.  Your existing code is
fine.  You can continue to code that way if you prefer.

They have added a new alternative.  If you don't like it, that's fine by me.
Some people won't like the new /free format either.

I was merely trying to say that, in my perhaps limited experience, it just isn't
the issue you make it out to be.  And I tried to offer suggestions as to why in
a practical sense it made little difference.  At least with my coding style.

>Again, you and I have very different views on the concept of "trivial".  I
>think in terms of users with thousands of programs, where implementing a
>change like yours could actually cost thousands of dollars.

Again, I fail to see your point.  You don't go adding the INFDS just for the
sake of doing it.  Where is the cost?

You'd have to already be modifying the program and starting to use the BIFs.
Even at that, IMHO it is not necessary to have the INFDS to debug.  But if you
want access to the I/O status, the INFDS seems like a logical place to get it.

I just don't see how this can cost thousands of dollars.  Of course, my world
view is smaller than SSA's was...

>Well, I outlined how it affects me.  Evidently since it doesn't affect you,
>then it's inconsequential.  I think that's a rather narrow view,

I wasn't meaning to suggest that if a change doesn't affect me, that it's
inconsequential.  The V5R1 library list change didn't affect me either, but I
consider that implementation a big mistake because it can affect existing code
(even though it doesn't affect mine).

But the BIFs aren't like that.  You don't have to use them.  You don't have to
use /free.  If you choose to use the BIFs, you need to understand how they work.
Many people seem to get tripped up on which operations affect which BIFs.  I
suspect this throws off way more people than the lack of being able to see the
value of a function during debug.

Doug