Ensign
Ensign
4088 views

Record Locking in Visual Cobol

We have just converted to Visual Cobol from RM.  Since we've gone live about a week ago we have users calling to complain that they are locked up in programs.  We're finding if one user is in a program that opens a record for I-O and another user is trying to run a report that uses the same record, the report program gets locked up, even though the report is only opening the file for Input.  RM did not display this behavior - in RM as long as the reporting program was opening the file for input then the report could be ran.  We're looking for a way around this. We found Visual Cobol documentation on line that references doing a read next-record with ignore locks  but we get a compile error on the word ignore. 

We are running native code on Red Hat Linux.

0 Likes
6 Replies
Absent Member.
Absent Member.

You may need to specify NO LOCK in the READ statement.  RM/COBOL doesn't try to lock a record when a file is only open INPUT, but Visual COBOL might.

Several details are missing from your description of the problem:

(1) Did you compile with directive dialect(rm)?

(2) Have you converted your data files to Micro Focus format or are you using filetype(21) directive at compile time and the original RM/COBOL data files at runtime?

(3) What do your lock mode clauses say (if there are any) and what does your OPEN statement say, both for the application and the report program(s)?

(4) Can you provide a small test case that demonstrates exactly what you are doing?

WITH IGNORE LOCK is a Micro Focus Visual COBOL option in the READ statement for relative and indexed files (not sequential organization files).  It might resolve your problem.

0 Likes
Ensign
Ensign

In the Read statement on the maintenance program that is doing the I-O read?

1.  With MF's help, our programs were converted using their modernization tool & then editing by our staff - we are NOT using dialect(rm)

2.  We converted our data files to MF

3.  We do not use any lock clauses so whatever is the default is in play.

As I stated in my original post,  WITH IGNORE LOCK will not compile. The compiler in says IGNORE is invalid.  The files in question are indexed files.  We do have the RETRYLOCK in our cobol.dir file.

4. Regarding test case - very simple.  Program A - maintenance program does a read on a I-O file. The report program has the file opened for input.  Does a start on the file and then a read next.  If someone is sitting on a record in program A, the report program will lock up or stop at the point where it  tries to read the record open in Program A.

select file assign to random "apy68"

    organization is indexed

     access mode is dynamic

     record key is file-key

*****select has multiple alternate keys as well.

Program A:

open i-o file

.

.

.

move co-no to file-co-no

move location to file-location

move item-no to file-item-no

read file invalid key

  close file

  exit.

Report Program

open input file

.

.

.

.

move location to file-location

move co-no to file-co-no

move space to file-item-no

start file key not less than file-key

  invalid key  move error-msg

                     display error-msg.

if not eof

  read file next record

      at end move "Y" to eof.

0 Likes
Absent Member.
Absent Member.

The conversion tool for RM/COBOL to Visual COBOL provides a directives file legacy_dialect.dir that removes the IGNORE keyword from the language.  This is because IGNORE is not an RM/COBOL reserved word.  The RM/COBOL program may have used IGNORE as a user-defined word and errors would happen if it was a reserved word.  Assuming your particular programs do not use IGNORE as a user-defined word, edit the legacy_dialect.dir file to comment out the "remove(ignore)" line by changing it to "& remove(ignore)".  Then there should be no problem with a READ statement that specifies the "WITH IGNORE LOCK".  If specifying NO LOCK is not sufficient for Visual COBOL to read through locks, then the IGNORE LOCK option is your best alternative.

0 Likes
Absent Member.
Absent Member.

One more thing.  The tool also provides a directives.dir file that contains the remove(IGNORE) directive.  The legacy_dialect.dir file is used during the conversion process.  The directives.dir file is the one that you need to comment out the remove(IGNORE) directive.  My regrets for not stating this in the earlier response.

0 Likes
Ensign
Ensign

This worked. Could there be another directive that allows a program that's open for input to ignore the lock anyways?  Seems to us that even if it is open for I-o in one program, the program open for input only should not have been affected - with out needing to use the "ignore lock" phrase.

0 Likes
Absent Member.
Absent Member.

I don't think there is a compiler directive, but there is a file handler configuration option for ignoring locks at run time when a file is open for input.  The default name for the file handler configuration file is extfh.cfg or you can set the EXTFH environment variable to point to a file of your choosing, as in, "set EXTFH=c:\mydir\test.cfg".  The format of the configuration file is explained in the documentation (square backets surround tags).  There are tagged sections that let you set an option based on the file's extension, file's folder,  file's name, file's path and name,   An example would be, if all your data files are in folder c:\files\app1datafiles\, then the configuration file would contain (note the doubled "\" characters):

[FOLDER:C:\\files\\appl1datafiles]
IGNORELOCK=ON

or, if the files all have the same extension ".inx":

[*.inx]
IGNORELOCK=ON

The configuration file could be added to the customer site(s) without having to redistribute your application.  (I know still a nuisance, but likely easier than a full distribution.)

Here's the documentation on the IGNORELOCK configuration option:

IGNORELOCK

The IGNORELOCK option specifies whether to ignore locks when reading files open for input.

Syntax:

IGNORELOCK = { ON } { OFF }

Parameters:

ON
Ignore locks when reading files open for input.
OFF
Do not ignore locks when reading files open for input.

Properties:

Default: OFF
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.