Known issues in OpenEdge 12.4

Generally, Progress Developer Studio for OpenEdge (PDSOE) automatically updates the spring security files for Web and Rest projects that were created in previous releases. You can also update the security files by right-clicking a Web or Rest project and then selecting Progress OpenEdge > Migrate Spring Security Files from the context menu.

However in OpenEdge 12.4, Developer Studio does not automatically update the spring security files for OpenEdge 12.3 projects. Also, the context menu option does not work for these projects. So, the latest changes in the spring security files are not included in the projects.

To update the spring security files in an OpenEdge 12.3 project, create a new Web or Rest project in Developer Studio. Then, copy the changes from the new spring security files and incorporate them in corresponding files of the OpenEdge 12.3 project.

A new AllowServerDisconnect property was added to the OpenEdge.Net.ServerConnection.ClientSocketConnectionParameters to allow developers to specify whether a remote server disconnecting should be considered an error or not.

Certain HTTP servers will not return any content negotiation headers such as Content-Length or Transfer-Encoding, and will instead terminate the connection to the client to indicate that the response has been completely sent.

The existing behaviour assumes that a server disconnect is an error. In order to allow server disconnects,  set the value of the AllowServerDisconnect property to TRUE. The default value is FALSE to maintain existing behaviour.

The flag is set in ABL in the following way:
<abl>
block-level on error undo, throw.

using OpenEdge.Net.HTTP.*.
using OpenEdge.Net.HTTP.Lib.*.
using OpenEdge.Net.ServerConnection.*.

define variable cscp as ClientSocketConnectionParameters no-undo.
define variable req as IHttpRequest no-undo.
define variable resp as IHttpResponse no-undo.
define variable hc as IHttpClient no-undo.

cscp =  new ClientSocketConnectionParameters().
cscp:AllowServerDisconnect = true.

hc = ClientBuilder:Build()
        :UsingLibrary(ClientLibraryBuilder:Build()
                            // add params to the client
                            :Option(get-class(ClientSocketConnectionParameters):TypeName, cscp)
                            :Library)
        :Client.

// things should work ok now
req = RequestBuilder:Post('https://localhost:8810/web/resource')
                    :Request.

resp = hc:Execute(req).
</abl>      

