equalize the behavior between ?transfer to transaction? and ?transfer to program? statement

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - Business Developer

For recording keeping, the previous attributes were:
Brand - Rational
Product family - Design & development
Product - Business Developer

This request is being rejected because it is not consistent with the EGL language.

As documented in the original PMR, the customer is using an undocumented method to instantiate the EGL rununit using native Java class (wrapper in their example). When they instantiate the rununit, they supply a properties file name which becomes the "program.properties" (this is userBB.properties in their requirement and note this is NOT the name of the program..but an arbitrary name). When EGL does a transfer to program, it is starting a new program within the same rununit, so the properties are not re-read and it uses the ones established when the rununit started. Transfer to Transaction in EGL means the current rununit shuts down and a new rununit is started. Since this is being done EGL to EGL, there is not a native Java class instantiating the rununit to provide a "special properties file" so the normal properties search rules apply (user.properties in user.home, program.properties (name of program), and rununit.properties. This is why userBB.properties is not used on the "transfer to Transaction" since it does not match the program name.

If unique properties need to be defined per user or per application, then this can be done by setting a unique user.home before the EGL generated programs are run. In this user.home, there can be a file named user.properties. The user.home can be set dynamically in the "invoker" class instead of setting the properties file name. Here is an example:

// set up new user.home to current working directory + \\bin
// user.dir not correct in deployed app..need to find some other way. ...but concept is the same.
Properties p = new Properties(System.getProperties());

String userdir = p.getProperty("user.dir") + "\\bin";
System.out.println("userdir = " + userdir);
p.setProperty("user.home", userdir);


// set the system properties
System.setProperties(p);
System.getProperties().list(System.out);

As noted in the comments, this code looks up the user.dir which is the workspace/project location. The compiled classes are in the \bin directory so running in the workbench (run as -> Java application) the user.properties file needs to be in \\bin. This is not the same working directory when running deployed..but some similar algorithm can be used to identify a location for the user.properties. Most likely the directory needs to be unique per user.

This RFE's Headline was changed after submission to reflect the headline of an internal request we were already considering, but will now track here.