Killing CGI job file locks

[TerryB]

Hi Guys, I've asked you this before in emails, hoping maybe someone else on forum might have ideas. The issue is using SQL to read the files versus RPG I/O. RPG closes any file locks when processing LR and closing. SQL does not seem to play by those rules. These files stay locked until the CGI job itself is killed. I don't mean update locks, I mean read locks, they are "open".

This has become more problematic now that I have setup a test system. I have job that copies live to test every night, now some files fail because CGI jobs still holding locks from testing in test system.

Isn't there anyway to change this behavior? We are 24/7 operation, so ending the CGI jobs isn't really an option. Well, I don't think. The same CGI jobs run both prod and test sessions.

Any advice appreciated from anyone. Thanks!

[robert.swanson]

Hi Terry,

I presume you're referring to the open data paths that SQL tends to leave out there. Those aren't record locks, but they may interfere with CPYF commands or anything that requires an allocation of the file objects.

I think the best option would be to have your program that copies the files to test to issue a VVSTART command immediately before the copy commands (be sure the Valence instance library is at the top of the library list). This will do an instant restart of all the CGI jobs and kill any lagging ODPs. Any active Valence users would not lose their sessions or anything like that. At worst a user might notice about a 30 second delay from the server if they happened to be taking an action just after the restart is initiated.

Another option, provided your custom programs being called by VVCALL are not compiled with an activation group of *CALLER or VALENCE, is to have the portal reclaim the non-VALENCE activation group(s) after each call, instead of the default which is to reclaim *ELIGIBLE groups after evert 100 calls. This is configured in Portal Admin > Settings > IBM i Settings. But there could be a slight performance penalty to that approach, so I'd try the VVSTART approach first.

-Rob

[TerryB]

Thanks Rob! I think VVSTART will work. My concern was kicking guys out of sessions, which ending HTTP server likely would have done. I run this in middle of night, so impact should be minimal.

I was also considering another Apache instance for testing, which I could then restart without impacting production sessions. But I'm trying VVSTART first. Take care!