Record lock question

[gregwga50]

I think I know the answer to this but here goes anyway. In some cases if a program that exits without setting on LR, the files remain open. So, if a program that doesn't close the files when exiting prematurely has a record lock on one of the files that remains open, does the record lock still remain intact or is the record released even though the file remains open.

[CRinger400]

Remains locked, unless compiled with ACTGRP (*NEW) which would defeat the purpose of wanting to leave files open.

[gregwga50]

Remains locked, unless compiled with ACTGRP (*NEW) which would defeat the purpose of wanting to leave files open.

Thanks
That prompts my follow up question:
So, if a file is left opened and a record in the file remains locked because the files did not close when the program A exits. Will a follow up call to Program B that issue an UNLOCK opcode release the record lock (this would all be done as part of the same interactive job).

[Rocky]

Remains locked, unless compiled with ACTGRP (*NEW) which would defeat the purpose of wanting to leave files open.

That is true if it's an ILE program - no such critter exists with RPG/400...

[CRinger400]

Yes right. If you are *not* using ILE which was introduced over 2 loooong decades ago then the answer simplies to "Remains locked".

[gregwga50]

We have a very large (6000+ lines of code) program that is old, poorly written and going to be replaced within the next year, so re-writing it now is not an option. The intent is to keep it from causing problems in the short term until it can be re-written later. That said, here is the problem:

The program occasionally aborts with error message Record n member XXXXX already locked to this job. I am not sure if the current invocation of this program that receives this error is the one that is locking the record or a previous invocation that never closed the files (leaving a record locked) caused it or another program called earlier in the current job locked it without releasing it. I thought that inserting an UNLOCK opcode before accessing the file in the aborting program would unlock the record but that does not appear to be the case for records that were locked by a previous call to this or another program but that is not the case. I need to find a short term fix.

[Rocky]

I have a suggestion for you - but it will have to wait until this afternoon....

[Rocky]

That is true if it's an ILE program - no such critter exists with RPG/400...

While true - we have a looootttttt of code at RPG/400. If we do any extensive work on a program we convert to ILE - but if it ain't broke...

[gregwga50]

It is a program that was converted from RPG II to RPG IV and compiled using the CRTBNDRPG. The new code I have introduced is written in free-format, but much of it remains fixed format RPG II type logic.

[Rocky]

If you have RDi I use it to create a program Status Data Structure - if you don't.....

     D PGMSDS         SDS                  QUALIFIED
     D  EXCP_DATA             91    170                                         * Exception data
     D  FILE_INFO_STATUS...
     D                       209    213S 0                                      * Last file status
     D                                                                          *   Code          
...
     C     1             CHAIN(E)  FILELIB
     C                   IF        %ERROR = *ON
     C                   If        PGMSDS.File_Info_Status = 1218
     C                   EVAL      MSG = %SUBST(PGMSDS.EXCP_DATA : 1 : 52)
     C     MSG           DSPLY
     C                   EndIf
     C                   Else
...

Use the (E) extender, check for %ERROR. You can use the file_info_status to see what error it is - 1218 is a record lock. The excp_data gives the message - in my case of the above:

DSPLY Record 1 in use by job 877413/RAM23/ITS08A.

[johnerps]

The solution has probably to do with open data paths (ODPs). Program A locks a record and leaves the file open, then program B can unlock the record if both programs share the open data path (ODP) to that file.
So you need to do an OVRDBF with SHARE(*YES).
See the following information:

https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzasc/sodp.htm#sodp

https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzasc/rcdlock.htm

[Barbara Morris]

Assuming you can make a small change to the program (program A), you could add a bit of code to just seton LR and return immediately if no parameters are passed. Or, if the program doesn't have any parameters, add a "quit" parameter that will cause the program to set on LR and return.

if %parms = 0;
    *inlr = '1';
    return;
endif;

Or, if you just want it to do an UNLOCK, but otherwise stay active, you could just code the UNLOCK opcode.

if %parms = 0;
    unlock rec;
    return;
endif;

Overriding the file to be shared could bring about a lot of hard-to-debug problems for all the programs using the file. The programs would have previously been independent, but now, for example, a program that used to read the file from beginning to end would now start reading from wherever a previous program was in the file. Or you might get errors where the file was originally opened for input only, and then another open tried to open it for update. Etc.