FWD » Core Development » Base Language

It is common for 4GL code to search for 4GL external procedure names before executing those programs. Such searches use SEARCH() which maps to FileSystemOps.searchPath(String) in P2J. Since the PROPATH can be assigned in the 4GL, the use of SEARCH() honors such changes and the results of the call can change at runtime.

Our searchPath() does also honor the propath, including any assigned changes. But since the 4GL code is not actually existing in the file system on the client, we cannot find such resources using the standard search algorithm. So what we have done is to first query the SourceNameMapper to see if it knows about the name as an external procedure. That code is also propath aware and it can have its results change at runtime based on this.

The only problem is that today, is SourceNameMapper.convertName() returns a non-null value (meaning it found a match), we return that value which is the Java class name that matches the original 4GL program that was being searched for. This breaks the contract with the original 4GL code, which is certainly expecting a return value that corresponds to the following:

• It is a 4GL external procedure name, usually (but not always) ending in a .p or .w and possibly including characters that are invalid in a Java package and class name (e.g. hyphens).
• The name is fully qualified with a client filesystem absolute path.

We need to fix FileSystemOps.searchPath(String) to return the 4GL procedure name for external procedures found via SourceNameMapper. This will have to be turned into a absolute path, which is tricky because no such path actually exists. We may have to either:

• Have a pre-configured application-specific 4gl-src-root that we treat like our pkgroot (as a fixed prefix on all application package + class names).
• Use the client filesystem's current directory (or other queryable value) to calculate a 4gl-src-root.

Or perhaps we do both of these things (use a 4gl-src-root if is configured, otherwise calculate one).

As part of this task, please also review how absolute paths are handled by SourceNameMapper. Make sure there are no inconsistencies or problems in the implementation. The intention has always been to be tolerant of absolute paths coded into the 4GL while actually eliminating them in the converted system. The way we did this was by allowing flexible matches based on the propath. I'm not 100% sure our approach is correct, so it needs some consideration.

From Ovidiu:

Related to searchPath() of #2489. While the system was busy I checked this method and related ones from SourceNameMapper & FileSystemOps. I could not identify a flow in the logic. The behaviour described in 2489 is exact the reason why the 13/14 SwipeCardExtractTest tests ere failing in #3072. Do you know a specific testcase that fails, or at least was failing before the merge of 2475c?

Code Review Task Branch 2489a Revision 11022

The code is good.

One thing I'd prefer is to implement convenience workers in SourceNameMapper to hide the two different use cases:

public String convertNameToClass(String legacy)
{
   String[] paths = convertName(legacy);
   return (paths != null) ? paths[0] : null;
}

public String lookupAbsoluteLegacyName(String legacy)
{
   String[] paths = convertName(legacy);
   return (paths != null) ? paths[1] : null;
}

Task branch 2489a was rebased to trunk 11037. The changes from note 7 were applied. The current revision is 11040.
I am going to regression test it on devsrv01.

Code Review Task Branch 2489a Revision 11040

Overall, this is very good. Please rebase. Also apply these minor changes:

1. On more reflection, I think SourceNameMapper.lookupAbsoluteLegacyName() should be named SourceNameMapper.lookupLegacyName() since it can match relative names as well as absolute names. The lookupAbsoluteLegacyName() suggests that we are passing in an absolute name, which is not always correct.

2. The return javadoc for lookupAbsoluteLegacyName() is incorrect.

3. In FileSystemOps.searchPath(), there is this comment/code:

      // if the Progress code was checking for the availability of an external procedure, we have
      // to "fake" it out into thinking that this still exists, try a converted class name lookup
      // first (but returning its legacy name)

      String cls = SourceNameMapper.lookupAbsoluteLegacyName(filename);
      if (cls != null)
      {
         // this is a program name, return the Java class name instead
         return new character(cls);
      }

In this case both comments seem misleading. We aren't looking up the class name anymore. But we are saying that try a converted class name lookup first and return the Java class name instead which are not accurate.

Since a class is not being returned, the cls variable name is no longer descriptive.

Please change it like this:

      // if the Progress code was checking for the availability of an external procedure, we have
      // to "fake" it out into thinking that this still exists, try to match this given filename
      // with a known program name, optionally honoring any absolute prefix passed in

      String legacy = SourceNameMapper.lookupAbsoluteLegacyName(filename);
      if (legacy != null)
      {
         // this is a legacy program name, return it instead of searching on the client side
         return new character(legacy);
      }

From Ovidiu:

Task branch 2489a was rebased to latest trunk. After update, the current revision is 11048.

Code Review Task Branch 2489a Revision 11048

I'm fine with the changes. Please runtime regression test them.

This is normal, since now the searchPath() returned the legacy procedure name, as documented in the task. The reference must be updated.

I ran manually the rest of the test and gc_tests/gc_66 and they are matched the reference (gc_66 failed because the screen got out of sync in gc_65).

In conclusion, the update passed the regression testing on devsrv01.

Please make the required updates to the baselines to match the new text, test the result to confirm that these changes will allow these tests to pass.

Then you can merge 2489a to trunk. Make sure to check in the baseline changes at the same time. In the notification email, explain to people how they must pull down the baseline updates.