Question about "client networking"... first off, are these KB articles still applicable?
The KB's make reference to a "stand-alone ABL client". My understainding is that PDSOE installation would *not* be considered a stand-alone ABL client for "client networking" licensing purposes (even though it is one). Right?
Moving beyond PDSOE... It seems odd to have a license that charges for remote access to a database, after you've already paid for an enterprise database user license. It sounds like they are telling us that the act of moving away from using "shared memory connections" will be an added cost.
So for example, if I were to simply change the startup parameters on an ABL session (_progres.exe CHUI or batch) to use "-H localhost" (loopback) then I'm hearing that it wouldn't work, even on a database server, unless the "client networking" license was installed. Can someone with a "price list" please see how "client networking" is listed? I'm especially curious what would be purchased for moving a batch client session (-b) out of shared memory, and possibly to a remote server.
I've never seen anything resembling a price list from Progress, but you can probably get Client Networking as a concurrent or named user license.
We have a very small number of Client Networking licenses that are needed - I believe to run ABL rcode on a client PC in a Windows GUI application connecting to databases on a remote server. It's part of an application we purchased from a Progress vendor. Most of our application from that vendor runs ChUI applications with direct-connect clients, but the features for the GUI app couldn't be done in the ChUI app.
From my experience, the Progress licensing model has a pretty big focus on number of users (either concurrent or named). Direct-connect ChUI clients get to use the database user licenses, but all other clients seem to have an additional cost associated. Classic AppServer, PASOE, Client Networking, etc.
I have never walked away from a Progress license purchase thinking, "Sweet - I just got a really good deal." But we do get a quality product with quality support.
Client Networking is the minimum required standalone runtime license to either connect to a database on a remote server (using -H -S), or run r-code, whether that is a GUI client user, or a batch job (prowin.exe -b OR _progres.exe -b) running on a work server. Typically out of an abundance of caution I will always install Client Networking alongside any other license.
I can't speak for others' experience, but I would expect if you have x users licensed on your RDBMS license, you will need to have x Client Networking licenses as well, one per possible connection. Maybe the other way around? Similarly because each Client Networking could potentially connect to an AppServer (traditional or PASOE) you would need x AppServer/PASOE licenses as well.
In addition there are two client start up parameters that can force running using a particular license, and if you don't have that license installed, you will get an error:
-rr forces a "runtime-only" client (i.e. Client Networking) to be used. Say you have PDSOE installed, but not Client Networking. Even though PDSOE has all the functionality of Client Networking, you will still get an error if you try to run "prowin.exe -rr", if you don't explicitly install Client Networking as well. This may be the same for AppServer or PASOE licenses as well. Even though they're essentially just runtime clients with additional functionality for Admin Server etc, they're not actual Client Networking licenses.
-rq forces the client to run under the Query/RESULTS license. Again if it's not explicitly installed, you will get an error. Even if you have a license installed that allows you to run RESULTS! So I can run "prowin.exe -p results.p" without a problem with my PDSOE license. But "prowin.exe -rq -p results.p" results in an error.
I honestly don't know why these parameters exist or why anyone would choose to use them (though I've found instances here where they are used - and I get rid of them when I find them).
When I ask how it is listed in the price list, I'm wondering if "client networking" is licensed per concurrent user, named user, core, or host machine, or some combination of those.
Also, on the topic of batch (-b) client sessions, based on a quick test it seems possible to run these types of sessions from any server with an existing installation of "Progress Prod PASOE".
That said, would it be permittable to run a batch (-b) from a server having only the PASOE license (purchased by core)? Or does that scenario count as using a "stand-alone ABL client" which requires us to purchase another license for our PASOE servers? In theory we could easily refactor batch processes and write them as a series of PASOE appserver calls but I'm not sure if OE licensing would demand that we do things that way.
Is there a license associated with running stand-alone ABL clients (_progres) on a machine if they do NOT connect to any databases? Eg. say for instance that all they do is make remote REST and SOAP calls. Sorry for all the weird questions. The client/server improvements in OE 12 may open a whole new world for Progress OpenEdge deployments.
Locate the details of your licensed products to see what model you are licensed for.
Then look at the EULA for you licensed products for definitions.
Then call your Progress Vendor/Supplier/Agent with your questions.
The Concurrent User model was retired after v9, though existing clients on that model were grandfathered. Client Networking is available on Named User and Registered Device models.
>> you can probably get Client Networking as a concurrent or named user license.
Thanks for this. What about a remote client/server batch (background) worker session that isn't even associated with a particular user? What about a remote batch (-b) that only uses SOAP or REST (and no actual connectivity to a database)? Is that a different type of license? What about running a _progres batch from a server that is already licensed for PASOE by core?
I'm assuming that the KB's are there for people to learn what the licenses are for. But I'm not finding enough of the KB's to make complete sense of this "client networking".
>but all other clients seem to have an additional cost associated. Classic AppServer, PASOE, Client Networking, etc.
OK, that is pretty clear. My primary concern was whether PASOE could connect via client-server for free, without an additional "client networking" purchase. I found another article that seems to say PASOE includes client networking.
ie. PASOE is..."An integrated application server for all types of clients including Progress ABL(Client Networking and WebClient),"
> I have never walked away from a Progress license purchase thinking, "Sweet - I just got a really good deal." But we do get a quality product with quality support.
I agree. Thanks for the help. We've experienced some turnover in the Progress salesreps that we've been interacting with over the past two years. What is clear to me is that, in order to plan for your deployment costs, we need to understand licensing for ourselves as well. It is helpful to rely on salesreps, assuming they really understand the licensing themselves, and you don't hear different things when transitioning from one salesrep to the next.
Well, I could be very handy to be able to see how your application behaves when it cannot run/compile sources (on your dev machine).
It sounds like I need to test -rr on a PASOE server that is licensed by core, and see if we are allowed to run in batch mode (-b) for legacy background tasks...
Given the KB article which explicitly says PASOE includes client networking, I don't see why that wouldn't work. More to the point, it would give us a path to move batch jobs off of the (now deprecated) HP-UX platform.
As far as moving our batch processes to any other *NON* -PASOE server, that sounds like a totally different matter. I'm glad I asked. What I'm hearing is that I would need to buy client networking for that, even if *only* to run the r-code. (It doesn't depend on whether or not we connect to an OE db).
Thanks for the tip about -rr. That is new to me.