can 11.1 run 11.2[.1] r-code ?

*bump*

Anyone got any idea ? From some experiments, it looks like 11.1 can run 11.2 r-code but I really need to know if it's a supported configuration

thanks !

Maybe.

11.0 was supposed to reintroduce unified r-code.

At first it didn't work at all and just crashed, this was fixed in 11.1.

It then worked unless you were using a DataServer, in which case it just crashed.

This was fixed in 11.2, but it wasn't (it just crashed). This was fixed in 11.2.1.

Now it works. :-)

When using a Progress database you may not run into issues...

what you are referring to is 32/64 bit r-code compatibility, right ?

I was wanting to take code compiled with 11.2 and run it on an 11.1

platform (both 32 bits)

Yes.

To accomplish this, I was led to believe that internal data structures had to be aligned to allow the same r-code to run on both 32 / 64 bits. Since you cannot put something large into something small I would assume that the structures were aligned to the 64-bit side. This would imply that 32-bit r-code contains invalid 32-bit structures which are expected to be 64-bit aligned.

Since we only had issues with the DataServers as of 11.1, you may not have an issue when only using a Progress database.

The 11.0 FCS release has introduced the 32-bit\64-bit compatibility issues with r-code and the problem was resolved in 11.3 sp1.

Also, the layout of RCODE structure is not similar in 11.1 and 11.2 releases for Data Server. That means the 11.2 compiled r-code will not work with 11.1 even though they are compiled on the same bit architectures (32 and 32 or 64 and 64 ). This bug was also got fixed in 11.3.1 release. Again if anyone moves to 11.3.1 they need to recompile their application at least once to make sure the r-code generated will be forward compatible with 32-bit\64-bit architectures as well as Little-Endian and Big-Endian platforms.

What is sp1?

The problem was solved in 11.2.1, so what does 11.3.1 have to do with it?

Yes, the compatibility issues were fixed in 11.2.1 , sorry for the typo. Please read it as 11.2.1 in place of 11.3.1.  And I mean 11.3 sp1 means 11.3.1.

Here is info on compatibility for the 11.3 release:

With the exception of DataServers customers, there will not be a requirement to recompile 11.x (x < 3) r-code in this release.  11.3 can execute r-code generated with 11.x (x<3), you cannot execute r-code generated with release 10, v9, v8 or earlier.

11.x (x<3) may be able to execute r-code generated with 11.3.  The recommendation is to recompile.  

For DataServers customers, due to a problem introduced in the 11.0.0 and 11.2.0 releases, any DataServer R-code that was created between 11.0.0 and 11.2.0 on both 32-bit and 64-bit platforms is not portable to newer OpenEdge 11 versions after 11.2.0, which includes releases starting at 11.3.0. Therefore, all MSS, ODBC and Oracle DataServer customers with r-code compiled between OpenEdge release 11.0 through 11.2 FCS will need to recompile and redeploy their r-code when they upgrade to 11.2.1 or 11.3.0.  This is true on all 32 and 64 bit platforms.  Customers should not apply the 11.2.1 service pack or 11.3 FCS release  if they are unable to perform recompile once on either version 11.2.1 or 11.3.0 for their MSS, ODBC and/or Oracle DataServer applications.  Once compiled on either 11.2.1 or 11.3.0, full r-code compatibility will begin for every OpenEdge 11 release moving forward.  If code has already been recompiled at version 11.2.1 or greater, you will not need to recompile your code in order to move to version 11.3.

WebClient applications can upgrade from an OpenEdge version to any later OpenEdge version using Intellistream with the following exception: in order for a WebClient application to upgrade from OpenEdge 10 to OpenEdge 11, customers must first upgrade to at least 10.2B03.  This is due to version format changes in 11.0.  

Due to some code changes in the Java Open Client runtime required for Mobile, any ProxyGen created Java proxies will need to be regenerated.  Customers can either continue to use their existing proxies along with the o4glrt.jar they were created with, or rebuild the proxies using the OpenEdge 11.3 version of ProxyGen or bproxygen.

GUI for .NET is another exception. The compiler will write the exact version of the referenced assemblies into the r-code and at runtime those versions are required. This includes Infragistics Assemblies and the Progress bridge build in types.

Between Service packs, Progress implements assembly probing to define compatible assembly versions. But not between releases.

So prowin32.exe.config in 11.3.1 has (among others)

   <dependentAssembly>

     <assemblyIdentity name="Infragistics4.Win.UltraWinGrid.DocumentExport.v13.1" publicKeyToken="7dd5c3163f2cd0cb" culture="neutral" />

     <publisherPolicy apply="no"/>

     <bindingRedirect oldVersion="13.1.20131.2015" newVersion="13.1.20131.2048"/>      

   </dependentAssembly>

which will allow a runtime of 11.3.1 use r-code compiled against the Infragistics version shipped with 11.3.0.

But not for 11.2 or 11.1. And it has been like this since 10.2B at least.

semi related: we recently experienced an issue where the pause behavior is different between 11.3 and 11.1.

If you compile the following in 11.3

pause 5 no-message. 
message "Here" view-as alert-box.

and run the resulting .r in a 11.1 client you will need to wait a *very* long time (weeks/months) to see the message.

I'm told this is to do with the translation and re-translation of fractional seconds in 11.3.

The issue you are experiencing is a bug.    The language team's model / goal is that  rcode should always execute properly  in a previous version (same major release) as long as the application does not take advantage of a new feature.  In the example noted above the program is not utilizing a new feature and therefore this should have worked properly in a previous release (11.1. for example).  A defect (PSC00286613 ) was logged to track this issue.

The problem is that the compiler now stores the PAUSE value as a Decimal (in order to store sub-second values) and not an Integer (as it used to).  When developer takes an 11.3 generated rcode file and deploys it in an 11.1 environment, the AVM (runtime) wants to interpret the PAUSE value as an Integer but it is stored in the rcode as a decimal.  Hence the error.