Path: utzoo!attcan!uunet!husc6!mailrus!ames!lll-tis!helios.ee.lbl.gov!nosc!gandalf.nosc.mil!dennis
From: dennis@gandalf.nosc.mil (Dennis Cottel)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo's Network License System (NLS)
Message-ID: <815@nosc.NOSC.MIL>
Date: 22 Nov 88 00:44:50 GMT
References: <3fccff2d.bf13@apollo.COM>
Sender: nobody@nosc.NOSC.MIL
Reply-To: dennis@gandalf.nosc.mil.UUCP (Dennis Cottel)
Organization: Naval Ocean Systems Center, San Diego
Lines: 33

[In article <3fccff2d.bf13@apollo.COM> holbrook@apollo.COM (Alan R. Holbrook)
addresses Dave Funk's NLS comments.]

In general, we are in favor of the NLS scheme and have long been
bothering vendors to implement something like it.  Having Apollo do it
once, right, will be a big help for all the people who have to install
and maintain vendor applications software.

However, Alan says:
>Concurrent access licensing adds about 400 milliseconds of elapsed time
>to the application.

An extra half second per application may not be bad for a large
monolithic applications program like Mentor or somebody's CASE tool
environment, but it's going to be an entirely different thing if, for
example, every compiler invocation takes an extra half second!

Alan also says:
>Concurrent-access licenses are in fact locked to the servers you
>choose.  To ensure high availability, we recommend running multiple
>servers and distributing licenses among them.

Suppose you split all your licenses in two parts onto two servers, and
then one server gets seriously sick and won't be available for a week
or two.  (It can take us that long to write a repair order!) That means
you are stuck with half your software for that time.  Not pretty.  What
provision has Apollo made for alleviating this scenario?  What is the
argument for locking the license servers to particular nodes?

Thanks to Alan for addressing the previous questions.

   Dennis Cottel  Naval Ocean Systems Center, San Diego, CA  92152
   (619) 553-1645     dennis@NOSC.MIL       sdcsvax!noscvax!dennis