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.