Object Lock Issues

[Paul]

[richard.milone]

I think there might be some unique problem on your system. It's very suspicious that your http jobs will not shut down. I see some of them are in EVTW status, are you sure you don't have a debugging service job started on those? If that's the case they will not end until the service job (or service entry point if you're coming from RDP or RDi) is first released.

I'm not surprised that you can't delete a logical. You will definitely find that Valence leaves objects allocated. Leaving files allocated is a natural remnant of the Valence design methodology. Because the programs run in a named activation group the files will not be completely free until the server instance is ended, even if files are closed manually and lr is set on. This is the desired behavior because of performance reasons so that files don't need to be allocated between each stateless call. To guarantee there are no file locks, like before a backup, the Valence server instance should be ended. However, adding a record from Valence and then going to the database and deleting it should be possible. There should be no record level locks left.

Like I said, I think there might be some unique problem on your system. If you want we can get online tomorrow and have a closer look.

[Paul]

[richard.milone]

Yes, all shops we do development work for have separate live and dev instances and libraries. By the way, most of the time you can stop and start a Valence server instance without affecting users. I only rarely need to do it in a live instance but I just wanted to point out that it's possible. At worst they might get the "Valence has lost communication with the server" message for 30 seconds or so, but usually they won't even get that if it restarts fast enough.

[robert.swanson]

Hi Paul,

Just to throw in a couple more tidbits on this topic...

You should be sure you have the “Development instance” box checked in the “Settings” application for the Valence instance in which you’re making frequent program and file changes, otherwise you might find recent changes made to your programs aren’t taking effect (because the system is still using the original object that was moved into QRPLOBJ once you recompiled). This is explained in more detail in the Valence manual.

For your file object locking issue, you could also consider using a unique named activation group on your custom programs and then adding a RCLACTGRP(*ELIGIBLE) to the VVCALL program, but beware that you’ll likely take a significant performance hit doing this. Restarting the server when needed, as Richard suggested, is the approach we generally recommend.

Lastly, keep in mind you can quickly restart your valence instance in Valence 2.2 using the supplied “VVSTART” command (which, in essence, will issue a “STRTCPSVR SERVER(*HTTP) RESTART(*HTTP) HTTPSVR(VALENCE22)” command). This RESTART(*HTTP) approach works so quickly that in many cases the users won’t even notice anything happened.