Known issues in OpenEdge 13.1

In OpenEdge 13.1, an ICU database going through conv1213 is handled differently due to the removal of the old ICU libraries. After the conv1213 process completes, the database’s ICU collation must be changed using the new PROUTIL -C COLLATIONUPGRADE. Afterwards, a complete PROUTIL -C IDXBUILD is required to complete the collation change.

In OpenEdge 13.1 and higher, the PROUTIL -C LOBMOVE utility provides the ability to move the LOB field data of a table from one storage area to another storage area. To support this utility, the LOB locator field definition has been changed. The new version of the LOB locator is incompatible with pre-13.1 releases of OpenEdge.

To ensure the new version of the LOB locator is not used under a pre-13.1 installation of OpenEdge, the LOB Move feature bit, with ID 34, was added in OpenEdge 13.1. This feature is enabled by default for any OpenEdge database that is either opened or created in OpenEdge 13.1.

OpenEdge Release 13.0 as of Fri Jan 23 11:15:06 EST 2026
22:03:25 BROKER     The startup of this database requires 28Mb of shared memory.  Maximum segment size is 1024Mb.
22:03:25 BROKER  0: An invalid feature 34 has been encountered in the database's Enabled feature list. (11727)
22:03:25 BROKER  0: The list of enabled features in database progressdb contains features that are not recognized by this codebase (11810)
22:03:25 BROKER   : Removed shared memory with segment_id: 1146895 (16869)
22:03:25 BROKER     ** This process terminated with exit code 2. (8619)

Could not get length of source large object. (11312)

UpdateSharedIniFileData: Unable to WriteProfString to shared.ini file

A bug introduced in OpenEdge 12.3 caused ABL indeterminate arrays that are initialized with constant values to give an incorrect value for the EXTENT() function. This issue affected ABL programs that declare an indeterminate array variable using the EXTENT keyword without specifying a size and initialize it with a list of constant values (e.g., DEFINE VARIABLE myArr AS INTEGER EXTENT INITIAL [1, 2].), and this DEFINE comes after a statement that causes the execution of the EXTENT() function. In affected versions, the extent of such arrays was not correctly determined at compile time, resulting in incorrect runtime behavior.

This issue is resolved in 12.8.12 and 13.1. Recompilation is required for any ABL program that declares indeterminate arrays initialized with constant values. Programs that use determinate arrays (where the extent size is explicitly specified) do not require recompilation.

This fix introduces a minor r-code version change for ABL code that contains indeterminate LONGCHAR arrays where any element is initialized with the UNKNOWN value (?). R-code compiled with this fix cannot run on OpenEdge 13 releases earlier than 13.1, or on OpenEdge 12 releases earlier than 12.8.12.  

Java OpenClient uses Apache HttpClient 5, whose diagnostic logging is routed through the SLF4J logging API. SLF4J itself does not write log output; if you add an SLF4J-compatible logging provider to your Java classpath, that provider determines which messages are written and where.

Add only the JAR files required by your Java OpenClient application to the classpath. Adding all JARs under  $DLC/java/ext  through a wildcard or umbrella classpath entry can unintentionally load logging providers and unrelated dependencies.

If you use Logback ( logback-classic  and  logback-core ), place a logback.xml configuration file on the runtime classpath and set the desired logging levels. Without  logback.xml , Logback uses its built-in default configuration, which can enable DEBUG output for Apache HttpClient, including request/response headers and wire-level diagnostics.

<configuration>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>
  <logger name="org.apache.hc" level="WARN" />
  <root level="INFO">
    <appender-ref ref="CONSOLE" />
  </root>
</configuration>

Configure other SLF4J providers according to their provider documentation. Ensure that the runtime classpath contains one intended SLF4J provider.A

A new startup parameter -oscmdwin has been added for handling OS-COMMAND command strings containing quotes on Windows. This can help with the migration of Classic WebSpeed applications to PASOE Web Transport, and for moving application code from local clients into PASOE.

When a Browse has a join query where its temp-tables are members of a ProDataSet, and part of a Data-Relation in that ProDataSet, and a browse row is selected, we no longer automatically synchronize the hierarchy of queries for each temp-table buffer in the query.

When a Browse has a non-join query (i.e., single buffer), the buffer temp-table is a member of a ProDataSet, and a browse row is selected, we will only synchronize the query hierarchy of the temp-table buffer if the buffer's AUTO-SYNCHRONIZE attribute is set.

If your application was inadvertently depending upon this behavior you can revert back to old behavior by specifying the client startup parameter -browNewSync, or you can turn on a buffer's AUTO-SYNCHRONIZE attribute where appropriate.

Starting with OpenEdge 13.1, the root CA certificate associated with the generated PAS for OpenEdge development certificate is no longer installed automatically in the operating system trust store.

To deploy applications from Progress Developer Studio for OpenEdge or OpenEdge Management to a PAS for OpenEdge instance that uses this certificate, manually install the root CA certificate in the operating system trust store. For installation instructions, see PAS for OpenEdge dedicated certificate generation.

After installing the certificate, restart the AdminServer and Fathom services before deploying applications.

This release upgrades the bundled Apache Tomcat to version 11.0.24.

In this version, the HTTPS Connector attribute strictSni is enabled by default (true). When enabled, Tomcat enforces validation to ensure the TLS Server Name Indication (SNI) host matches the configured HTTP virtual host. Certain load balancer or proxy configurations may experience rejected HTTPS requests after upgrading.

To retain previous behavior, you may set strictSni="false" in the HTTPS Connector configuration. However, disabling this setting is not recommended, as the default configuration improves security.

Starting with OpenEdge 12.8.12 (and carried forward into 13.1), JWT authentication using the HS512 signing algorithm now enforces the HMAC-SHA512 minimum key length requirement: the signing secret must be at least 512 bits (64 bytes) long.

Previously, OpenEdge did not enforce this minimum, so shorter secrets that had been working on earlier releases (e.g. 12.8.6) would authenticate successfully. After upgrading, JWT authentication attempts using a secret shorter than 64 bytes now fail with an error indicating the secret length for HS512 must be at least 512 bits.

This is an intentional security hardening change, not a defect. Administrators who use JWT authentication with HS512 must ensure their signing secret is at least 64 bytes (512 bits) long after upgrading.

See KB article: https://community.progress.com/s/article/can-t-authenticate-using-jwt-after-upgrading-to-12-8-12

Starting in OpenEdge 13.1, the PASOE OEManager REST API for retrieving an ABL session's stack trace (GET /oemanager/applications/<app-name>/agents/<agent-id>/sessions/<session-id>/stacks) returns different information than in 12.8.x.

Previously, the response included additional session metadata -- BrokerSessionId, StartupParams, Propath, Databases, PersProcs, and OO4GLObjs -- regardless of whether the session had an active call stack.

Starting in 13.1, the response includes only the call stack (Callstack) when the session is actively executing a request. The additional session metadata fields listed above are no longer returned.

Progress Developer Studio for OpenEdge 13.1 supports Eclipse versions *4.38*, *4.39*, and *4.40*. Other Eclipse versions are not supported and may result in unexpected behavior.

OpenEdge 13.1 introduces support for Java 21, which uses UTF-8 as the default JVM character encoding. SQL JDBC applications, including OpenEdge SQL Explorer (sqlexp), that rely on the JVM default encoding may experience character conversion issues when working with legacy or non-UTF-8 data. This could result in incorrect character display, data conversion errors, or messages such as "Transliteration failed".

-Dfile.encoding=<encoding_used>

-Dfile.encoding=windows-1252

For more details, please refer Oracle JDK Migration Guide.