On n-tiers configurations, we set up "business super-procedures" (super-procedures that are loaded into shared memory on appserver side tier).
These libraries are often called from appserver-part of our smart data objects (or from client-side tiers) to run business rules (such as : inventory preparation, bill validation, etc.).
Those procedures are designed by module and contain all the processes required by the given module.
Those procedures enable us to centralize module processes and rules within one given object and then enable us to maintain business rules easily and clearly.
When it comes to production time, and as far as patches are concerned, every time we do have to release one of those procedures we have to stop the appserver process and restart it after the release of the procedure.
We then require our customer to stop production during the working day or we are not able to make a patch during the day (if the customer cannot stop working).
Dealing with either of the 2 choices is a bad step.
1) We should be able to have access to loaded programs (super-proc) on appserver side.
This access would be made available through an appserver command.
2) We should the be able to RELOAD a given (named) super-proc. This would be done from the menu, by giving name or a reference to the given super-proc.
This should replace .r in memory by the .r (in the same location) updated by us.
3) optionnaly, we should be able to load or unload a named program - this is for a special need of a given super-proc during production time.
But this would be at our own risk, as the initialization phase of the appserver process should be updated if we want this proc to be (not) loaded in normal startup phase.
Check my procedure manager on http://www.peg.com/utilities.html for some possible ideas on how to address this problem.
Thanks for your answer, but the requirement is not about 4GL behavior/properties.
Our requirements deal with Appserver in-memory programs management, and of course we wait for answers from Progress Software Corporation. It has to be a dedicated move coming from Progress Corp.
Regards
I expect that getting PSC to natively support "swapping out" super-procedures will probably be a very long wait.
Depending on what you're trying to do, and if you don't use procedure libraries or -q, it may be possible to do the super-procedure swapping yourself through purpose-made 4GL code, which is why I suggested looking at my procedure manager.
Thanks again for your reply, but that is unfortunately not the answer i am looking for.
The reason why i have posted this mail inside the forum is to get an clear position and answer from Progress Soft Corp.
Regards
This very request came up at Exchange 2006, specifically at Comp-13: OpenEdge Deployment Tools InfoExchange. We will be looking into it.
Regards
Salvador
I have a solution you might be able to use :
first of all, we use the activate procedure of the appserver, in this very small procedure, there is in fact only one statement which calls a procedure which resides in one of the persistent procedures allready running. Eventually - I haven't tried it yet - you can include this procedure in a memory mapped pl to improve speed.
In the called procedure, there is a periodic check to insure a restart was initiated and a control who looks which persistent procedures did actually change (I have a temp-table with last modification date & time, and compare this to the values of the file-info handle).
When the procedure is changed, i remove from super, apply a close to it, and restart the new version. This is now running for several months now, and we don't encounter any problems nor system performance drop.
Hope this helps...
could they divert requests to a standby appserver using a nameserver
restart the appserver and switch back ?
As the restart occurs before the original request is beeing done, you can assume that the restart will happen pretty fast.
And yes, we use a nameserver. But if there are eg. 100 servers, with only some clients and a little number of requests, it can take some time before there is a trigger to reïnitiate the supers, but you're sure that within a given time (I won't check at every request neither - here there is a check every 100 seconds) there will be a check on the next request.