Question Progress 9.1E and IBM AIX version

[Louise]

Hi,

Yes, it is true, I help support an application that is actually still running in Progress 9.1E. It is running on a machine with IBM AIX 5.3 as the OS.

Do any of you know or can recall/remember whether there is a particular limitation on which IBM AIX version Progress 9.1E can run?

Also, if we do go down another route, any things to look out for when moving to a different UNIX OS?

Many thanks

 

[Stefan]

google:

site:progress.com product availability 9.1e aix

Provides Which versions of OpenEdge are supported against what AIX platform versions, which contains:

Progress 9.1E: (Java not supplied)

• AIX POWER 5L 5.1 32-bit with ML5 JVM 1.3.1 SR6
• AIX 5L 5.2 32-bit with ML1 JVM 1.3.1 SR6
• AIX 5L 5.3 32-bit with JVM 1.3.1 SR6

AIX 5 64-bit, port will not be certified against Progress 9.x

 

[Louise]

Thanks Stefan, much appreciated.

We are looking into moving our system to a VM, still getting info from external vendor as to which OS can run on it.

Also contacting our Progress support vendor re access to the ESD to see if we can still download that version in case we need to move to another OS as I’m pretty sure we will then need to dump and load ie rebuild the database.

Fun times… ( starting to experience hardware issues but still need to keep it all going for 12 months..)

 

[TomBascom]

There are really only two platforms that you should consider migrating to -- Linux or Windows. Of the two Linux will be far less likely to be a problem, since you are already on AIX Linux ought to be much more familiar.

In either case you will need to dump & load for the platform change. AIX databases cannot be successfully copied directly to Linux or Windows. If you somehow manage to find a vm with 9.1E on it you might not need to recompile. But I wouldn't hold my breath.

Do you have all of the source and are you able to successfully compile it? If those are both "yes" then there is nothing significantly limiting your choices with regards to newer OpenEdge versions. (Ok, if you have appserver code you will have to update it to PASOE for OE 12, but that's relatively easy). In that case the last barrier to upgrading to a modern release is "have you been keeping your Progress maintenance up to date?" If so, no problem. If not... you will need to fix that.

Is this an in-house app? Or something purchased from a Progress partner? That can have quite an impact on the "can you re-compile" and "is maintenance current" questions.

 

[Louise]

There are really only two platforms that you should consider migrating to -- Linux or Windows. Of the two Linux will be far less likely to be a problem, since you are already on AIX Linux ought to be much more familiar.

In either case you will need to dump & load for the platform change. AIX databases cannot be successfully copied directly to Linux or Windows. If you somehow manage to find a vm with 9.1E on it you might not need to recompile. But I wouldn't hold my breath.

Do you have all of the source and are you able to successfully compile it? If those are both "yes" then there is nothing significantly limiting your choices with regards to newer OpenEdge versions. (Ok, if you have appserver code you will have to update it to PASOE for OE 12, but that's relatively easy). In that case the last barrier to upgrading to a modern release is "have you been keeping your Progress maintenance up to date?" If so, no problem. If not... you will need to fix that.

Is this an in-house app? Or something purchased from a Progress partner? That can have quite an impact on the "can you re-compile" and "is maintenance current" questions.

Thanks Tom.

Pretty unique setup as we can compile part of the system that is running against the main db (so the one where the systems working master tables and trx tables are) but when the support was taken over years ago (before my time), the other part against the db where the system users, menu functions etc run off where 'bought' encrypted, compiled and with now key supplied....So it is this part that has limited moving it to newer versions, combined with significant rewrite due to key word use (as you know these have changed since this version). The organisation is moving to a SAP solution but the existing application is critical to the business so needs to be kept running for another 12 months.

We do have a support agreement via a vendor, but due to the version, support is understandably a relative term here ;-)

 

[TomBascom]

I might be flogging a dead horse but just to clarify... do you mean that you lack a key to decrypt the xcoded files back to clear text?

(That's normal. There is no Progress provided utility to convert xcoded source back to clear text. Obviously the compiler knows how to do it. There are also a few utilities floating around "out there" that can do it. But none are provided by Progress. If that is the only problem then this is not a barrier to upgrading.)

Or are you saying that they encrypted some source with a non-default key and that you cannot create r-code from those xcoded sources anymore because you do not have that key?

If you can run directly from xcoded sources, rather than only from r-code, then they either used the default key or the other key must be embedded in a script or pf file somewhere locally. In that case upgrading is still feasible.

Also - I'm curious, what vendor did you purchase that tooling from? It sounds like it might be some sort of "framework". Depending on what it is there might be someone who knows more about it.

Regarding keywords... The list grows but "ABC" never becomes "XYZ". That can be annoying but there is a parameter (-k keywordlist.txt) which specifies keywords to "forget" when compiling. This allows you to continue to compile old code even if it has field or variable names that have been "promoted" to keyword status. That can be very handy when porting old code. There are lists of new keywords associated with version changes, this kbase explains: Progress Customer Community where to find them.

 

[Louise]

I might be flogging a dead horse but just to clarify... do you mean that you lack a key to decrypt the xcoded files back to clear text?

(That's normal. There is no Progress provided utility to convert xcoded source back to clear text. Obviously the compiler knows how to do it. There are also a few utilities floating around "out there" that can do it. But none are provided by Progress. If that is the only problem then this is not a barrier to upgrading.)

Or are you saying that they encrypted some source with a non-default key and that you cannot create r-code from those xcoded sources anymore because you do not have that key?

If you can run directly from xcoded sources, rather than only from r-code, then they either used the default key or the other key must be embedded in a script or pf file somewhere locally. In that case upgrading is still feasible.

Also - I'm curious, what vendor did you purchase that tooling from? It sounds like it might be some sort of "framework". Depending on what it is there might be someone who knows more about it.

Regarding keywords... The list grows but "ABC" never becomes "XYZ". That can be annoying but there is a parameter (-k keywordlist.txt) which specifies keywords to "forget" when compiling. This allows you to continue to compile old code even if it has field or variable names that have been "promoted" to keyword status. That can be very handy when porting old code. There are lists of new keywords associated with version changes, this kbase explains: Progress Customer Community where to find them.

Thanks Tom, I will look into some of the further. Will have to double check re r-code vs xcoded source situation.

For interest, where would one find the default key? Do you mean the default key would be embedded in some script or .pf file? Thanks again.

 

[Stefan]

For interest, where would one find the default key? Do you mean the default key would be embedded in some script or .pf file? Thanks again.

See manual xcode utility:

If you do not specify key, XCODE uses a default key.

and from the notes section

Compile encrypted procedures with the XCODE option on the COMPILE statement. (The XCODE option is not required if the procedures were encrypted with the default key