David: Nice thought. There never appears to be an end to the line of people that take short-term profit views to long-term profit potential. Just look at Toyota and General Motors. :-(
Bill -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Wolverton Sent: Friday, August 22, 2008 8:57 AM To: [email protected] Subject: RE: [U2] UONET connection pool problem One of the reasons we CANNOT leave RedBack is the pricing logic of Connection Pools -- At least with RedBack, each new account only costs us the price of a single U2 seat and as long as the volume is not too high, you're good to go... The WebShare gives the bandwidth (how many transactions at once), but the Responders allow us a number of 'available' accounts "cheaply". IBM knows all this -- I've complained about it every chance I get! Hopefully 'Market Noise' will cause them the correct their pricing flaw ... If not, I know Cache or QM will be excited about their pricing in the long run! <g> But one choice you DO have - build an account of nothing but pointers -- AcctName.FileName as the VocEntry -- and then use *those* to allow one Connection Pool port to 'multiplex' accounts. But it's a PAIN and requires a change to your code to know what account it uses and hence what file to open - and as a bonus, it's impossible to secure correctly! But as IBM will tell you - you DO have a a way to do it with just one CP... In my mind, the answer is that Connection Pooling pricing should be more in line with RedBack - buy a 'volume' in one column (pricey) then buy the number of accounts in the other (cheap)... Just my thought.... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill Haskett > Sent: Thursday, August 21, 2008 4:30 AM > To: [email protected] > Subject: RE: [U2] UONET connection pool problem > > Symeon: > > Isn't this the basic problem with U2 Connection Pooling > licenses? They only work on a single account at a single > time. Very bogus for multi-account activity. The > limitations seem pretty broad in scope; mostly by design I'm > afraid to say. > > Bill ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
