[omniORB] omniNames.exe and the -start parameter. omniNames a s an NT service.

[Smith, Norman]

We have omniNames running as a service under Windows NT v4.0 by using the
SrvAny application that comes with the NT options pack (although I believe
it is available for license separately). 

This app allows any Windows 95/NT application to be run as a service under
NT without having to write any special code (it essentially wraps the
application). The installation of the SRVANY add-on as well as configuring
it to host omniNames takes about 10 minutes the first time you run through
it.

FYI

-----Original Message-----
From: Theo Aukerman [mailto:taukerman@logici.com]
Sent: Tuesday, September 21, 1999 11:32 AM
To: 'John Kamp'; 'omniorb-list@uk.research.att.com'
Subject: RE: [omniORB] omniNames.exe and the -start parameter. omniNames
a s an NT service.


I would certainly be interested in seeing the code which installs omniNames
as a service.

How can I get it?

-----Original Message-----
From: owner-omniorb-list@uk.research.att.com
[mailto:owner-omniorb-list@uk.research.att.com]On Behalf Of John Kamp
Sent: Thursday, September 16, 1999 7:22 AM
To: omniorb-list@uk.research.att.com
Subject: [omniORB] omniNames.exe and the -start parameter. omniNames as
an NT service.


I was wondering what the idea was behind omniNames exiting when -start was
used
for the second time. When trying to automate the startup of our servers, I'm
finding that I need to write a script(s) which do something like this:

if omniNames log files exist
   exec=omniNames
else
   exec=omniNames -start 1234
end

This is because issueing an "omniNames -start <port>" is fatel. Is there any
chance that the semantics could be changed slightly so that if omniNames is
issued for a second/third time etc.., its non fatel?

This would help greatly. As it turns out, this change is trivial in the
code.

Lastly, I have code which adds the following command line options to
omniNames.exe:

-install
-uninstall

which installs or de-installs omniNames as an NT service. Is anyone
interested
in seeing this code in omniNames? Or would this be getting far too platform
specific. The problem with NT services is that you need a thread in the
server
itself to respond SCM events. On UNIX, inetd requires no such response
system.
Anyway, this NT service code is generic enough such that any .exe can be
turned
into an NT service in short order.

Thanks for any feedback. We are maintaining this code locally anyhow, it
seems a
shame to have to port it to each new release of omniNames.

Cheers

John Kamp