home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / vms / 13892 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  3.3 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!DREW.DREW.EDU!PCOEN
  2. From: PCOEN@DREW.DREW.EDU (Paul Coen)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: Will lmf kill alpha?
  5. Message-ID: <01GNSEQJ6BGW0011OO@drew.drew.edu>
  6. Date: 20 Aug 92 07:44:00 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 55
  11.  
  12. >Will lmf kill alpha?
  13. > 
  14. >A while ago somebody asked if it is necessary to install lmf 1.1.
  15. > 
  16. >Somebody else answered dec had good products an bad products - unfortunately
  17. >lmf belonged to the latter.
  18. > 
  19. >My understanding is that VMS and ultrix is not widely used in universities and
  20. >other research institutions compared to other unix derivations because of the
  21. >administrative overhead caused by correctly using lmf.
  22.  
  23. What?  That's odd.  We've had our share of annoyances with products
  24. expiring here and there, but I'd hardly say that the product is "hard to use."
  25. At the moment, I've been a stopgap system manager here at Drew, and it took
  26. me about five minutes to figure out how the license utility works under
  27. VMS.  When the issue came up under ultrix, it was mearly a case of finding
  28. out that the command was lmf.  (Well, and entering the PAK information using
  29. vi wasn't exactly a treat.)
  30.  
  31. I can't speak for research institutions, but our experience here with 
  32. the license utility under VMS (it seems to be used more extensivly on the
  33. VMS side than the Ultrix side still) has been fine.  We are part of the
  34. CSLG (Campus Software License Grant) program, which means that once
  35. a year, we copy a com file that builds a new license database for most
  36. of Digital's VMS software.  We still have to enter PAK's for products that
  37. aren't covered, or older products that Digital has discontinued (the
  38. old Lisp, for example), but that we have indiviual PAK's for.
  39.  
  40. You can go into the lmf utility and print out a list of when things
  41. expire (if they expire).  It's not really difficult.  I'd rather have
  42. a central utility with a license database, rather than every package
  43. having its own, built-in key, a key that will make it blow up on x, y,
  44. or z date.  Updating a license with the VMS Patch command always struck
  45. me as kind of cheezy, on packages where that was needed.
  46.  
  47. Anyway, any organization that bases the decision on the "difficulty" of using
  48. a license utility is really looking at things in an odd way.  Price/performance,
  49. the availablility of software, and vendor support are three things that I'd
  50. rate higher than that -- and Digital does pretty well in all three areas.  
  51. Alpha should boost the first two, and I expect that the third will continue.
  52. I can't really see an organization not going with Alpha because of lmf --
  53. especially since Alpha could be running operating systems that don't
  54. HAVE lmf.  Remember -- Digital is selling the chips to other manufacturers.
  55.  
  56. Not getting VMS or Ultrix because of lmf would probably be similar to not
  57. buying a car because that particular model has an ignition keyhole that
  58. is a little clumsy to put the key into in the dark.  And it's not
  59. very clumsy at that.
  60.  
  61. I'm sure that there are lmf horror stories, but I've had pretty good luck with
  62. it.  I could see that an organization that doesn't like the software 
  63. licensing policies could opt to go with another vendor, but that has nothing
  64. to do with lmf itself -- that's pricing and marketing.  And as I mentioned
  65. above, Universities can get a rather attractive licensing package.
  66.  
  67.