FWD » Core Development » Base Language

Currently the code always returns "Full", but this is probably not a great idea. It means that COMPILE will work, which is not correct. We probably should return "Run-time" by default and allow a directory override to something else in case the application requires it.

I don't see a reason at this time for us to report "Query", "COMPILE" or "COMPILE-ENCRYPT" which are the other documented possibilities. None of these have any natural meaning in FWD.

As part of this task, the gap marking would be set to full-restricted with a note explaining the limitation ("we hard code the default to 'Run-time' but allow any other value to be specified as a directory override").

I would like to ask for some help. Directory override means changing the working directory on runtime or does it mean creating a directory when the directory already exists? I tried searching the internet about how to change the working directory without success (https://docs.progress.com/bundle/abl-reference/page/Working-directory.html).

No, this is a reference to the directory.xml used as the configuration source for the FWD application server.

Can you please elaborate more?

message progress.

which prints "FULL" in both, FWD and OE.

In FWD, the following code is generated:

message(EnvironmentOps.getRuntimeType());

/**
 * Gets the current runtime type being provided by the Progress
 * compatible environment.  The P2J environment only provides a
 * "Full" environment.
 *
 * @return   Always returns the string "Full".
 */
public static character getRuntimeType()
{
   return new character("Full");
}

which indeed, returns the hard-coded "Full". In the documentation it says that FULL means that the program is executed by a full editor. I get "Full" when I execute the above program using the Developer studio or the proenv on the VM.

As it is stated in this task, I hardcoded it to return "Run-time".

I have some questions about the second part. Should I set a node in directory.xml like this?

<node class="string" name="progress">
   <node-attribute name="value" value="Run-time"/>
</node>

If yes, under which "path"?

Should the client be able to send a new value (to override it)? If yes, do I need to implement this functionality or does it already exist?

kind reminder

Theodoros, I think the path should be runtime/{default|<server ID} - look how widget-descriptors are loaded in WidgetDescriptorHelper.loadFromDirectory, as this node resides under the same path.

As for the name: I would suggest having something like this:

   <node class="container" name="legacy-variables">
      <node class="string" name="progress">
         <node-attribute name="value" value="Run-time"/>
      </node>
   </node>

Did you create a branch for the changes?

Yes, the branch is 4382a. Should I mention it here when I create a branch?

Greg, FWD trunk has a commit for #4382:

------------------------------------------------------------
revno: 14496
committer: Theodoros Theodorou <tt@goldencode.com>
branch nick: trunk
timestamp: Tue 2023-03-07 00:54:35 +0200
message:
  Implemented configurable directory override for the PROGRESS global variable (refs #4382)

Theodoros: you need to follow the change management process; save the change in FWD trunk and add it to a 4382a branch. For creating a branch, please see Create a new branch.

Oh, my bad. I created the branch 4382a and my intention was to push the changes there, not in the trunk. The changes are just a few lines in EnvironmentOps.java. We may do not need to revert if the changes are ok.

I just uncommitted the change from trunk.

We will go through our normal review and testing process.

Theodoros Theodorou wrote:

Oh, my bad. I created the branch 4382a and my intention was to push the changes there, not in the trunk. The changes are just a few lines in EnvironmentOps.java. We may do not need to revert if the changes are ok.

Please commit the change to 4382a so it can be reviewed.

I have recreated the branch 4382a and pushed the changes there

• the path being used is legacy-system/progress. Greg, I think we need a legacy-variables/progress, as this is not related to the legacy system.
• the lookup is done using DirScope.ACCOUNTS - we need to use DirScope.SERVER, as this is not something related to a specific user, is related to how the code was compiled, and it affects the entire code.
• please update the Copyright year in the header, and also add the history number, like ** 056 TT 20230307

the path being used is legacy-system/progress. Greg, I think we need a legacy-variables/progress, as this is not related to the legacy system

I think it is better to leave it as legacy-system/progress. It is a kind of value abotu the legacy system, because it reports the type of OE install on that legacy system. I prefer not to introduce an entire section for this.

Greg Shah wrote:

the path being used is legacy-system/progress. Greg, I think we need a legacy-variables/progress, as this is not related to the legacy system

I think it is better to leave it as legacy-system/progress. It is a kind of value abotu the legacy system, because it reports the type of OE install on that legacy system. I prefer not to introduce an entire section for this.

OK, then the lookup needs to remain as is, DirScope.ACCOUNTS.

Theodoros: the only issue remaining for the review is the Copyright and history number.

Done

4382a has been rebased to trunk 14509

4382a was merged to trunk as revision 14510. It was archived.