John Alleyn-Day replies:

>You need to move spaces to debug-record and cond-word to display-number
>before you string "END ATTEMPT .......".  You are not seeing the most
>recent value of cond-word (and "string" doesn't clear the record the way
>"move" does).

I knew that!  I did move spaces the first time (at the BEGIN ATTEMPT...),
I just forgot to do it the second time.  However, that omission on my part 
does not invalidate the data in the debug-record.  While string does not 
"clear" the record, it will overwrite whatever value is in the bytes it 
replaces.  As for not seeing the "most recent value of cond-word", it's not

a problem because I want the "previous value" (that is, the value of 
cond-word at the beginning of the paragraph) which indicates what pass 
number we are on.

>job-ctl-status is being used to give you a return from the "open" and also
>(presumably) from the "exclusive".  Also the logic of the "perform"
depends
>on its value, so you have to know what it is after every time it could
change.

Well, yes, I want to know if the I/O failed, that's why I have the status 
variable, but as for *why* it failed, I really don't care.  If the I/O 
faield, I just want to try again (up to 100 times).

>Do you have debug statements elswhere in your program, so that that you
can
>pinpoint where it gets to?

Yes, but it never gets beyond this.

>I'm presuming that the initial 8 lines are somewhere else in the program,
>since there is nowhere for the code to go after executing them, except to
>run on on into the "OPEN" paragraph.  I can't see that something like that
>would have the effect you describe, however.

Correct, what I originally posted was a code snippet.  If you want the 
complete source, I can arrange for that.

>By the way, what is the problem with using an unconditional lock and just
>waiting for the file to unlock?  Do you have some rogue process that holds
>a lock for an inordinate amount of time?

We want some control over the wait process, that is, we would prefer the 
program terminate gracefully instead of waiting forever for a resource to 
be freed up.  So, now the program waits forever anyway. :-)

Jim Phillips                            Manager of Information Systems
E-Mail: [log in to unmask]      Therm-O-Link, Inc.
Phone: (330) 527-2124                   P. O. Box 285
  Fax: (330) 527-2123                   Garrettsville, Ohio  44231