licensed user counts
- Thread starter syddie
- Start date
tamhas
ProgressTalk.com Sponsor
So that's the old concurrent user model. As I recall ... the docs are on my other box which is in the shop 
... the standard was that one only counted batch processes at all if there were more of them than there were people users. Remember that none of the models is about the number of connections. It is always the number of people or machines. So, four concurrent sessions from one client is only one license. I think the thinking is that generally batch process are basically all on the same box and all the same "user" so at most they would count as one license, but in practice they just ignore batch unless one comes up with an application which has more concurrent batch processes than there are real users.
This is a bit more complicated in OE10, but many of the same principles apply, except they are clearer about reaching through to the real user. I.e., if your batch process is some kind of front end for supporting 100 users using some other technology, they are going to count the 100 users, not the batch process.
... the standard was that one only counted batch processes at all if there were more of them than there were people users. Remember that none of the models is about the number of connections. It is always the number of people or machines. So, four concurrent sessions from one client is only one license. I think the thinking is that generally batch process are basically all on the same box and all the same "user" so at most they would count as one license, but in practice they just ignore batch unless one comes up with an application which has more concurrent batch processes than there are real users.This is a bit more complicated in OE10, but many of the same principles apply, except they are clearer about reaching through to the real user. I.e., if your batch process is some kind of front end for supporting 100 users using some other technology, they are going to count the 100 users, not the batch process.
Hi Tamhas,
The only person user is an admin user. The server is used to talk to multiple servers (handling ingoing and outgoing batch transaction files. The spawned processes run rexec and ftp commands to linux boxes which are triggered by another server via mqseries. 5 main batch processes handle this.
We currently can have around 25 batch processes running at a time during a 3 month seasonal run. The rest of the time very little is happening.
The only person user is an admin user. The server is used to talk to multiple servers (handling ingoing and outgoing batch transaction files. The spawned processes run rexec and ftp commands to linux boxes which are triggered by another server via mqseries. 5 main batch processes handle this.
We currently can have around 25 batch processes running at a time during a 3 month seasonal run. The rest of the time very little is happening.
TomBascom
Curmudgeon
On the one hand you're running v9 so the usual rule is "the greater of either warm bodies running interactive sessions or batch processes". From your description you would need to count the largest number of concurrent batch sessions. So you would need a 25 user license.
On the other hand if your batch processes are really a form of "connection pooling" (there are, for instance, several "webspeed alternatives" that fall into this category) then it gets more complicated. In that case you need to count the connections being pooled.
PSC sales weasels have been known to claim that if any data that ever resides in a Progress database is ever exposed by a web browser that you then need to license every possible internet user on the planet. (The weasel anti-defamation league is sure to sue me for that comment -- so please contribute to my legal defense fund...)
They are obviously insane when they make such claims -- the best defense is to laugh hysterically and offer to buy the next beer. Make it clear that you know that they were joking. Because if they smell even the slightest whiff of weakness they will put that "sale" on their forecast and then they will be painted into a corner that they cannot get out of. Ditto if they mention the words "platform change", "re-licensing" or "name change". These are code words for really, really big unearned commission. It's a game of chicken and you will be road-kill if they have even the smallest inkling that they can get away with it. They will tell you with a straight face that there is nothing that can be done, that everyone is doing it and that those nasty evil people back at corporate are making them do it. Laugh again and buy them another beer. Remember that this is all about the commission. If you can redirect their attention to some actual money that you really will spend if they will simply come to their senses and stop fooling around before you have to regretfully inform your management that ... (I'll leave this as an exercise for the reader) A word or two about a bird in the hand vs. lots of birds in bushes might be constructive
OpenEdge 10 licensing cures the ills related to licensing every imaginable user on the internet and may even offer some nice alternatives to counting the maximum concurrent users. But beware of the "platform change" -- it is officially dead. No sales weasel is supposed to be charging it anymore. Not that a little thing like policy stops them from trying.
On the other hand if your batch processes are really a form of "connection pooling" (there are, for instance, several "webspeed alternatives" that fall into this category) then it gets more complicated. In that case you need to count the connections being pooled.
PSC sales weasels have been known to claim that if any data that ever resides in a Progress database is ever exposed by a web browser that you then need to license every possible internet user on the planet. (The weasel anti-defamation league is sure to sue me for that comment -- so please contribute to my legal defense fund...)
They are obviously insane when they make such claims -- the best defense is to laugh hysterically and offer to buy the next beer. Make it clear that you know that they were joking. Because if they smell even the slightest whiff of weakness they will put that "sale" on their forecast and then they will be painted into a corner that they cannot get out of. Ditto if they mention the words "platform change", "re-licensing" or "name change". These are code words for really, really big unearned commission. It's a game of chicken and you will be road-kill if they have even the smallest inkling that they can get away with it. They will tell you with a straight face that there is nothing that can be done, that everyone is doing it and that those nasty evil people back at corporate are making them do it. Laugh again and buy them another beer. Remember that this is all about the commission. If you can redirect their attention to some actual money that you really will spend if they will simply come to their senses and stop fooling around before you have to regretfully inform your management that ... (I'll leave this as an exercise for the reader) A word or two about a bird in the hand vs. lots of birds in bushes might be constructive
OpenEdge 10 licensing cures the ills related to licensing every imaginable user on the internet and may even offer some nice alternatives to counting the maximum concurrent users. But beware of the "platform change" -- it is officially dead. No sales weasel is supposed to be charging it anymore. Not that a little thing like policy stops them from trying.
tamhas
ProgressTalk.com Sponsor
I.e., there is a key issue here separate from your original question as to what it is that these batch processes are doing and whether you need to license the process or the users of those processes. That aside, if the license is appropriately focused on the simultaneous batch process, then yes, a child process would be considered a separate process since ABL is inherently single threaded.
The batch process are purely to control what is sent via ftp or to run a remote unix command. The 5 main processes check the status of a request held in a table, so as to know which child to kick off. ie a data extract process or a communication process etc. thus guaranteeing a successfull comms to a remote server. There are never any database connections outside of these internal processes. Unreliable comms dictates that all data transactions are done via batch files. All remote servers are appropriately licensed unix Progress servers.