File access error under Linux

[Frank Cox]

I have what has become, over the course of time, a rather large and complex database application.

The production server runs Fedora Core 3 (http://fedora.redhat.com), dosemu (http://www.dosemu.org), and supports several simultaneous users.

This is what I use to open the main datafile:

sub openrandomfile(file.to.open$,filenumber) ^
| shared ad :
| on error goto open.random.file :
| open.random.file: :
| open file.to.open$ for random access read write lock read write as # :
| on error goto 0 :
|end sub

Sometimes if I get a collision the program crashes with an Error 75 Path/File access error, just like the on error statement wasn't present.

What am I doing wrong? As I see it, the on error statement should cause the program to keep retrying until it gets access to the file.

------------------

[Donald Darden]

Here are some ideas. First, you should not use periods in variable
names. This was acceptable under PF/DOS, but is not going to be
supported going forward, as periods will identify fields within
UDTs. So you should change that.

Second, the ON ERROR GOTO normally branches to code that is out
of the main sequence. Here you continue right into the same
statement, which makes it just like an ON ERROR GOTO 0. The best
way is to do something like this:

ON ERROR GOTO Problem
ErrCode=0
'Perform step that might cause error
'Main sequence continues here
ON ERROR GOTO 0
IF ErrCode THEN             'handle the error
END IF
END                         'or END SUB or END FUNCTION

Problem:
ErrCode = ERR                     'try to get the err code 
if ErrCode = 0 THEN ErrCode = -1  'at least show we trapped here
RESUME NEXT   'continues at step after error

The code example you provided includes strange markings,
and won't work as typed. For instance, you did not provide
a valid file number for the OPEN command. Likewise, we do
not know what you have the filename set to, so we don't know
if either the path or the filename is invalid. And finally,
If you get an error, you don't just ignore it and do the same
thing over and over - you are suppose to see what the error is
and take appropriate action. And before you attempt to perform
some action that may result in an error, you need to make sure
that the error flag is cleared and that you set a trap to
detect and handle the error.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

[Michael Mattias]

Here you continue right into the same statement...

And when it gets there, it never does a RESUME, which is required to exit "error handling mode" (and error handling is disabled until a RESUME is encountered, which is why you get an error messsage "just like there was no ON ERROR in effect" - because there isn't!).

, which makes it just like an ON ERROR GOTO 0.

Not quite.. see explanation above re no RESUME. ON ERROR GOTO 0 disables error trapping completely and in this mode <U>all</U> errors are fatal and result in immediate program termination.

MCM


------------------
Michael Mattias
Tal Systems Inc.
Racine WI USA
mailto:[email protected][email protected]</A>
www.talsystems.com

[Frank Cox]

>The code example you provided includes strange markings,
>and won't work as typed.

When I cut-and-pasted that code from my dosemu window, it added those "strange markings", which I assumed were something to do with formatting text pasted in that manner to the "Ultimate Bulletin Board Version 5.45c". Now I see that it's not, so I will remove them in the future.

>For instance, you did not provide
>a valid file number for the OPEN command. Likewise, we do
>not know what you have the filename set to, so we don't know
>if either the path or the filename is invalid.

It's a sub, and as such is called with the filename and filenumber when it's called by the main program.
I have several datafiles that inter-relate with each other, and the sub is called to open any and all of them.

Here is an example:
call openrandomfile("barghntr.000",1)

> And finally,
>If you get an error, you don't just ignore it and do the same
>thing over and over - you are suppose to see what the error is
>and take appropriate action.

In this case, that's exactly what I want to do. The only possible error at this point in the program (outside of hardware failure) is a share violation. The error will be error 75 (always) and on that event I want to re-cycle and keep hammering until the other user(s) close the file and the share violation goes away so I can open it, lock it, and write to it myself. The clients hold the file open for only a split-second per transaction.

> And before you attempt to perform
> some action that may result in an error, you need to make sure
>that the error flag is cleared and that you set a trap to
>detect and handle the error.

That's the purpose of the sub as I posted it here and as it appears in the program. My question here is, why is it not working as designed?


------------------

[Frank Cox]

>And when it gets there, it never does a RESUME, which is required
>to exit "error handling mode" (and error handling is disabled
>until a RESUME is encountered, which is why you get an error
>messsage "just like there was no ON ERROR in effect" - because
>there isn't!).

Aha! Most interesting indeed. It appears that I shall have to re-work my logic in that sub, then.

Thanks a lot for your advice. You've provided me with a great help.



------------------

[Frank Cox]

Michael and David:

Thank you ever so much for your advice. I have implemented your suggestions into my database program and it's working just dandy.

That database started out as a small single-user program of a few hundred lines running on DOS. It's now many thousands of lines and a fully multi-user system that runs under Linux, doing a lot of stuff that I never dreamed of implementing when I started writing it.

No-one can tell me that PowerBasic for DOS is obsolete. It rattles along like nobody's business on modern P4 CPU's, and it's so efficient that a lot of simultaneous users can be supported in very little ram.

Thanks again, guys. Your help is greatly appreciated.

------------------