OpenEdge Management - Appserver environment variable defaults

DownUnder

New Member
Hi all,

I'm a newbie on this site. This is my first post ... :)

I was hoping someone might be able to shed some light on something I've been wondering about, or whether I need to log an issue with Progress.

I'm currently running OpenEdge Management and Explorer Standard Edition Version 10.2A0000 and have found that when I create an AppServer, it automatically places the name of the AppServer in the Environment Variables folder/tab.

This, on the surface of it, looks to be a good thing, as it implies a mechanism whereby my application might be able to determine the name of the AppServer a process is running on (if running remotely).

However, unfortunately it just contains the name, not an actual environment variable setting (e.g. it will just have 'asbroker1' instead of something like 'appservername=asbroker1'). The default as it current exists is invalid, and cannot be queried from the 4GL using OS-GETENV().

Does anybody happen to know what variable-name it should be set to, if the automatic mechanism that appears to be (almost) present was working correctly?

My short-term solution is to get anyone from my company who might be setting one of these up to insert a prefix of 'ASname=' in front of whatever the appserver name is (e.g. 'ASname=devSystem' when it defaults to 'devSystem' for an AppServer of the same name).

The reason I ask is I need to know the name so that I can have 2 AppServers per system (1 broker and 1 agent, for SonicMQ messaging and Job Processing / batch) etc. for each kind of system supported (e.g. development, testing, production or possibly by client-name for multi-client ASP servers), whereby the broker knows which agent to call. I want to use this mechanism, and need a variable name to use (currently 'ASname' as a guess).

If anybody has any comments, suggestions, information, insights or solutions related to this issue it would be much appreciated.

Cheers.
 

GregTomkins

Active Member
I read your post 3x and I can't quite figure out what you are getting at. But since I am naturally predisposed towards people from Australia, I thought I'd make a weak attempt at help:

Our app runs a Progress Win32 client connected to potentially any of about 50 AppServer farms; some customers, some internal testing and development. When we start it up, we read a file called 'sites.txt' that resides on a shared folder. This file contains the AppServer connection smarts for each AppServer farm. We use it to construct a CONNECT statement for whichever environment the user wants to access.

When we need to add a new customer or test environment or whatever, we setup the AppServer side as normal, and then we also add an entry to sites.txt. I suppose this is duplicative and it would be slicker if we could probe our network for available Name Servers or something, which it kind of sounds like what you are trying to do. That would not be of much benefit to us though, so I've never tried it.

HTH,
Greg
 

DownUnder

New Member
Greg,

Thanks for your reply. :rolleyes:

I'm sorry my previous post needed to be re-read that many times, still requiring clarity ... it must be the accent (mate) !

The thing that I need to achieve is to detect the name of the AppServer that the program is running on, from the 'startup' procedure (as defined in the management console appserver configuration screen, 'Agent' folder tab, that initialises and remains persistent).

To further explain, perhaps starting from the beginning:
- we have various 'systems', which might be for various clients and possibly multiple for some clients (e.g. development, test, production)
- we have two AppServers per 'system' - a broker and an agent
- the broker is for running one or more SonicMQ listeners
- the agent is to run jobs for the broker, so that each incoming job request received via SonicMQ can be processed and the results returned to the broker (to send back as a SonicMQ response message)

We use the 'startup' procedure for two things:
- to auto-start the broker, so that the SonicMQ listener(s) are available when the server / service is started and/or restarted
- to pre-initialise the agent processes so that all configurations, temp-tables (for caching) etc. are pre-loaded prior to any job coming in

So that the broker knows which agent to call, it needs to know which appserver it is running on (the naming convention is <system_name>_broker and <system_name>_agent)

I am aware that I could just pass the <system_name> string as a parameter (as set in the config. screen), but as we may have a very large amount of AppServers set up (although not as many as you!) I'm attempting to 'dumb-down' the setup process and remove potential for mistakes in configuration. It's been simplified to the point where the only system-specific thing you need to set other than the AppServer name (when you create it) is the work directory, with all other defaults being generic (although a few are different from Progress's, they don't change from AppServer to AppServer) using relative paths etc. (e.g. ..\software for propath etc.).

I was hoping to take advantage of what it appears that Progress are attempting to do when they seem to automatically (almost) set an environment variable (but don't properly) to match the AppServer name, and detect that from the startup procedure (which then knows if it is a broker or an agent, and if it's a broker it knows what the agent name will be).

Sorry ... that probably just got even more complicated, however it does spell out exactly what I need and why I need it (IMO).

I hope that clarifies it sufficiently (clear as mud?!).

Cheers.

p.s. (for others reading this for the first time ...) the issue that I'm attempting to get around, or ask if anybody knows what it should be / should have been, is that the management console doesn't supply an environment variable name when creating a default environment variable for an AppServer that matches the name of the AppServer. Just the AppServer name appears, and I'm asking what the environment variable name would be if they were setting it correctly (for future when it is fixed; I can set it manually in the meantime). For example, it might be set to 'ClientABC_broker' instead of something valid like 'ASname=ClientABC_broker' ... my question is: what will the name be instead of 'ASname' ?
 

GregTomkins

Active Member
I don't quite get your emphasis on environment variables. Yes, I know what they are and I have a general idea of how they work; but I just never use them, ever, really.

Anyway, if you want to know the Progress name of the AppServer that a remote .P is running on, you could parse it out of SESSION:SERVER-CONNECTION_ID. Like this:

10.10.96.15::asbroker1::3090::0af23947d66d3862:772617:12476975a
58:-7f7a

I am sure the structure of this string is not guaranteed across versions etc. but it would probably work OK.
 

DownUnder

New Member
Greg,

Thanks once again for responding.

I was initially quite excited by the information that you provided, as it appeared that there was indeed a mechanism internal to the Progress environment that I could use to check the name of the AppServer that the program was running on. If that was the case then I would totally agree with you that there would be no need to use things like environment variable settings (I used them because I could find no other mechanism, other than manually setting a parameter for the startup procedure, and the advantage with environment variable was that management console was 1/2 the way to setting it up automatically for me).

Unfortunately, when I tested your method (using SESSION:SERVER-CONNECTION_ID) I found that this is only set once the AppServer process has started and is running a program via a connection, yet is blank when running the startup procedure that performs the initialisations. Unfortunately 2 out of the 3 places that I need to know which AppServer it's running are in the startup procedure phase (therefore not available).

Unless you and/or others have other ideas / resolutions (that work in both startup and connection mode) I'll try logging the issue with Progress support (as per TomBascom's question/suggestion) and see if they can provide further guidance. I'll do another post to supply information (in case anybody else faces a similar issue) if & when I receive further information and/or resolution.

Cheers.

p.s. I had read about this attribute (SESSION:SERVER-CONNECTION_ID) previously, yet nowhere in any of the documentation (or any other literature I've searched) did it mention that it contained information regarding the AppServer itself (which as you've pointed out it clearly does: the host IP + AppServer name), in addition to just being a unique ID as documented.
 
Top