So, Smart Swami, what should I do?

This is one place where generalities will clearly have to suffice.

Generally, you should NOT use SHAREOPTION(3). When this option is chosen, VSAM and VSE provide no integrity checking for you, and it is (at least remotely) possible that you or an operator might just happen to schedule two jobs concurrently that OPEN a file for update. You could have been running them like this for months or years without a problem, but one day...

Generally, you should use as low a SHAREOPTION level as possible. SHAREOPTION(1) provides the most integrity, but it restricts you if you need to read a file which is opened for update somewhere else. SHAREOPTION(2) permits concurrent read access while the file is opened for update. However, it is possible that a read-only user may experience any one of the symptoms from the lack of read integrity:

• GET can return a record's old data, even though that record has been updated on disk.
• GETs can return an "incorrect logic" or "boundary exception" type of error when they try to retrieve a record which has been relocated by a CI and CA split since the time that the read-only task OPENed the file.
• Application programs may experience ABENDs, return codes, and other indications which indicate potential for corrupted VSAM file information. Re-running the read-only application usually causes the apparent error to disappear. In some cases, the update application may have to CLOSE the file, in addition to the read-only application being re-run.

SHAREOPTION(4) and (4 4) permit multiple applications to access a file for update safely, but in so doing, incur a significant performance price. Recall that SHAREOPTION(4) and (4 4) files do not provide more protection than SHAREOPTION(2) for files opened with only read intent.

Use the lowest SHAREOPTION level you can to meet the needs of your application suite.