Known issues in OpenEdge 12.8.7

The .NET Open Client StrictHostVerify property on both the RuntimeProperties and Connection classes has been marked as Obsolete. This property and its associated behavior are ignored and do not affect the HTTP host name validation performed by .NET Open Client. The hostname validation for .NET Open Client HTTPS connections relies on the underlying .NET implementation for its behavior.

In past releases on Linux, the name of an OOABL class name had to match exactly to the on disk class name the first time a class was encountered during an ABL session. After the first reference, the AVM would cache the class name and r-code information. Any reference to the class name after the first would accept be use any capitalization as the cache lookup was performed case-insensitive. This bug primarily impacts Linux where the file systems default to being case sensitive. On Windows, this is less of a problem because the file system is case-insensitive by default. This resulted in inconsistent behavior at both compile time and runtime behavior. Depending on the order the class name was encountered, a compilation or class load may or may not compile if inconsistent capitalization is used.

This bug has been addressed and now class names must always be cased correctly in all situations, including compile time and dynamically at runtime. Runtime changes directly impact statements such as DYNAMIC-NEW, DYNAMIC-CAST, GET-CLASS(), etc.. A startup parameter is introduced that controls this behavior: “-casesensitiveclasses [1|0]”. For OpenEdge 13.0, the new behavior defaults to enabled (1) on Linux, and disabled on Windows (0). You may revert to the old behavior using “-casesensitiveclasses 0”. For OpenEdge 12.8, the new behavior defaults to disabled (0) on both Windows and Linux.

The behavior change and startup parameter affect references to user defined class names, including the names of Interface, Enum, ABL classes, and all .NET class names. Built-in class names, i.e. those appearing in the “Progress” internal package, are not affected and may continue to use any capitalization for first or secondary references. Note also that the class’s own name used within the CLASS statement must match the exact capitalization of the on disk file name. Names of properties, methods, variables, etc. are not affected. The capitalization of constructors and destructors is not affected as these are considered methods.

With this change, you may need to correct class references in ABL code to compile your application. You may also need to review and test any class names used to dynamically load classes such as with applications that use reflection related language features.

When an ABL socket client/ABL HTTP Client connects to a server that has client authentication required (set on the server) using the TLSv1.3 protocol, and the client does not provide client authentication credentials, the connection may appear successful during the initial handshake. However, it will subsequently drop the connection with an error indicating a connection is dropped.

How to avoid the issue for different clients is below:

1. For ABL Socket client, while providing correct client credentials set -sslAuth ssl in the connection string.
2. For ABL HTTP Client, provide correct client credentials using OpenEdge.Net.ServerConnection.TlsClientCredentials class properties.

Progress Developer Studio for OpenEdge (PDSOE) provides the "Report Technical Issue" feature that enables customers to directly log a support case. This feature depends on a service hosted on a Progress server accessible through the web. Progress has determined that this feature is rarely used. So, it opted to retire the hosted service and remove the "Report Technical Issue" feature from the Developer Studio.

Customers can contact Technical Support through the SupportLink portal or by phone. To get the list of phone numbers by region, browse to the Welcome to SupportLink page and click “Call Support". Then, click the “Call Support” button for OpenEdge.

Starting with OpenEdge 12.5, Progress Developer Studio for OpenEdge (PDSOE) introduced a new tooling model to analyze and gather information about entities within a project or PROPATH and their dependencies using an upfront data collection approach. However, this model made the initialization process resource-intensive and time-consuming, and negatively impacted the developer productivity. To address these performance issues, the tooling model has been reverted to its previous state, aligning it with PDSOE in the OpenEdge 12.4 version.

As a result, the following features will no longer be available in PDSOE from OpenEdge 12.8.7 onwards:

• Intelligent compilation
• Type Hierarchy