Regardless of how BMC markets, advertises or how a sales person may present them, I have always considered a "Floating-Write" license primarily as a write license shareable by two or more non-concurrent users. I've never considered them a concurrent read license with occasional non-concurrent write permission.
Back in the day, (right or wrong) the sales folks would present these licenses as "something for users working on different shifts or not likely to login at the same time" and that is how I have always considered them. If I had a limited number of floating licences and shared them at a high ratio among concurrent users, I should reasonably expect to experience "token unavailable" errors; HOWEVER, that may be acceptable to a given org (for example, folks creating/modifying ARSystem or Web reports). If I have support staff working tickets who need that "write" capability more reliably, they either get a Fixed -or- I would share floats (example) 3:1 across 3 different work shifts. What I'm not clear on is how could BMC have any say in whether I assign floats at 2:1 or 10:1 if I so choose? If the organization can tolerate the "token unavailable" errors, so be it. If not, then it is up to the org to decide what changes to make whether that's buying more licenses or reassigning licenses, users and/or schedules to reduce the number of concurrent floating users to mitigate the issue. Or did I completely misread the original poster's issue? On Fri, Oct 30, 2015 at 9:29 PM, Mueller, Doug <doug_muel...@bmc.com> wrote: > Folks, > > First, at the start of the thread, there was no version of the product > listed. And, as Misi has called out, there was a flaw with how the > overview console was constructed and working that would cause a license of > the application to be grabbed just for opening the overview consol. And, > as Misi also called out, that flaw was corrected with the 8.1 release of > the system so that opening just the overview console will not grab a > token. We decided that just looking at the list in the overview console > should not be considered interaction with the application. > > Second, the system is constructed to obtain your token when you interact > with the application (or system for an AR System license) to do work. That > is either read or write, it obtains your assigned token type. So, if you > OPEN an incident, you will indeed grab your incident token. > > So, I suspect that the issue from the original message is present because > the version of the applications is pre 8.1 (if it is 8.1 or later, then > have a conversation with support because just opening the overview console > without opening a ticket from that console or opening up other forms in the > application should not obtain a license from 8.1 and later). > > The behavior of floating licenses has been and remains if you do actual > interaction with the application, you will obtain a token. > > I hope this helps, > > Doug Mueller > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky > Sent: Friday, October 30, 2015 3:17 PM > To: arslist@ARSLIST.ORG > Subject: Re: Serious flaw in BMC Remedy Licensing > > Hi, > > This might be considered a flaw, and if my information is correct it has > been fixed in version 8.1.f I you use the OVERVIEW CONSOLE in 8.1.x it does > NOT consume any application write licenses. This is something that I have > read somewhere, and I have not tried to prove it myself. So Ryan, are you > using a version prior to 8.1? > > In all other circumstances any access to data in a form will "grab" the > write token id one is available. This has worked the same way since the > beginning, and I personally started with version 1.1... > > If a license token is not available you will get a FLOATING READ, and will > get an error first when you try to modify data. > > As for APPLICATION LICENSES they work the same way, but only "grab" the > license token when you access form data in a form tagged for that specific > applications. Some forms are tagged, and some are not tagged. > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > > Didn't think BMC wanted me to post this on their communities but we > > have found what I would consider a serious flaw in the way that BMC > > counts a license against a user. > > > > Here is the scenario: > > > > User A has been giving a FLOATING license for Incident. User A has his > IT > > home page configured as overview console to display all INC's, CR's, > > and TASKS assigned to his group. > > > > User A's support group has NO incidents assigned to it. > > > > User A logs into Remedy and immediately shows up in license review as > > consuming a "write" license (NOT A READ LICENSE) for Incident. > > > > User A refreshes his overview console every half hour. Since the > "write" > > license doesn't switch back over to "read" for 15 minutes, he is > > virtually consuming a "write" license for Incident all day long. > > > > And this is the really stupid part. He has never even opened an > Incident. > > > > > > What we have found through our use of the RRR License tool is that > > some of our top "Incident License" users are people who have NEVER even > opened an > > Incident. We've taken the list of people who (according to BMC) have > > consumed an Incident "write" license and searched for their login ID in > the > > HPD audit log and work log forms. To our amazement, over 1/4 of them > aren't > > in there. > > > > So, this begs the question. Has anybody else figured this out? If > > so, does it bother you as much as it bothers us that a user who has > > been given an Incident User (FLOAT) license and NEVER uses it, can > > still cost your organization money in license fees? > > > > I know we can adjust our licenses and give out Incident viewer but it > > seems like an administrative nightmare to figure out who should get > > what when the real answer would be for the tool to do a better job of > > counting who is really using a license. > > > > ______________________________________________________________________ > > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > "Where the Answers Are, and have been for 20 years" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the > Answers Are, and have been for 20 years" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
