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?
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
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?
Architect of the SmartComponent Library and WinKit
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.
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 :)