T.R | Title | User | Personal Name | Date | Lines |
---|
2127.1 | | IJSAPL::MONNINK_H | | Tue Feb 18 1997 08:00 | 13 |
| Renee,
You'll have to stop the dcs process !
This is also true for releases prior to 307 because normally you don't
know which user is actually using the shared library, so you'll have to
shutdown the DCS!
Han
|
2127.2 | | TAV02::YAKIR | Yakir Lavie, ISRAEL DTN 882-3327 | Tue Feb 18 1997 09:26 | 14 |
| Hlelo Rene,
> make a new version operational. How do you do that now? Does one need
> to kill the process(es) in the style of stopdcs.sh?
>
From the experience of some of our customers, it would seem that YES, you
need to do (as a minimum) a stopdcs.sh + startdcs.sh when the Shared Library
code has changed.
HTH
Yakir
|
2127.3 | Is the DLL reloaded now on each call? | KETJE::HAENTJENS | Beware of Counterfeit | Wed Feb 26 1997 17:19 | 18 |
| I could do just one brief test with /DISCONNECT and then my development
system broke down (for other reasons). So I want to re-test later.
What I thought I noticed with /DISCONNECT is the following. Tell me if
I'm wrong. The server process stays alife and indeed, another client
can connect to it and make it work.
But, my great advantage of loading the DLL (the shareable image on VMS)
only once seems to have gone! As soon as the second client executes its
external call, the DLL is reloaded (instead of being re-used).
The C program in my DLL has a static variable where it counts the
calls. Without /DISCONNECT, it counts 1 2 3 4 ... (for one client).
With /DISCONNECT it restarts at 1 when the second client connects.
So I win a process creation but I loose a DLL loading?
Ren�.
|
2127.4 | | maandaj.uto.dec.com::~::ANONYMOUS% | | Thu Feb 27 1997 12:11 | 32 |
|
> What I thought I noticed with /DISCONNECT is the following. Tell me if
> I'm wrong. The server process stays alife and indeed, another client
> can connect to it and make it work.
That is the intention.
> But, my great advantage of loading the DLL (the shareable image on VMS)
> only once seems to have gone! As soon as the second client executes its
> external call, the DLL is reloaded (instead of being re-used).
No that should not be the case. I don't know VMS but on UNIX and NT, the /DISCONNECT
will disconnect the client from the DCS process on the server but the DCS process
should stay and the shared lib should still be loaded.
THe /CLOSE should stop the DCS process and hence unload the shared library.
> The C program in my DLL has a static variable where it counts the
> calls. Without /DISCONNECT, it counts 1 2 3 4 ... (for one client).
> With /DISCONNECT it restarts at 1 when the second client connects.
I have tested the same thing on NT and UNIX. Without the /DISCONNECT all clients
have their own private counter. With the /DISCONNECT the will be using the same counter
so client A gets 1, client B gets 2 client A gets 3 etc. when they take turns on this
method.
Be carefull though. The parameters in cltdf.cfg are still taken into account. So if you
use /DISCONNECT but the server process is not able to keep up with the request a new DCS
process will be started and also loads the DLL probably with shared text but certainly
with private data. So that counter will start at 0.
With other words if you want to use this as an inter process (client) communication
mechanism, there is more to do.
Could you check the above when your server is running again?
Regards,
Jos
|
2127.5 | I'm wrong - it works OK | KETJE::HAENTJENS | Beware of Counterfeit | Thu Feb 27 1997 21:06 | 8 |
| Jos, Thanks for the quick reply and the useful info.
Our server is up again, I retested and you're right. The shareable
image stays loaded. Don't know what went wrong the first time.
Sorry for the wrong statement in -2.
Ren�.
|