Updating Procedure Libraries on a live system.

Posted by bstaunton on 20-Jun-2018 08:48

Hi.

The company I work for is considering moving some of their more frequently used code to a Procedure Library on their live production system. The question that has come up though is, since these procedures will be stored in shared memory during use, can you update the library without stopping the system?

Thanks.

OpenEdge General - Forum
Posted by jmls on 20-Jun-2018 08:55

Short answer is no.

Long answer is that you can alleviate the problem by implementing the .pl in a different way. Instead of calling the pl "mylib.pl" (for example) you call it the date and time it was built, so 2018-06-20-14-52-mylib.pl and create a startup routine that finds the youngest .pl file in the distribution folder, and add that lib to the propath.

Any *new* client start ups will then use the new library, and you can get the clients using the older lib to log out when convenient 

It also has the advantage of keeping the "last known working library" in place - so if you find something wrong with the new lib, get everyone to log out, delete the .pl and then they can restart, as they would be using the older pl now

Posted by Peter Judge on 20-Jun-2018 09:00

PL’s are a good approach in general. If you want to hotfix you could think about dropping the affected rcode into propath ahead of the PLs; there are some threads on Communities about approaches for that (ie folders named for hotfixes  etc).
 
If the question is about removing r-code that is memory-resident (ie persistently running or loaded via -q) then you have other things to think about.
- For the -q case, you can force r-code to reload using a  ASSIGN CURRENT-LANGUAGE = CURRENT-LANGUAGE. statement in ABL.
 
- For the persistent-procedure case, you can read the session’s procedure chain and delete/reload the rcode.
- For OOABL and static members, it depends on what’s held and how it was loaded in the first place.
 
In general terms it’s probably better (for the last 2 cases) to start new sessions (and/or agents in AppServer terms). That way you know you had a clean session start (and not a hinky-dinky manual process).
 

All Replies

Posted by jmls on 20-Jun-2018 08:55

Short answer is no.

Long answer is that you can alleviate the problem by implementing the .pl in a different way. Instead of calling the pl "mylib.pl" (for example) you call it the date and time it was built, so 2018-06-20-14-52-mylib.pl and create a startup routine that finds the youngest .pl file in the distribution folder, and add that lib to the propath.

Any *new* client start ups will then use the new library, and you can get the clients using the older lib to log out when convenient 

It also has the advantage of keeping the "last known working library" in place - so if you find something wrong with the new lib, get everyone to log out, delete the .pl and then they can restart, as they would be using the older pl now

Posted by Peter Judge on 20-Jun-2018 09:00

PL’s are a good approach in general. If you want to hotfix you could think about dropping the affected rcode into propath ahead of the PLs; there are some threads on Communities about approaches for that (ie folders named for hotfixes  etc).
 
If the question is about removing r-code that is memory-resident (ie persistently running or loaded via -q) then you have other things to think about.
- For the -q case, you can force r-code to reload using a  ASSIGN CURRENT-LANGUAGE = CURRENT-LANGUAGE. statement in ABL.
 
- For the persistent-procedure case, you can read the session’s procedure chain and delete/reload the rcode.
- For OOABL and static members, it depends on what’s held and how it was loaded in the first place.
 
In general terms it’s probably better (for the last 2 cases) to start new sessions (and/or agents in AppServer terms). That way you know you had a clean session start (and not a hinky-dinky manual process).

Posted by bstaunton on 20-Jun-2018 10:49

Thank you for both of these answers, that's a wonderfully elegant solution jmls! Peter can you ellaborate on ASSIGN CURRENT-LANGUAGE = CURRENT-LANGUAGE? I assume making that equal itself triggers some sort of process?

Posted by Peter Judge on 20-Jun-2018 10:54

I don’t know the details but I suspect that the runtime needs to force-reload the r-code to pick up a new language segment, regardless of whether there are any or whether the language actually changes. A useful side-effect.
 
I was told about this by a customer not too long ago, so thought I’d pass it along :)

Posted by Mike Fechner on 20-Jun-2018 11:00

This is a well known trick to flush cached r-code. Also when -q is active.
 
 
(in case you don’t trust an UPPERCASE coder).

Posted by George Potemkin on 20-Jun-2018 11:05

.

Posted by George Potemkin on 20-Jun-2018 11:13

CURRENT-LANGUAGE = CURRENT-LANGUAGE clearing the inactive slots in the -D directory.

It takes effect only at the end of the current procedure.
Example: run any .r or .p procedure. Let's say:

RUN test.p. /* e.g. MESSAGE "Hello" VIEW-AS ALERT-BOX.*/

Then check and clear the -D slots:

RCODE-INFO:FILE-NAME = "test.p".
MESSAGE "Before clearing:" RCODE-INFO:CRC-VALUE VIEW-AS ALERT-BOX.

ASSIGN CURRENT-LANGUAGE = CURRENT-LANGUAGE.
MESSAGE "Check again" VIEW-AS ALERT-BOX.

Posted by jmls on 20-Jun-2018 11:15

I'm pretty sure that from what I can remember you cannot remove and replace a .pl file that is in use , especially a memory-mapped one. You can flush r-code all you want, but I don't think that removes the .pl restriction.

A little wrinkle on the named pls would be that you *could* dynamically add the new prolib to the start of the propath in a running system, _then_ flush the r-code. that may give you the best of both worlds.

Unless, of course, you hold state in the r-code :)

This thread is closed