I resolved this issue. Permissions were incorrect on the new device. Missed this when reviewing the issue. Fixed the device permissions, shutdown the instance, updated the cache.cpf file, and re-started the instance

I forgot to set the namespace to %SYS. That fixed it.

A more optimal processing loop:

where hdl.run_obj_method("%Next",[status]):

     <process results>

I was able to resolve this issue by use the %Library.ResultSet' object '%New() method (python)

hdl = self.db.run_class_method('%Library.ResultSet',"%Library.ResultSet',%New",[])

The setting the class name and query to be executed:

        hdl.set("ClassName","%SYSTEM.License")
        hdl.set("QueryName","Summary")

This is then executed:

hdl.run_obj_method("%Execute",[])

The results are process in a while loop while the value of:

status = None

conStat=True

while conStat:
                lStat = hdl.run_obj_method("%Next",[status])

               if lStat:

                       < process results>

              conStat = lStat

There may be more elegent refinements to this python solution but this does accurate extract and return the license usage summary data

In talking to Intersystems in regards to this issue, the query that I would need to use is not defined as a proc. Unknown if that will be corrected in the future or not.

The prescribed solution was stated as:

"...So the solution requires writing your own method in ObjectScript that uses %ResultSet to run the query. Your method then loops through the results, and creates something that can be returned. You call your method from Python" [ joel.solon@intersystems.com ]

So I am closing this issue out. I may pursue that approach at a later date.

I resolved this issue. The intersys.pythonbind3 import on Windows references the dir "C:\Users\<user name>\AppData\Local\Programs\Python\Python37\Lib\site-packages\pythonbind3-1.0-py3.7-win-amd64.egg\intersys". I found that I can copy the contents of that dir to another windows server which allows the process to execute on a remote server even if cache is not installed on that remote server

This is a summary of the report that I am trying to create through a Python process:

For the values in the "local" column I am using the %SYSTEM.License class and setting the values as follows:

  Current License Units Used -     ->  LUConsumed

   Maximum License Units Used  --> LUMaxConsumed

   License Units Enforced               --> KeyEnforcedUnits

   License Units Authorized            --> KeyLicenseUnits

   Current Connections                   --> InstanceConnections

   Maximum Connections              --> InstanceConnectionsMax

The values appear to be match the Management Portal values. The instanceConnections and InstanceConnectionsMax in Python are Null so that is an open issue

For the values in the "distributed" column  are not completely clear. The first two values appear to be from the "%Monitor.SystemLicense" But this is my best guess. So for the distributed column I have:

      hdl = database.run_class_method("%Monitor.System.License","%New",[])

    Current License Units Used -     -->  hdl.get('CurrentUsedDist')

   Maximum License Units Used  -->hdl.get('MaxUsedDist')

   License Units Enforced               --> ?

   License Units Authorized            --> ?

   Current Connections                   --> ?

   Maximum Connections              --> ?

At this point I would like know how to get the missing distributed license values. Also, is the "%Monitor.System.License" the correct source for some of the distributed values?

I have resolved this issue. I used:

execRes = qry.prepare_class("SYS.Database",'CompactLocalList')

to get basic information on each of the databases.  I then used object getters to get the other property values I needed. To get a object handle to each database I used:

_db = db.openid('SYS.Database', <database dir>,-1,-1)

Then

<prop value = _db.get(<property name>)

I believe that I was able to answer my own question. In a csession I used the command "DO ^%GSIZE".  I specified the database path and the global of interest - in this case - STMONITS . The command generated the information I needed.

I appreciate the further edification on the management of the cache database; it will be useful going forward.

Intersystems continues to request a conclusion to this issue. I have already stated and included such. So this will be redundant. I worked with support, copied a cache.dat from another system of the same version to correct the issue.

Per WRC. 2 possible fixes: 1). perform a install/repair, or 2). work with WRC to determine if the corruption is fixable.

Ok, so there isn't a problem with defining the static variable once as is proper design. based upon your response, I found the root cause of my issue. My static variable is a 600 char. string. This apparently exceeds the 'send:' buffer of the terminal script file. I broke the variable into 3 send: statements of 250, 250 and 100 chars in length the last send followed with a <CR>. The script functions without issue now.

SOLVED

The fix is to break the write statement into multiple 'send:' statements with the last send containing the trailing <CR>. So my write statement becomes:

send: WHILE rset.%Next() { set sub=$PIECE(rset.%Get("CurrentDevice"),"|",2) set devLen=$LENGTH(rset.%Get("CurrentDevice"),"|") set port=$PIECE(rset.%Get("CurrentDevice"),"|",3) set dev=rset.%Get("CurrentDevice") set IP=rset.%Get("ClientIPAddress") Write rset.%Get("jobNumber"),",", rset.%Get("Pid"),",",rset.%Get("UserName"),",",$CASE( devLen,1:"null",3:dev,4:"|"_sub_"|"_IP_"|"_port),",",rset.%Get("NameSpace"),",",rset.%Get("Routine"),",",rset.%Get("CommandsExecuted"),",",rset.%Get("GlobalReferences"),",",

send: rset.%Get("State"),!} <CR>

I am running this script on a Windows box. The Cos script file was written using notepad++. Because of this the file had windows line terminators.

The Fix: I updated the file replacing the Windows linefeeds with unix line feeds. The script functions perfectly now.

Thank-you for the help.

Eduard Lebedyuk; thank-you for your help.

Unfortunately, switching to IRIS is not an option as we are preparing to support clients who are not prepared to upgrade to IRIS; at least not yet. I will, though, look at PythonGateway.

Again, thank-you for the help.

Kevin McGinn