John, As you know, I'm not a BMC employee...so all of my understanding of things comes from that perspective :)
As I understand it the overview console utilizes a plugin to pull the information...but, being I don't run ITSM where I work...I can't confirm this....but even with that said...even if the plugin was pulling the information...it's the SERVER that determines what type of allocation is made...so....if I were to guess, and this is 100% a guess...I would guess that something was re-written in the server that says something along the lines of 'if the query is coming in from 'this client' and the user is floating...don't allocate a write token'....and I would assume, that the 'this client' portion of that is specified using the client type function when that plugin connects.... So...trying to replicate it would be difficult....but in theory not impossible.... On Mon, Nov 2, 2015 at 11:02 AM, John Sundberg < john.sundb...@kineticdata.com> wrote: > ** > Just wondering — say you wrote your own console … how can you not “tap” > the license unless you need it? > Is this reserved only for the BMC provided consoles? > > > -John > > > > > On Mon, Nov 2, 2015 at 11:34 AM, LJ LongWing <lj.longw...@gmail.com> > wrote: > >> ** >> Ryan, >> As I understand it, this isn't a 'flaw' that needs to be >> 'backported'...but instead, a change in direction from their long standing >> stated policies. >> >> As I understand it, and somewhat agree with...the reason that a Float >> Write is accompanied by doing a query, instead of at attempt to write, is >> quite simple. If a user is doing a query for some data, they are more than >> likely trying to find something that they need to modify, and as such, will >> need a write license in the near future. Along those lines, if they didn't >> request a write till they were actually trying to write, it might be >> frustrating to the user experience. >> >> Now...with that said...when the policy was put in place (as I understand >> it...almost from the beginning...certainly not recent)...there was no >> concept of an 'overview console' that allowed people to query every form in >> the system for relevant information and consolidating it into a >> console/dashboard type of functionality....when this was done, and applied >> the old methodology of 'a query likely means a coming modify', then as you >> know, this then causes massive quantities of float licenses to be >> unnecessarily consumed. When it was pointed out to BMC that this was >> occurring, and how 'unfair' it was, BMC apparently decided to change it so >> that the overview console was allowed to do its queries without incurring a >> penalty on the cost of the system by allocating licenses to everyone in the >> console. >> >> So....while it was a design choice with unintended financial >> consequences...it was not a flaw, or a bug....and in order to avoid this >> feature, you need to be on the version of the tool that changes the >> direction and avoids this one scenario.... >> >> I'm not a major fan of the 'it's a feature, not a bug' discussion...but >> in this case, I agree with BMC's logic that it wasn't a bug....I don't >> fundamentally agree with the idea of allocating float write on query...but >> it's not my tool, and I don't make the rules :) >> >> On Mon, Nov 2, 2015 at 9:15 AM, Ryan Nicosia <ryan.nicosia....@socom.mil> >> wrote: >> >>> We are on 7.6.04 with Mid Tier 8.1. So, based on Doug and Misi's >>> response it sounds like it is fixed in newer releases (we are moving to 9.x >>> this coming spring). >>> >>> That begs a follow up question or 2. >>> >>> If this is indeed a flaw with 7.6.04, one could argue we have been >>> overpaying for licenses since 2012. Unfortunately, since the user.log logs >>> these interactions and we are using the RRR license tool to determine how >>> many licenses we need, it appears there is no easy way to figure out how >>> many actual write licenses we need and should assign. >>> >>> 1. Does anybody have any recommendations on how to address with BMC when >>> with our annual license renewals? >>> >>> 2. We have queried SQL with the 1900+ write license consumers and >>> determined that 500 of them have never updated a ticket or entered a work >>> log entry in a ticket. Would setting them to Incident "viewer" be a good >>> work around? >>> >>> 3. Is what has been fixed in 8.x relative to the "flaw" something we can >>> apply to our 7.6.04 environment? >>> >>> Thanks AR listers!! >>> >>> Ryan >>> >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> "Where the Answers Are, and have been for 20 years" >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > > -- > > *John Sundberg* > Kinetic Data, Inc. > "Your business. Your process." > > 651-556-0930 I john.sundb...@kineticdata.com > www.kineticdata.com I community.kineticdata.com > > > _ARSlist: "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"
