We had a customer ask us if it is possible to determine how many active sessions are currently running so that processes can determine if there are enough licenses available to launch another engine.

I know that this can be done through RTI_LH_Info, but I think this is limited to UD5. Please correct me if I'm wrong. Other than that, are there other solutions?

Don Bakke

SRP Computer Solutions, Inc.

I think that if you have the list user locks patch ( included in a fully updated system) then you have rti_lh_info.

Declare Function rti_lh_info



EQU CMD_SESSION_INFO$	TO 1

server_Stats = rti_lh_info(CMD_SESSION_INFO$)





/*

rslt<1> = lhsrvc_version

rslt<2> = SessionsFound

rslt<3> = ActiveInfo

rslt<4> = lh_servername

rslt<5> = lh_serialno

rslt<6> = lhsrvc_mode

rslt<7> = resize_disabled

*/

Another approach is to count the records in syslogins,

I think that if you have the list user locks patch ( included in a fully updated system) then you have rti_lh_info.

…

Another approach is to count the records in syslogins,

Hi Bob - Right, I had already tested RTI_LH_Info with UD5, but this will be for UD4. Do you know off hand if it will work? I seemed to recall OI clients would crash when calling RTI_LH_Info directly.

I considered counting rows in SYSLOGINS, but as per the recent thread from Mike O'Neal, I'm concerned that there could be orphaned rows.

Don Bakke

SRP Computer Solutions, Inc.

OI 9.4 UD 4.7.2 Direct network, RDP, and Parallels 2X. INET and O4W on webserver.

I use RTI_LH_INFO just fine. It is called in List_User_Locks.

Added a dose of SRP_Get_IdleTime (thanks SRP) to compute Idle minutes per User to determine if active, inactive, abandoned/orphaned.

Dave Harmacek - Harmacek Database Systems - near Boston, MA USA

Great information - thank you.

Mike O.

Hi Don,

SYSLOGINS_MFS is supposed to delete the orphaned rows during a select, so one should be able to select the rows and get an accurate count. the Get.Reccount function reads the rowcont from the file header, so it could give the wrong answer. For each row in the SYSLOGINS table the mfs tries to lock the row. If it can lock the record it deletes it.

FWIW,

I have long suspected that syslogins_mfs is a bottleneck during login and could contribute to slowness when a lot of people log in at the same time. When OpenInsight initializes it runs a select on the SYSLOGINS file in order to create the record for the current settopn and clean up orphaned rows. I modified it at some point so that it only performs the cleanup if it can lock a specific record. This should reduce the contention on the table. But perhaps that is why Mike sees extra sessions.

I have been using the system editor to open SYSLOGINS to view the records. I will run a SELECT on the table the next time this occurs to see if that cleans it up. Thanks much, Mike O.

View this thread on the Works forum...