RMCOBOL-85 I/O Error 99 2

[SiouxCityElvis]

I am using RMCOBOL-85 on a Linux platform.

I've been getting this error off and on for the last 8 months.

I have a handful of Cobol applications("users") that access the same file by an OPEN I-O TEST-FILE statement.

The manual indicates that if I wanted to lock a file that I would have to use a LOCK MODE clause.

I want to permit the file sharing of the above mentioned TEST-FILE. So, then, since I'm NOT using the LOCK-MODE clause, and I DO want to share this file, then why is it that I keep getting into this 99 I/O error which states:

"A DELETE, READ, or REWRITE statement failed because the record is locked by another user".

I've even tested to verify that this happens when I only have 2 different apps("users") accessing the same file by and OPEN I-O TEST-FILE statement and the same error comes up.

Please help or suggest something which may help me finally resolve this issue. It's killing me on 2 different projects now.

Your help would be greatly appreciated.
Thanks.
-Dave

 

[fredericofonseca]

The OPEN with LOCK will only affect the whole file, not the records. E.g. another user would not be able to OPEN the file, nevermind reading the records.

"normal" open I-O will cause "lock on record" to be set

So user A reads Record XXX using the following command

read file next at end
or
read file invalid key

and it will lock Record XXX unless you use the WITH NO LOCK on the read.

So when user B tries to read the same record on a file opened I-O it will get the 99 error.

Perfectly normal on my opinion, but ...


Multi-user management is always a hard thing to do, and there are a few approaches to this, so a solution for this will vary on what you are trying to do with that record, e.g. if you need to update it, or only read it, so more information is required.



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

Dave,

You need to read and understand the section of the RM/COBOL Language Reference Manual entitled Record Locking in Chapter 5. There are several choices for you on how to manage record locking. Your programs are behaving in the default manner which is Automatic Record Lock Mode which was described above by Frederico.

... statement failed because the record is locked by another user. {empahsis added)

The error message was telling you about a record locking problem, but you were using file locking tools to fix the problem.


While it is not required to do so, it is a reasonable programming practice to read a record (with lock) before attempting to delete or rewrite it. Not to do so might cause data that you are absolutely sure you wrote to the file to disappear, because of the race between two programs updating the same record.

Heed Frederico's advice about muti-user management and think things out.

Tom Morrison

http://www.liant.com

 

[SiouxCityElvis]

Guys,
I appreciate this. I really thought it was a File Lock issue, but as it turns out, it was a record locking issue.
And it explicitly states it in chapter 5 as you mentioned how to go about record locking vs. no record locking. I guess my error output of

IO-ERROR-ROUTINE.
DISPLAY "COB: CHECKDB FILE Error " ACHDB-STATUS
" on operation.".

said it all with the 99 error which states NOTHING about it being a file lock, rather it states a record was locked by another user. I don't know why I thought it was a file lock issue. Sorry about that.
Star to both of you for putting up with questions like this!
Tom, I did read into the manual, but naturally I missed the point before posting this thread, as I was looking for file lock info.
I will definitely keep the timing issue in mind also as you mentioned "... because of the race between two programs updating the same record"
I know exactly what you're talking about as we covered the same type of issue at the last shop I worked at(mainframe COBOL shop).
At this point, the 2nd program only reads the same file on a cron job 1/day whereas the 1st program "listens" to pipe input and reads and updates the file all the time.

Thanks again.
Star to both of you.
-David