How to determine os of connected database

IF OPSYS = "UNIX" THEN UNIX ls.

ELSE IF OPSYS = "WIN32" THEN DOS dir.

ELSE MESSAGE OPSYS "is an unsupported operating system".

I understood the question more as for the server's os, not the client os as this code is returning.

I'm curious to learn about the use case, as I believe the server's os should be irrelevant for the client. Or?

The OS should not matter and hence is not retrievable.

Being able to determine the OS could tempt you into programming specifically for that OS, which is a bad idea. Program for the database, not the OS.

If you ever need to move the db to a different OS, your programs should still be able to work.

I'm indeed looking for the server os. We solve client os issues mainly with the {&OPSYS} preprocessor.

We need this for example to calculate the number of logins which can be Windows clients as well as Unix clients. As far as I know you need to know on which os the database is running to find the right _connection records. The _connect-device and _connect-type fields are handled slightly different depending on which os the database is running.

Our posts just crossed. But see my example above, we need it for finding the right _connection records to calculate unix and windows logins. Progress seems to handle those differenty depending on de database os.

Well, there are a number of other ways to check the number of connections.

The first one is doing it manually with ProMon.

The second one is by reading the YourDb.lic file and checking it there.

The third one is by reading from the _License system table in your database.

Both of these "License" methods can not be trusted due to a known bug where the user count is increased during online backups, but not decreased when the backup has completed. Don't know from the top of my head whether this has already been fixed and if so, in which SP.

The last method is the one we use: Reading from the _Server system table and accumulating for each server the number of connections.

This doesn't count the connections from the local machine on which the db is running (only the connections for which servers are used), but shouldn't cause too much discrepancies in your result.

You could use the _Connect system table to check the machine from which the connection is made, but you have to filter out SYSTEM connections and maybe batch connections.

From the machine (_Connect-Device) you have to translate manually to an OS, probably using your own lookup table.

Thanks for you suggestions.

We sell licenses for our product and differentiate (also in price) in Unix and Windows clients. If a user logs in we need to determine if the number of logins exceeds the number of licenses. So knowing the number of remote or local connections is not enough, since we need to know now many Unix and Windows connections there are. We have a working routine based on the _connection system table, but it is sort of hard coded per customer depending on their database os. It would be nice to be able to do this ion a more flexible way.

I think promon is probably using the same system tables to show connections by the way.

It's not a big deal though, it would just make things easier if I know in which os the database is running. There is a lot of other information you can retrieve, like the parameters that the database was started with, the physical name etc. Why not the OS?

Well, I can think of one remaining really (and I mean really) dirty way, by using the _FileList table.

This table lists the segments in _FileList-Name that make up the db.

You could check these segments to look for Unix-type (/whatever/path/db/mydb.db) or Windows-type (C:\DB\mydb.db) paths.

Basically, Windows-type paths usually have a drive-letter and Unix paths don't, I guess.

And the slashes are reversed.

So, cheat by using a combination of SUBSTR, ASC(), stuff like that.

Thanks, that's what I was looking for. Sure, it's a bit dirty, but good code should be a bit dirty every now and then ;-)

alex_u4a wrote:
We sell licenses for our product and differentiate (also in price) in Unix and Windows clients. If a user logs in we need to determine if the number of logins exceeds the number of licenses. So knowing the number of remote or local connections is not enough, since we need to know now many Unix and Windows connections there are. 

One way to skin this cat was to have a PP find a record corresponding to the login, share-lock it, and then leave.Since the PP buffer stayed in scope, the share-lock would persist as long as the client session was connected. This enabled other sessions to FOR EACH through the table, count the records it couldn't exclusive-lock, and thereby come up with an active user count.

What in the world is the justification for charging differently for a Unix client than a Windows client?  Is there a difference in functionality?

I will be out of the office until Monday 8th August with little email access. If you need to contact someone within the office then please phone reception on 01904 727150, otherwise I will reply to your email as soon as I am able. Thanks, Andrew.

Yes, one is character based and the other has a grafical user interface. The gui is richer in functionality for obvious reasons.

Using the share lock to keep track of logins sounds as a good alternative for counting the _connection records. In our case it wouldn't provide a complete solution though, since we also have to deal with logins from 3rd party products which we want to keep track of as well.