|
On Fri, 5 Oct 2001, Robin Coles wrote:
>
> With READ and an indicator, if the record happened to be locked the user
> got an error message that was ugly but allowed a retry. It happened so
> infrequently and recovery was so painless that we just accepted it.
> We've recently switched to using READ(E) and %EoF etc, using code
> similar to:
>
> Read(E) File
> Dow Not %EoF
> ... Some stuff here
> Update File
> Read(E) File
> EndDo
>
> but now we don't get the error message if there's a lock, and we fall
> through the DoW loop ending up with an update without prior read or
> chain.
The reason that you're not getting a "lock error message" is because
you're specifying "(E)", which means to trap all errors. This is the
same (and has the same results) as placing a 2nd indicator in the 'Lo'
indicator position.
i.e., these two code snippets are functionally the same:
C read file 0102
C dow *in02 = *On
C read file 0102
c enddo
c read(e) file
c dow not %eof(file)
c read(e) file
c enddo
This is a bad idea, as you've noted, because in both cases you're telling
it that _you_ want to handle any errors (either by specifying (E) or by
specifying indicator 01) -- but then you're not handling those errors.
Instead, if you're not going to handle them, let the operating system take
it's default action. These two snippets of code do that:
c read file 02
C dow *in02 = *On
c read file 02
c enddo
c read file
c dow not %eof(file)
c read file
c enddo
Does that make sense? (Or did I miss the point completely?)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.