home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.vms
- Path: sparky!uunet!usc!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!indyvax.iupui.edu!harvey
- From: harvey@indyvax.iupui.edu
- Subject: Re: Will lmf kill alpha?
- Message-ID: <1992Aug26.163743.1@indyvax.iupui.edu>
- Lines: 22
- Sender: news@usenet.ucs.indiana.edu (USENET News System)
- Nntp-Posting-Host: indyvax.iupui.edu
- Organization: Indiana University
- References: <9208191732.AA11146@ucbvax.Berkeley.EDU> <1992Aug21.140033.2240@inland.com>
- Date: Wed, 26 Aug 1992 21:37:43 GMT
-
- In article <1992Aug21.140033.2240@inland.com>, allebrandi@inland.com (Tom Allebrandi) writes:
- >> administrative overhead caused by correctly using lmf.
- >
- > If you want to talk about administrative overhead, open your eyes. We
- > just went through a main CPU upgrade for our VAX/VMS cluster. For the
- > most part, for those products which needed new licenses, the LMF
- > managed products came right up; the non-LMF managed products gave us
- > some form of trouble.
-
- This has been our experience too. I actively discourage the purchase of
- any software for our system that uses it's own (often harebrained) license
- management system. I have wasted much more time with these than I ever
- spent "correctly using LMF." I still can't decide which is worse, the
- software that tried to find our hardware Ethernet adapter address but didn't
- know what a DEBNA was (i.e., could not be convinced to look at ETA0) or
- the silly package that wouldn't run half the time after we went to VMS 5.0
- (SMP) because it was misusing the CPU SID for machine identification (this
- was on an 8800)...
-
- --
- James Harvey IUPUI OIT Technical Support
- harvey@iupui.edu uucp: iugate!harvey bitnet: harvey@indyvax
-