PCT version 218 is shipped with OpenEdge 12.4. But, the PCTLoadData task fails in this PCT version. The issue will be addressed in the next PCT release. It will be available in [https://github.com/Riverside-Software/pct/releases|https://github.com/Riverside-Software/pct/releases].

As of OpenEdge version 12.4, RCODE-INFO attributes TABLE-LIST, TABLE-CRC-LIST, and DB-REFERENCES return an empty string (“”) when ABL source files, which do not contain table references, are compiled.   This behavior change is aligned with the existing documentation.  Previously these RCODE-INFO attributes returned (“ “) instead of an empty string.

The fix for OCTA-8410 caused a change in behavior in the AVM when validating XML and JSON Date, Datetime, and Datetime-TZ types.  The empty string, e.g. <myDate></myDate>,  no longer maps to the unknown value for the type.  Instead error 20015 is issued for JSON and 20237 for XML.

20015: "JSON string %s<string> is not a valid ISO-DATE"
20237: "XML string %s<string> is not a valid ISO-DATE"

When using the -assemblies startup parameter in OpenEdge 12.4 or later, OpenEdge will now verify that there is an assemblies.xml file in the specified directory.  Previously, this was never checked when used with a PASOE server, and for a client it was only checked if -preloadCLR was also used.

Several messages that were previously marked as warnings have been changed to errors.  So if you use SESSION:SUPPRESS-WARNINGS, they will no longer be suppressed.  These messages are:

**Attribute <attribute-name> for the <handle id> has an invalid value of UNKNOWN. (4056)        
**Attribute <attribute-name> for the <handle id> has an invalid value of <integer>.  (4057)  
**Attribute <attribute-name> for the <handle id> has an invalid value of <string>.  (4058)
**Attribute <attribute-name> for the <handle id> has an invalid value of <logical>.  (4059)  
**Attribute <attribute-name> for the <handle id> has an invalid value.  (4060)                  
**Attribute  for the <handle  id> has an invalid value.  (4061)
**Attribute <attribute-name> for the <handle id> was passed an invalid <handle id>.  (4062)
**The <attribute-name> attribute on the  <handle  id> has invalid arguments. (4065)
**Attribute <attribute-name> must be greater than or equal to 1 on <handle id>.  (4081)        
**Attribute <attribute-name> must be greater than or equal to 0 on <handle id>.  (4082)
**Unable to assign UNKNOWN value to attribute <attribute-name> on <handle  id>.  (4083)
**Attribute <attribute-name> must be greater than zero on <handle  id>.   (4084)    
**Attribute <attribute-name> cannot be set to  an empty string on <handle id>. (4085)

Previously, the warning status of these messages prevented them from being properly handled by structured error handling (e.g., prevented them from being caught or thrown).  That is now no longer the case.

In versions prior to 12.4.0, .NET OpenClient does not always return a datetime-tz with the correct UTC offset from the OpenEdge AppServer. This bug was due to the use of TimeZone class in .NET framework (a  C# base class), this class has been deprecated by Microsoft and it was replaced with TimeZoneInfo in both .NET Core and .NET Framework. .NET Open Client replaced the use of TimeZone with TimeZoneInfo. The issue could not be reproduced in .NET Core, so moving an application that uses .NET Open Client from .NET Framework to .NET Core may show a difference in the UTC offsets of datetime-tz values.

For more information you can read about TimeZone here: https://docs.microsoft.com/en-us/dotnet/api/system.timezone?view=netcore-3.1

Proxygen makes use of the classpath value stored in the .xpxg file when compiling a generated proxy library. If you are using bproxgen with an existing .xpxg file and compilation of the java classes fails, ensure that progress.jar does not appear in the classpath stored in the .xpxg file. The error messages from the log file generated by bproxygen will indicate the Connection object is not compatible with the use of try with resources syntax. To correct the compilation failure, replace any references in the .xpxg file to progress.jar with o4glrt.jar.

Java 9 deprecated the use of a finalize() method with the understanding that java developers would improve their code to reduce the reliance on the garbage collector to cleanup system resources such as network connections and open file handles. Some classes in java open client have been modified to follow the current best practices.  The com.progress.open4gl.javaproxy.Connection class now implements AutoClosable. The code generated by proxygen for java open client proxies takes advantage of this change and uses try-with-resources style syntax to instantiate Connection objects when needed. This change ensures that any system resources created by the Connection objects are released in a timely manner without relying on the garbage collector to call finalize(). The change in the generated code relies on the Connection class implementing AutoClosable. Ensure that when deploying generated libraries, an up-to-date version of open client library is used.

As of OpenEdge version 12.4, the AVM will no longer ignore errors that occur when evaluating a query expression.   Previously, if an error occurred, the value of the expression was set to the Unknown value, and the query continued to execute.  This would affect all statements that involve query WHERE clauses, such as FOR EACH statements, FIND statements, and the OPEN QUERY statement.  For a dynamic query, this may not be detected until the first GET-XXXX method after the query is opened. It is possible that mistakes in existing ABL will be uncovered by this change.  Now any error that occurs will be raised and handled by the normal error handling mechanisms.

Here is an unrealistic but illustrative example:
FOR EACH customer WHERE custNum > INTEGER("A"):
   ...
END.

This will now raise an error.  It used to resolve to:

FOR EACH customer WHERE custNum > ?.

In this case, to catch the error raised, use a CATCH block in the block containing the FOR EACH statement (not inside the FOR EACH block as that block has not actually started yet).

If this causes any issues, you can use the zNoQryExpErrors startup parameter to revert to the old behavior.  Please note that this is meant to be used as a temporary work-around.  It is possible that without it, you may, occasionally, be returning incorrect data to your customers.  So Progress Software strongly recommends that in the long-term, you fix your code to avoid any new errors rather than use this undocumented startup parameter.