record lock

[ruma]

Hi all,

I have an RPG program in which i am using around 15 files in update mode. I have CHAIN opcodes on almost all of them. The problem is in production this program crashes because of record lock in one or the other file.

Member/ Record File I/O ----Open--- Relative
File Library Device Format Type Count Opt Shr-Nbr Record

FDSL570 FDSDATA FDSL570 FDS570R LGL ++++++++ IO NO 2


What should i do? Should i do an do an ALCOBJ for all the files? or should i do a CHIAN (n) and CHAIN again to make changes?

Thanks in Advance,
Ruma

[B.Hauser]

Re: record lock

I'd use a monitor group to catch the record lock error. If an error occurs, you may chain the file again with (N), but remember (N) or UNLOCK won't work, if your program uses commitment control.

/Free
   Monitor;
       Chain (Key1: Key2: .... KeyN) FileFmt;
   On-Error 1218;   // Record Lock
       //Do whatever you want
   On-Error;  //all other Errors
       //Do whatever you want
   EndMon;
/End-Free 

Record locks only happen for Update Files. Input files get read even if the record is locked for update by an other job. Never use an update file, if it is not necessary. For example, in an subfile program the file must be updated too. To fill the subfile, use an Input file and for the update use an other logical file and chain with relative record no.

Birgitta

[ruma]

Re: record lock

Thanks Birgitta.
I am updating all the files that i have opened in update mode.

[jamief]

Re: record lock

As always Birgitta answer the question perfectly.
I have an example program that shows who locked a specific
record in a file. This can be seen here.

http://www.code400.com/locked.php

please download and give it a test.

[wegrace]

ARISE! Oh foul, dead thread!

I'm at a place that has a legacy system that has never had record locking handling implemented .

So, I am developing a record locking process, and am therefore researching how best to handle this.

I was hoping to take a peek at the code linked above, but I get an error ('Invalid File Specified') when I click on the link.

Jamie, might you still have the code around? 0-)

Thanks in advance.

Walt

[JonBoy]

Since you are reviewing your record lock handling you might want to look at implementing the technique discussed here so that the situation doesn't occur in the first place. https://www.itjungle.com/2015/03/03/fhg030315-story01/

[wegrace]

JonBoy,

Thank you for pointing me at that article! 0-)

Of course, Optimistic Locking is the preferred method for table access/update, and I have already considered that, and would prefer to do that.


However, there are a few reasons I chose not to do that as the stand alone solution at this time;

1) This record lock is for the Legacy System Item Master, which of course has had every attribute related to an item jammed in it; this Legacy System was born in the early eighties and has had numerous programmers work on it over the years, with no Program Standards nor Design Standards

2) So, I would have to apply this change to several hundred programs that update the Item Master, and TEST them all

3) And, I have not been allocated the amount of time required to accomplish this level of change


Therefore, what I have chosen to do is the following;

1) Provide the User a way to resolve their record locks without involving IT

2) Apply Optimistic Locking to item master update programs (and others) as an ongoing Technical Debt project, and therefore do these changes in smaller increments as time allows


Thanks again for taking the time to respond JonBoy. 0-)

Walt

[JonBoy]

Sounds like a realistic approach Walt. The method that I discussed does indeed have potential issues where legacy code is the target. These days it is a little easier than it used to be as the qualified names used in the DS arrays avoid direct conflicts with existing field definitions but that still leaves a lot of field = DSArrayfield type logic to be addd.

Good luck to you.

[wegrace]

Thanks Jon.