New Appserver and propath for OS Shell

Posted by carl.williams on 26-Feb-2016 03:54

Just so people are aware if they move to the new Appserver and shell out to Linux to run start say a batch progress task (mbpro) then the PROPATH environment is no longer setup in the Linux environment.

Tech support say this is the expected behaviour and offer this possible work around below but instead we will be changing our application to pass the PROPATH to a script which will then run mbpro having setup the propath.

"The PROPATH variable isn’t set in the environment because the PASOE does not use it. The reason for this is that a single PASOE instance can support multiple ABL applications with their own session manager and PROPATH.

That said, you can get the PROPATH via the "oeprop" command. Execute the below command on oepas1 instance: <instance-location>/bin/ Appserver.Agent.oepas1.PROPATH, it should dump the PROPATH value.

In your case, as the instance needs to find the ABL application on startup, you can create a *_setenv.bat/sh script that gets executed at startup. In this script you can set the PROPATH or you can call oeprop to extract the PROPATH value from and add it to the environment."

All Replies

Posted by cverbiest on 26-Feb-2016 08:30

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.

Posted by gus on 26-Feb-2016 08:56


Posted by carl.williams on 29-Feb-2016 02:29

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?

Posted by Simon L. Prinsloo on 29-Feb-2016 03:47

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?

Posted by David Cleary on 29-Feb-2016 10:35

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 * 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 that lives in $CATALINA_BASE/bin that does a PROPATH="...";export PROPATH and your code will run as-is.


Posted by David Cleary on 29-Feb-2016 10:37

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


Posted by carl.williams on 29-Feb-2016 10:50

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.

Posted by Irfan on 29-Feb-2016 11:45

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 "" in <instance-location/conf directory and then add the below lines

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

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

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

Posted by Simon L. Prinsloo on 29-Feb-2016 12:42

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 * 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, 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.

Posted by Peter Judge on 29-Feb-2016 12:52

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.

Would something like a OS-SETENV() be enough? So your ABL would OS-SETENV('PROPATH') and then OS-COMMAND('prowin -b ...' ).
We've also talked about OS-GETENV() being able to read values in the oe.props file. Would that be helpful in this respect?
Posted by Simon L. Prinsloo on 29-Feb-2016 22:14

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.


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:

cLogfile = ParseProps("Appserver.SessMgr.MyApp:agentLogFile")

LOAD "Acme Inc.\AcmeApp".
USE "Acme Inc.\AcmeApp".
GET-KEY-VALUE SECTION "AppStylistService" KEY "StyleLibrary" VALUE cPref.


As opposed to:

  cMe      = OS-GETENV("USERNAME")
  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:

  cMe      = OS-GETENV("USERNAME")
  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)...

Posted by carl.williams on 01-Mar-2016 02:51

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")

This thread is closed