Ram�n Jim�nez wrote:
A job will always(*) take up an additional license unit. The good news
is that, unlike the CSP license units, the job's LU will be released as
soon as the job has finished.
I've done some testing that appears to disprove this, at least under
some circumstances. A job started from a terminal session shares the
license unit of that terminal session; i.e., it merely increments the
"connection count". As you know, one license unit can hold up to 12
connections.
I assume (but have not tested this) that jobs started from e.g.
%ZSTART can't connect to an existing license unit and use one for
themselves. If so, I don't know what "User ID" this license will use,
but it is possible to change it to e.g. 127.0.0.1 (the userid that
local connections from e.g. Studio or Terminal get). It should also be
possible to share a license unit among multiple jobs this way.
It appears that the CSP license login is somewhat different. I don't
fully understand this, but apparently, although the license for a CSP
session uses the CSP session ID as license User ID,
$system.License.GetUserId(), called from a CSP page, returns an empty
string. This is probably why a job started from a CSP page takes up an
extra license unit, as it has no license user id to connect to. (I
assume this is by design, because CSP pages are ultimately served by a
small pool of processes.)
One way to solve this problem is to make the job login to the license
used by the calling CSP page, using $System.License.Login(). I do this
with a wrapper routine. A very simplified example:
In the CSP page:
================
Job JobEntry^fwUtils("h 10",%session.SessionId)
In ^fwUtils:
============
JobEntry(Job,Login)
If $Get(Login)'="" Do $System.License.Login(Login)
Xecute Job
Quit
(Note that this Jobs the wrapper routine, not the actual job you want
to run. The wrapper routine then executes the actual job. Added
advantage of using a wrapper is that you can easily Job expressions,
classmethods etc., and set a default error trap.)
A quick test reveals that with this mechanism, the job does indeed
connect to the CSP license, so no additional license slots are used.
Note that for the brief period between the start of the job and the
call to $System.License.Login(), an additional license *is* used. This
could perhaps be circumvented by using
$System.License.DeferUserIdentification(), but I have not tested this.
The obvious solution of using $System.License.Login() in the CSP page
*before* doing the Job has the disadvantage that even without actually
Job'ing anything, *two* connections to the license are used.
HTH,
Gertjan.
