Upgrade Questions 10.2B to 11.6 and OS Migration

LawnyToast

New Member
I am just going to Dump a lot of information here so bare with me...

We are hitting a roadblock with Windows Server come 2020. Our OpenEdge 10.2B DB is hosted on a VM who's OS that is going end of life in January. Our software has been created and curated in 10.2B for 12 years. We own 11.6 but never upgraded due to concerns with our software's compatibility. In the midst of our OS upgrade, we are considering a DB upgrade as well: From 10.2B to 11.6. I am aware of some threads that have a similar topic, especially this one - ...binary-d-l-from-10-2b08-to-11-7-5.191608... I have many questions, but my largest concern is compatibility.

Do you know if any of our code will have to be re-compiled or re-written if we upgrade to 11.6? My initial thought process is "No". Since this is just updating 'where' and 'how' our records are kept, at most we will just have to tell the software to look in different areas for the information. Any input or experiences provided will help.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I am aware of some threads that have a similar topic, especially this one - ...binary-d-l-from-10-2b08-to-11-7-5.191608...
Can you edit that to make it an HTML link? There is an "Insert Link" button on the toolbar, and the shortcut is Ctrl+K.

We own 11.6 but never upgraded due to concerns with our software's compatibility.
Are those concerns documented? Can you share them with us?

Do you know if any of our code will have to be re-compiled or re-written if we upgrade to 11.6?
You will have to recompile. R-code contains a compiler version number and that version is incremented with each major version increase. So r-code compiled with a 10.x compiler will run in any 10.x client but not in an 11.x client.

Whether your code has to be rewritten is another matter. My first thought is "probably not" though of course the devil is in the details. It depends entirely on your code.

Progress is very good about maintaining backward compatibility with old code so in general you shouldn't have a problem unless you depend on some language feature or product that no longer exists in late 11.x, which is very unlikely. There is the possibility that some identifier is used in your code which was not a keyword in 10.2B but now is in 11.x. In that case you could revise the code or you could use a keyword-forget list to make the existing code work.

It is also possible your application depends on some Progress framework or library, so you would have to test with an 11.x installation to ensure it still
works the same, that call signatures haven't changed, etc.

Another point: if you are concerned about end of life for your OS, you should be equally concerned about end of life for your application platform. Don't bother upgrading to 11.6 now, as it is already in retired status. You would be better off upgrading to at least 11.7, as it will remain in mature status for some time to come. Even better would be to upgrade to 12.1, provided you don't depend on one of the many features that were removed in 12.x (which are not listed in the Product Availability Guide). Even if you do, and you opt to upgrade to 11.7 instead, you should still start developing a plan to get to 12.x soon so you don't find yourself in the same boat you are in now, running software on a retired platform.
 

TomBascom

Curmudgeon
11.6 is pointless. 11.7 would be sort of current but it will be obsolete by the time you get there. 12.1 makes more sense.

and another thing...

The db server can just as easily be on Linux as on Windows.
 

LawnyToast

New Member
Can you edit that to make it an HTML link? There is an "Insert Link" button on the toolbar, and the shortcut is Ctrl+K.
Here is the Referenced Thread. It discusses a DB upgrade with a similar jump. Particularly focusing on the Dump & Load strategy. I will definitely be referencing the thread come crunch time. This article from Progress as well.

Are those concerns documented? Can you share them with us?
The concerns are not documented, but I believe they were regarding the "re-compiling" you mentioned in your reply. Our software uses quite literally thousands of r-codes, some of which are 15000+ lines in length. If there is a language barrier between the two versions, we would most-likely run right into it. As for 12.x. Nothing on the list you mentioned stands out to me. We currently use the Progress Proenv and AdminServer, and I do not believe this is mentioned as removed in 12.x. We have not innovated much in these 12 years and I am just now inheriting it all.

The db server can just as easily be on Linux as on Windows.
You makes a fantastic point, but everyone here is used to the Windows Server environment. Plus, we already have the licenses. As for 11.6 being pointless, I will have to see what we own/have the rights to use. But as far as I am educated, that is what we have available to us.

Thank you for your replies. I will continue checking in as dates draw nearer.
 

TomBascom

Curmudgeon
The "pure progress" part of an upgrade is easy. Install a new version of Progress, run the conv1011 utility (or dump & load), recompile and you are probably done.

Once in a while you might run into glitches such as those Rob describes. But those are all just speed bumps. None of them are hard to overcome.

More concerning is if your application relies on external interfaces that are specific to some flavor of Windows (32 bit ActiveX components as an example). Those sorts of things can be much more of a problem to overcome.

If the *server* is just a db server none of that matters. Those are all client considerations. Presumably your client code runs on something other than whatever flavor of Windows Server is being retired. Hopefully not XP ;)

If the *server* also hosts app servers *and* the app servers rely on Windows DLL calls then you need to check those out.
 

TomBascom

Curmudgeon
As long as your maintenance is paid up you should be able to get a current release and change platforms without much trouble or cost.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Particularly focusing on the Dump & Load strategy.
Your interest in this intrigues me. You may very well benefit from a dump and load, depending on the current state of your database and the changes you intend to make. If you are going to go to that effort, you should ensure that you employ a modern structure design. But you don't need to dump and load as part of this OE version upgrade, unless you are also planning a platform migration from Windows Server to Unix.

How to dump and load is another conversation. It could be simple and straightforward or it could involve a lot of iterations of testing and benchmarking. It all depends on the size of your database, the capability of your hardware, and the available window of downtime for the outage.

The concerns are not documented, but I believe they were regarding the "re-compiling" you mentioned in your reply. Our software uses quite literally thousands of r-codes, some of which are 15000+ lines in length. If there is a language barrier between the two versions, we would most-likely run right into it.
Recompiling is easy. If you have the source, the right propath, and the new OpenEdge installed (with a development product, of course), you can compile.

I'm not sure what you mean by "language barrier". The best way to find out whether any obvious code changes would be required in an upgrade is to upgrade. Install a new OE release on your build server (alongside 10.2B) and compile. Then run whatever tests are appropriate. Then assess your compile logs and test results and go from there.
 

Cringer

ProgressTalk.com Moderator
Staff member
Tom and Rob are both correct. They both have a lot of experience in this, as do we. You may well find that the experience of upgrading is a lot easier with some specific consultancy, so please do reach out if you think you would benefit.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Some thoughts on structure design:
Answered - Dump And Reload - Can I Reduce The Fixed Database Size..

Thoughts on upgrading across a major version boundary:
Question - Does anyone have a demo of Progress database migration?

An upgrade is also a good time to revisit your backup and recovery (AI files, AI archiving, warm spare DB, OE Repl targets, etc.) configuration to ensure it is working, it is being monitored for failures, and it is in alignment with business goals (RPO/RTO).

Given the size of the jump in OE version you are planning, you should also reevaluate your client and database broker startup parameters. A lot of new features have been added since 10.2B, and in some cases you will need to use new parameters to take advantage of them.
 
  • Like
Reactions: rzr
Top