-S Port Number

[KMoody]

We launch Progress with a “–S 2640”. At runtime, how can we find out what our –S value is within any program?

Progress: 10.2b SP7
OpenEdge Architect: 3.4.2.R342_v20090122-9I96EiWElHi8lheoJKJIvhM3JfVsYbRrgVIWL
OpenEdge OS: Windows XP Professional 2002 SP3

 

[Cringer]

Why do you want to know that? What are you trying to do?
We have our services defined in the services file and give them a name (eg hob-icmasliv). That way you can change the -S to anything and not have to change .pf files etc.
One way you can do what you want is to parse session:startup-parameters for the entry you want.

 

[GregTomkins]

The _servers VST might be useful as well ... as in,

for each _servers:
disp _servers._server-port

I am pretty sure this resolves the service name from /etc/services, which would make it potentially more helpful than parsing parameters. However, it would be vulnerable to how exactly Progress defines 'servers'.

 

[Stefan]

The _servers VST might be useful as well ... as in,

for each _servers:
disp _servers._server-port

I am pretty sure this resolves the service name from /etc/services, which would make it potentially more helpful than parsing parameters. However, it would be vulnerable to how exactly Progress defines 'servers'.

The _server-PortNum seems to match - beware that it is displayed as a signed 16 bit integer instead of as an unsigned 16 bit integer. So port 37100 is shown as -28436 (37100 - 65536).

I also have 5 records in that virtual table - the first one with _server-type 'Login' matches my port number, the next four records have _server-type set to 'Auto' with port numbers 3002, 3003, 3004 and 3007 - these are my secondary brokers and sql broker ports (based on the pids which correspond with what OpenEdge Explorer reports for them).

 

[WesleySmith]

You could also try using the DBPARAM function this will return the parameters used to connect to the database specified:

DBPARAM ( integer-expression | logical-name | alias )

You would need to parse the result for the -S entry but its a comma separated list so should be easy enough

 

[KMoody]

Thank you for your help!

Since you asked why I'm doing this:
I'm using three different environments: live, testing, and development. Each environment uses a different database. When I run my program, I must pass the port number as a startup parameter to connect to the correct database. By reading the port number, I can determine which environment I'm in and set other variables (such as source and compilation directories) appropriately.

I've followed Cringer's suggestion (parsing the session:startup-parameters), and it's worked great so far.

 

[GregTomkins]

Not that it really matters, but that will leave you vulnerable to someone changing the port# and screwing everything up in a possibly mysterious way. It's a bit like telling someone your web site address using an IP# instead of a domain name. Not that I haven't ...

We have dozens of environments, and they generally take the opposite approach - each environment has a small set of scripts/.pf files that are unique to it, and that script defines the relevant DB's and PROPATH, etc.

 

[KMoody]

When you say "changing the port number," do you mean the actual port number for the database or the parameter we pass to the program?

In the case of the former, I've written the program so that it throws an error if it does not recognize the port number. If someone in IT decided on a whim to switch the port numbers without telling me, then yes, that would be a problem. I'm not sure how easy that is to do. I'll check with the rest of my IT team.

 

[GregTomkins]

I mean if you change either one (the actual port# or the parameter) without changing the other, it will break.

Honestly, I doubt this matters much. Millions of things can and will go wrong and you obviously are capable of figuring out why and fixing it. In the scheme of things, this is probably one of the easier scenarios to decipher.

To me, your whole approach seems a bit backwards and strange, that's all. But if it works for you, I'm sure you have lots of bigger things to worry about

 

[KMoody]

Ah, I see what you mean. We could include the port numbers in the preference files, and that would require a preference file for each environment.

Fortunately, we only have three environments, so our current approach is reasonable. If we had dozens of environments like you do, then it wouldn't be so manageable!