New Appserver and propath for OS Shell

Thanks for the info. The "expected behaviour" seems explainable but it's not what I would have expected.

I guess expected is very subjective.

My initial attempts to use PASOE failed on environment variables, this "expected behaviour" may explain why they did.

bug.

Interestingly tech support have now closed this call and don't share the view that it is a bug. Should I suggest they reconsider this in the light of the Gus comment?

Traditionally, if the code shell out of the Progress session, it shares the environment of the AVM. If that is no longer the same, migration to PASOE will introduce errors without any change to the ABL source, which is unexpected.

Older source will always work on newer versions (given the possible need to use a keyword forget list), in part so enable us to keep our customers up to date with the latest technology.

Now we have a situation where running a) the same source code on b) the same OS in c) the same OpenEdge version, but using a different AVM, results in different behaviour. To make it worse, the described "workaround" is not universal, but unique the the particular AVM and requires run time access to files and folders that are not regularly in the PROPATH either.

If that does not constitute a bug, what does?

We provided a new architecture that allows a single Progress Application Server support multiple independent ABL applications with their own PROPATH. Yes, we did not foresee customers would be shelling out to batch processes, so we did not inform customers that this is a change in behavior. We also are taking advantage of this architecture to deliver some major new products in 11.7, and I am sure we have customers who do want the ability to have multiple, independent ABL applications running on a single AppServer, so we think that this is a small price to pay given the functionality it provides.

Now, given our current approach of using a *_setenv.sh/bat file to set the environment will set the same environment for all ABL applications, we will take a look at what we could do to provide this functionality at a more granular level. Until then, create a file such as foo_setenv.sh that lives in $CATALINA_BASE/bin that does a PROPATH="...";export PROPATH and your code will run as-is.

Dave

Just to be clear, we do share the environment of the AVM when we shell out. It is just up to you to set the PROPATH environment variable should you need it, and ensure it is in sync with changes you make in OpenEdge.properties.

Dave

Thanks for the update David. Would it not be possible for the PROPATH to be set automatically when  we shell out as it is known at the point the UNIX statement is executed as it is in the PROPATH variable.

What if  multiple ABL Applications are deployed in the instance. Lets say you have deployed ABL Applications  - App1 & App2. The PROPATH for both of them would be different

What I would do is to add a file "propath_setenv.sh" in <instance-location/conf directory and then add the below lines

App1_PROPATH=`$CATALINA_BASE/bin/oeprop.sh AppServer.Agent.App1.PROPATH`; export App1_PROPATH

App2_PROPATH=`$CATALINA_BASE/bin/oeprop.sh AppServer.Agent.App2.PROPATH`; export App2_PROPATH

Once you restart your instance, you should be able to get these are environment variables

The  PASOE instance supports multiple ABL Applications, but PASOE starts one (or more) _mproapsv process for each ABL Application. This process is the AVM and the PROPATH belongs to it. When you shell out of it, you expect to have the same environment as you would have when you shell out of a traditional AppServer. When you shell out of an _mproapsv process of another ABL Application on the same PASOE instance, you expect to have the same environment as you would have had if you shelled out of a traditional AppServer serving that application.

Setting PROPATH in *_serenv.sh is too soon. That set the environment for the Java process that parents the _mproapsv processes, so they will share the SAME value, which is wrong. When we shell out, _mproapsv is the parent process. We inherit the environment of the direct parent and need the environment to be as tailored for this process, rather than variables inherited indirectly from the grand parent process.

By moving PROPATH to openedge.properties, the propath is no longer set in the environment, but rather in the "registry", as we've done with prowin32 for ages. Normally, if you run MESSAGE OS-GETENV("PROPATH") in Windows, you get an unknown value. The same is now true for PASOE.

In DOS and UNIX we have to set PROPATH, in Windows (and possibly PASOE?) that works for compatibility reasons, but it is not required (or desired) that it be done.

That being said, shelling out of Windows force once to jump through hoops when PROPATH is needed in the shell.

I guess I've just convinced myself that this is not a bug, but a natural progression beyond shell variables. I am sure that ChuiMonster would LOVE this move closer to Windows. ;-)

It would be quite nice if OS-COMMAND / DOS / UNIX / INPUT THROUGH could populate the PROPATH environment variable, if it is undefined, before spawning the shell.

I would therefor suggest two things:

a) That PSC add pertinent note in the PASOE migration and reference documentation to note that the PROPATH environment variable is now redundant and not desired.

b) That anybody who feels the need to propagate this value to the shell create an enhancement request.

Hi Peter,

For various other reasons beyond the original reason for this thread, in my case mainly from a tooling perspective, I do believe that OS-SETENV() would be a welcome enhancement.

For various other reasons beyond the original reason for this thread, in my case mainly from a tooling perspective, I do believe that OS-SETENV() would be a welcome enhancement.

The original poster can then fix his problem by using that in the startup procedure of the AppServer, e.g.

OS-SETENV('PROPATH',PROPATH).

Being able to read the "newer" environment configurations, like oe.props, this way, is also an attractive idea. While we do have a way to get to registry settings, the current mechanism is a bit awkward, in that you cannot assign a value directly to a variable, so improving that access at the same time might be nice. Consider the difference in the following:

ASSIGN
cMe = OS-GETENV("USERNAME")
cHost = OS-GETENV("COMPUTERNAME")
cLogfile = ParseProps("Appserver.SessMgr.MyApp:agentLogFile")
.

GET-KEY-VALUE SECTION "Startup" KEY "PROPATH" VALUE cValue.
LOAD "Acme Inc.\AcmeApp".
USE "Acme Inc.\AcmeApp".
GET-KEY-VALUE SECTION "AppStylistService" KEY "StyleLibrary" VALUE cPref.
USE "PSC\" + PROVERSION(0).

METHOD PRIVATE CHARACTER ParseProps(pcProperty AS CHARACTER) :
...

As opposed to:

ASSIGN
  cMe      = OS-GETENV("USERNAME")
  cHost    = OS-GETENV("COMPUTERNAME", "ENV")
  cPath    = OS-GETENV("Startup:PROPATH", "REG")
  cPref    = OS-GETENV("Acme Inc.:AcmeApp:AppStylistService:StyleLibrary", "REG")
  cLogFile = OS-GETENV("Appserver.SessMgr.MyApp:agentLogFile", "PROP")
  .

or even:

ASSIGN
  cMe      = OS-GETENV("USERNAME")
  cHost    = OS-GETENV("ENV:COMPUTERNAME")
  cPath    = OS-GETENV("REG:Startup:PROPATH")
  cPref    = OS-GETENV("REG:Acme Inc.:AcmeApp:AppStylistService:StypeLibrary")
  cLogFile = OS-GETENV("PROP:Appserver.SessMgr.MyApp:agentLogFile")
  .

I do however believe that these methods of getting to (and setting) the environment are going beyond the pure OS environment, and it might be more appropriate to introduce "GETENV()" and "SETENV()" for this purpose, while re-mapping OS-GETENV(&1) internally to GETENV("ENV:" + &1)...

Just to remind people again of the simple solution that would work is for OpenEdge to set the PROPATH automatically when an OS-COMMAND/UNIX/DOS shell is run. As the OpenEdge .exe is running at that point for a single PROPATH it is just a case of setting the environment PROPATH on the shell.

In the short term we will use UNIX(VALUE("PROPATH=" + PROPATH + "; mbpro package -p login.p")