Patch P219 for version 9.3.02 has been withdrawn (Updated)

Patch P219 contains a solution for problem 29010 that has introduced an incompatibility with earlier patches of version 9.3.02. After carefully considering the impact that the incompatibility of patch P219 is causing, and the fact that the solution also has introduced a side-effect that may cause Uniface to loop/hang in odd cases, the Uniface Lab has decided to withdraw patch P219.

*** Important: the fix for problem 29138 (‘Re-fix’ of 28617) could not be provided with P220. Instead the fix of problem 28617 has been ‘undone’ in the mentioned patch (see problem 29164) . For more information see the article Patch P220 released – Update on 29010/28617 ***

 

 

Technical explanation

Patch P219 contains a solution for problem 29010 (“Performance drop when executing global Procs in 9.3.02”) that has introduced an incompatibility with earlier patches of version 9.3.02 – for an explanation see the alert “Potential runtime incompatibility after installing patch P219 for version 9.3.02” of March 8, 2011.

After carefully considering the impact that the incompatibility of patch P219 is causing, and the fact that the solution also has introduced a side-effect that may cause Uniface to loop/hang in odd cases, the Uniface Lab has decided to withdraw patch P219.

The mentioned patch will not be re-released. We will provide a solution with the patch P220 that will undo the solution for problem 29010 (and the introduced incompatibility). The root cause for the performance problem described in 29010 is a solution for problem 28617 in patch P211, “Crash when using global variables after changing the library”. The fix for bug 28617 will be redone in patch P220. This new solution (see problem 29138) replaces the existing solutions for 28617 and 29010 and makes these solutions redundant.

 

A bit of background for problem 28617:

  • Since version 9.1 it’s possible to call a module (global proc function) in a different library than the library bound to the component (defined declaratively in the Component properties).

Example: THISFORM is bound to THISLIB, and in one of the triggers of THISFORM a call to a module in OTHERLIB is made in the form of:

call OTHERLIB:MODULE(param1, param2, …), or
$1 = OTHERLIB:MODULE(param1, param2, …)

  • If the proc in OTHERLIB:MODULE uses a Global variable, Uniface tries to locate that variable in THISLIB. If the variable is not defined in THISLIB, Uniface crashes.

As stated above, we now plan to redo the solution for problem 28617 (in the context of problem 29138) in a different way, which will make the solution for 29010 redundant. Currently (since the version 9.3.02 patch P211, and additionally the version 9.2.03 patch O312 and version 9.4.01 patch R102) the data-scope of a global module is similar to the data-scope of the component calling that module, including the library referred to in the component. We will change the global module’s data scope to the library’s data scope. Effectively, this means that a global variable called from OTHERLIB:MODULE must exist in the library OTHERLIB.

Theoretically, this may cause an incompatibility:

 

  • If $OTHERLIB:MODULE uses a global variable that exists in THISLIB, this variable will be found in 9.3.02/P211 and higher.
  • After the proposed fix, a global variable will only be looked for in the same library as the module’s library.

The Uniface Lab anticipates that the use of calling other libraries’ modules, which in turn use global variables, is not widespread, and the solution 29138 (new solution for problem 28617) introduces consistent behavior.

What does this mean for you?

  1. If you are not using the version 9.3.02 patch P219, this issue will have the least impact for you. You can simply upgrade from an earlier version 9.3.02 patch level straight to patch P220 – the performance problem introduced with the original solution for problem 28617 will be resolved by the  solution for problem 29138
  2. If you are using the patch P219, you will be required to recompile all global objects after you’ve installed P220. Not doing so may cause Uniface to crash when trying to execute/access global objects that were compiled with P219. Note that as of P220, the compiled global libraries are backward compatible again with patches prior to P219.
  3. If you are using version 9.4.01, the performance problem introduced with patch R102 will be addressed in patch R111 (scheduled release date April 1)
  4. If you are using the version 9.2.03 patch O312 (or higher) and would like to benefit from the performance improvement of the fix for problem 29138, please upgrade to either Uniface 9.3.02 patch P220 or Uniface 9.4.01 patch R111. Compuware will not provide any solution for Uniface 9.2, as this particular release has not been supported since December 2010 (for more information see Uniface Support Lifecycle).

 

Leave a Reply