Hi Michelle I have always recommended my clients opt for as many fixed licenses as they can, rather than using floating licenses, and this test just reinforces that opinion.
It looks like when estimating license requirements, you now need to consider how frequently occasional users log in to the system, rather than how often they need to modify a record. If they log in more than twice a week for more than an hour, they are a candidate for either a fixed or read license. Only users who are truly 'occasional' should have a floating license. Also, there is a real training requirement here to make sure that Mid-Tier users log out correctly, rather than just closing the browser. Moving more users to the thin client will only exacerbates this problem. A couple of years ago I did some work for a client where they had 24 hour operations, with a couple of fully staffed shifts, and a graveyard shift with fewer people at work. Remedy had recommended and supplied all floating licenses as being 'ideal' for shift workers, but actually at shift changeover time it was a nightmare with half the new shift being unable to work. The solution was to change to all Fixed licenses, and all staff could be given a fixed license for the same overall cost. Also, with good application design and using 'allow any user to submit' field permissions, and submitter mode locked may allow many users to operate with a Read license... and then, if you have more than one Remedy server, the advantage of fixed licenses over floating is even more pronounced. So you're in a situation where you're running out of floating licenses and need to buy some more. Rather than buying say 10 extra floating licenses, consider buying 25 extra fixed ones and allocating them to your 25 heaviest floating users. This will probably free up more of your floating tokens than the extra floating licenses would have given. I have rarely seen a Remedy installation where a large number of floating licenses were really cost-effective - by all means have a few, but make the majority of your license fixed. Just MHO. David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Thursday, September 28, 2006 12:46 AM To: arslist@ARSLIST.ORG Subject: Re: Read (floating) license Hi, David There was a search menu on the Group field. But, I had to test this further. Here I go beatin' a dead horse. I created a display only form with not one single field, button, workflow nor any other object. I opened the form on the Mid-Tier with my test floating license. And again it immediately took up a Float WRITE. It still doesn't flush after a few minutes, etc. <USER> <TID: 0000002324> <RPC ID: 0000263453> <Queue: Fast > <Client-RPC: 390620 > <USER: clucero > /* Wed Sep 27 2006 18:28:59.8080 */ FLOAT GRANT WRITE clucero (1 of 5 write) Even if we accept the premise about search menus, etc... Isn't it unrealistic to assume that a form would have absolutely no workflow and absolutely no search menus? In other words, in almost all cases, there will be a search menu, workflow on window open or loaded, a table field or something? Meaning a FLOAT GRANT WRITE will almost always be taken up upon log on. So far in my testing, it is 100% of the time. In my experience it doesn't drop off after 5-10 minutes of activity. It either expires after the admin defined float license timeout or drops off when I click Logout. I think that if one isn't suppose to be granted a WRITE until after some sort of activity (and the behavior clearly doesn't work this way) then this is definitely an issue. OK, OK, I'll leave it alone. Thanks for listening. Michelle PS Remember we all could be experiencing different behaviors on different versions. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of David Sanders Sent: Wednesday, September 27, 2006 5:32 PM To: arslist@ARSLIST.ORG Subject: Re: Read (floating) license Hi Michelle I think that if the form has a field with a search menu on it, this can cause the floating token to be grabbed just by opening the form. Regards David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Wednesday, September 27, 2006 10:38 PM To: arslist@ARSLIST.ORG Subject: Re: Read (floating) license Hi, Misi: Hope you're doing OK. Is the operative word here "should" instead of "NOT"? I just performed a very simple test on the SHR:ConsolidatedList form, by opening it in submit mode. There is no active link workflow on this form. There is a single filter that fires on Submit, Modify and Merge. Wouldn't opening a form qualify as accessing the server? Bottom line, as soon as I logged in, my test account showed up as Floating in both the Admin tool AND the User Log. I have performed no actions other than placing the URL to the form in the browser, pressed enter and logged in. To the other point that was made. I've also let the same form sit idle for over 10 minutes. It is sitting idle as I type. It still displays as Floating. It has not been released according to the User Log. If accounts were released after sitting idle for 5 - 10 minutes (gosh I wish; imagine the reduction in cost), there wouldn't be a Float License Timeout minimum setting of one hour. Maybe we should get Criss Angel from Mind Freak (US TV Reference) to figure this out for us. All that said, the behavior in your environment could be different. Here's mine: Win2003/IIS/6.0/Mid-Tier 7.0 P1 Win2003/SQL Server 2000/ARS 6.3 P11 WinXP Pro/Admin Tool 6.3 Special Support patch 12 My two cents worth and minor test, Michelle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: Wednesday, September 27, 2006 3:52 PM To: arslist@ARSLIST.ORG Subject: Re: Read (floating) license Aaron, I have recently had some communication with Doug Mueller, and you are almost right. Opening a form in Submit or Search mode should NOT grab a license, unless there is workflow that somehow contacts the server when the form is opened. There is a difference concerning the user log file, where users does not show up at all until they try to grab a licenses (i.e. by performing a search, triggering workflow that does a set-fields, etc.). Best Regards - Misi, RRR AB, http://www.rrr.se > As always with licensing it's somewhat vague, but my experience has been > this: > > > > When a user with a Floating license assigned to them logs in, they show > up in the User License list as Read(floating) immediately. > > -If they sit there without doing anything, they disappear from the User > License list after a short time (5-10 min) > > -If they open a form (in ANY mode), they are then listed as Floating. > > -If they log out, they disappear from the User License (no matter how > they were listed before) > > -If they are listed as floating and don't take any action for 1 hour, > they revert to Read(floating), and shortly thereafter disappear from the > list. > > > > As far as floating license token allocation, I tested our system with 10 > licenses, and found: > > -There could be more than 10 users marked as Read(floating) with no > problems. > > -When users opened any form, in query or submit mode, they changed to > Floating (and took a floating token) > > -Once there were 10 users marked Floating, then other users remained > marked as Read(floating) when quering or submitting. > > -Users marked as Read(floating) could not Modify while there were 10 > others marked Floating. > > -When someone logged out, the next Read(floating) user to perform an > action (query, submit, or modify) was changed to Floating. > > > > > > -Aaron > > * Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Cleereman (IT) > Sent: Monday, September 25, 2006 11:40 AM > To: arslist@ARSLIST.ORG > Subject: Read (floating) license > > > > Hi All, > > We're using ARServer 6.3, Patch 17. > > I'm using Manage User Licenses from the Admin Tool, with the following > options: > License Category: Server > Category: Current Licenses > License Type: Floating > > I was seeing the following: > Floating - 10 users > Read (floating) - 2 users > > Another user who is assigned a Floating license just logged in, and I am > now seeing > Floating - 10 users > Read (floating) - 3 users > > I've double-checked our server licensing, and we have 25 AR User > Floating Licenses. > > I have the feeling I should know this, but it's a Monday, and I'm not > seeing it in the help file or my Admin Guide. > > Does anyone know why 3 of the users are showing a "Read (floating)" > instead of "Floating", when we should have 15 unused AR User Floating > licenses remaining? > > Eric Cleereman > > __20060125_______________________This posting was submitted with HTML in > it___ > > > SunCom is the wireless company that's committed to doing things > differently. > > Things we want you to know. > > This e-mail and any files transmitted with it are confidential and are > intended solely for the use of the individual or entity to whom they are > addressed. This communication may contain material protected by the > attorney-client privilege. If you are not the intended recipient or the > person responsible for delivering the e-mail to the intended recipient, be > advised that you have received this e-mail in error and that any use, > dissemination, forwarding, printing or copying of this e-mail is strictly > prohibited. > > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ________________________________________________________________________ ____ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org