avoid file (record) locks in cobol 1

[Katla]

My problem is like this..

Reading a file sequntially and based on information reading/writing other files on key based.

Sometimes, the required file (record) is locked by other user. If it is locked, system is not returning the control back to program. Instead keep on trying and sending information about record lock to other user.

As I am running a cron job, no informnation is getting populated. As we are not aware of record lock, program is running for long time as nobody is noticing about the lock.


I am looking for

1. Any way to know the lock before reading the file?
2. If file (record) is locked by other user, how to get back control to program?
3. Help in notification of record lock or programatic elimination of lock.
4. Any pointers in helping avoiding record locks?

Thanks,
Suresh.

 

[slade]

Hi Suresh,

A solution will depend on what OS/platform you're running on. My background is on OS390/MVS mainframes. If you're running on a different config, I'm sure others here have the background to help. Let us know.

Regards, Jack.

 

[Katla]

I am running on HP UNIX with Acu cobol.

Even if we have a solution on MVS, I think I can duplicate to unix (untill unless it is operating system dependent solution...)

I am looking for quick solution as our production system is getting locked by everyday. I will be grateful, if someone can answer...

Thanks,
Suresh.

 

[slade]

Hi Suresh,

Here are some thoughts from the MVS perspective, maybe you can translate them to your environment.

If an MVS job reads a file, the file is defined as shared. This allows it to be accessed if other jobs using a shared definition for the file are running. If the other jobs don't use shared, the read job will be locked out. If the read job doesn't use share, it will be locked out if the other update job starts first. If the read job starts first the update job is locked out. Note that these "file locks" are done at the job level, that is, the lock lasts for the duration of the job. It sounds like your problem results from a long duration lock too.

Some solutions to this problem are:

1) define the update file as shared. Problem here is that the file can be updated simultaneously, thereby corrupting the file. Careful scheduling can avoid this, but it's risky.

2) Schedule the file updates away from the inquiries, or the converse. If you are running into updates by other jobs, you're probably running the job in the wrong timeframe.

Well, there may be other solutions, but these 2 are all I can come up with.

HTH, Jack.

 

[slade]

Hi,

Correction. I said:
quote:

If the read job doesn't use share, it will be locked out if the other update job starts first.

end quote

It should be:

The read job will be locked out if another update job starts first.

MHA, Jack.

 

[gtg]

When retrieving records that you don't intend to modify and rewrite make sure you are reading them with "No Lock".

When you are retrieving records that you may modify and rewrite you need to test for a "99" File Status Code. When this status code is encountered you will need to perform some appropriate code to bypass this record and continue.

 

[dhecht]

This is how it works in an MVS world:

If its a VSAM file, look at the share options on the CLUSTER defintion. You can specify a dirty read option, but this is dangerous. Share options '2,3' are the most generally used to allow concurrent reads of a VSAM file without locks.

The best solution is to check the file status as stated above and go into a loop until the file is available. You'll need some sort of timeout fail safe mechanism.

But before doing this, make sure that instances of the program or other programs do not OPEN the file, do time consuming processing, then do the writes. If this is the case, alter the programs to open immediately before the writes.

If it's a flat file, the disp parm on the DD statement should be set to DISP=SHR to have the same logical effect of a VSAM share option of '2,3'.

Maybe you can apply some of these concepts to the UNIX world. 1) Allowing dirty reads, 2) looping until the file is free, 3) making sure that files aren't opened until actually needed. These concepts should be true across OS environments.

 

[slade]

Saginaw,

MHA (my humble apologies).

Jack