sockets

[Nancy Palmquist]

I can not take it anymore. This has got to be the craziest logic I have 
ever heard.

What I am hearing is:

A Point of Sale System - that is active all day at a register - lets 
say.  Needs to make a credit card sale, so a socket is used to make that 
transaction.

At the end of the transaction, the socket is closed.  But the license is 
attached to the rclerk session so what you get is the socket stuck with 
that session of rclerk until the end of Session.

So what you seem to be saying is that each user rclerk license must have 
a socket license for their exclusive use.  So if I buy a Runtime license 
with 10 users, I have to buy a license for at least 10 sockets so each 
will have access to a license.  The Socket license is not independent of 
the Runtime license.  Another totally crazy idea when it comes to sockets.

First and foremost, the fact that you license this separately is 
appalling.  Second, how can you build a functioning app with this 
interaction?

What if each rclerk session needs to connect to two places with sockets, 
since the SOCKETCLOSE does not release the socket, they just tied up two 
sockets.    So I would need to buy 2 sockets for every rclerk license to 
make this work.

Even though a socket is usually used for only seconds, you want this to 
flow like this.

Sockets are not sold as a license that is dependent on the Runtime seats 
purchased.  You have programmed this incorrectly if you designed the 
socket to be dependent in anyway on the clerk session that activated it.

Ed is right.  If an rclerk opens a socket and closes a socket the socket 
should be available for use by any rclerk or rreport on the system.  
They should not be associated as you have described and if they are you 
are misrepresenting the licensing entirely.  Ed should not need to buy 
more socket seats.

Ed paid for rclerk seats and socket seats separately.  They should not 
be interrelated at all.  How could he design a proper application using 
that method?

Let's say I have 5 employees that need to make phone calls periodically 
during the day.  I do not buy 5 phone numbers and lines so that they all 
can access the phone.  I put in one line and when one employee is done 
another can use the same line.  That is how you represented the 
sockets.  Ed Bought 5 seats, which is huge since the likelihood of the 
sockets ever overlapping is already off the charts, but he wanted to be 
safe.  You never indicate that there is any connection to the rclerk 
license or sessions.

Ed is right, this is broken and needs fixing.  I had to weigh in on 
this, the discussion was driving me nuts.
Nancy

On 5/15/2012 2:45 PM, Kenneth Brody wrote:
> On 5/15/2012 2:33 PM, Ed Hilovsky wrote:
>> I really need help. I run this as a client socket to another server. I can't
>> "exit" the process as it is a rclerk for a point of sale. The socket usage
>> is in the called process table and connects and does the close according to
>> the documentation of sockets. It seems as though, even using socketclose,
>> the fp license count doesn't de-increnent. So, when I have five users do a
>> sale and credit card payment, all socket licenses are used even though there
>> are no socket connections. It seems to be an issue with the fp license. I
>> need a solution or a "fix" until we can get a real solution.
> [...]
>
> If you need more than 5 users accessing the socket functionality, it seems
> obvious to me as to what needs to be done.
>

-- 
Nancy Palmquist         MOS&  filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com