upgrades from 9.1E -> 11.5 + 11.3 -> 11.5

Posted by agent_008_nl on 08-Jan-2015 01:06

Hi,

We have a couple of applications running on 9.1E and one on 11.3.2.13 and would like to upgrade everything to 11.5. Starting with the one on 11.3. We use the database, appserver, oem, and oe with the sonic adapter. What would be required to upgrade. Database can stay the same I suppose, we would have to change some things like the propath in the .ini and copy & maybe change some files like ubroker.properties, fathom.properties etc? 

  What would it take to migrate from the old appserver to pasoe, is there a preferably not too verbose instruction doc?

When we migrate from 9.1E some more work is necessary, at least for the db. I suppose that's not different from moving to 11.3 and we already did that. But are V6 things like prompt for editing still working in 11.5?

--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

All Replies

Posted by Frank Meulblok on 08-Jan-2015 08:04

Speaking from ABL perspective only.

"What would it take to migrate from the old appserver to pasoe, is there a preferably not too verbose instruction doc?"

4 points of attention I can think of:

1. You'll need to double-check the AppServer connection strings, as the pasoe will be defined by URL only.

2. The PASOE will label operating modes differently, if you have ABL code that actively checks the SESSION:SERVER-OPERATING-MODE you'll need to double-check that.

3. If you're using .dll's / shared libraries on the AppServer side, you really will want to verify if the external functions you're calling are thread-safe, and if they are update the ABL definition with the THREAD-SAFE keyword. Otherwise only one request can be calling the dll at once, and you may end up causing unneccesary queues in the processing.

4. Also if you're using .dll's / shared libraries on the server side, keep in mind that PASOE is only available in 64-bit releases. So if you've not had to update the ABL code to take into account different pointer sizes & byte allignmnets yet, that becomes a requirement for the transition.

"But are V6 things like prompt for editing still working in 11.5?"

The syntax is still there, and that shoudl still work.

On the other hand, if you're coming across one of these things that's been deprecated for a long time already, you may want to consider phasing them out as part of the migration project.

Posted by agent_008_nl on 09-Jan-2015 00:07

Thanks Frank, I'm going to try out the pasoe.

Posted by Jeff Ledbetter on 09-Jan-2015 14:15

Hi.

"Otherwise only one request can be calling the dll at once, and you may end up causing unneccesary queues in the processing."

Are unnecessary queues the only negative affect of not using the THREAD-SAFE attribute?

Posted by Michael Jacobs on 09-Jan-2015 14:59

Complicated question.

When your ABL application uses a non-threaded safe/non-reentrant shared library the ABL sessions have to line up in a queue and wait their turn to use the shared library.  Queueing access to an external shared library is the default condition because OE cannot detect whether a shared library is thread-safe and reentrant or not and queueing the calls guards the application against data corruption and/or OS process crashes.  Obviously having each ABL session wait can have serious performance implications, especially if the shared library calls take a significant amount of time.  

When you ( the developer ) choose thread-safe and reentrant shared libraries in your application you can set the THREAD-SAFE attribute.  With THREAD-SAFE on OE does not queue ABL session calls into the shared library and all of the concurrently running ABL session's requests can access the shared library simultaneously.   This is the ideal situation for selecting external shared library support for your application because it will safeguard your application without impacting performance.  (OpenEdge has already certified as thread-safe all of the external shared libraries we standardly load as part of the ABL language engine so no ABL session queueing occurs)

If you ( the developer) insist on setting the THREAD-SAFE attribute on a non thread-safe / non-reentrant shared library you can expect that possibility exists for some data corruption and/or OS process crashes.   The fix for data corruption or OS process crashed instigated by the shared library is to remove the THEAD-SAFE attribute and have OE queue the ABL session's call to the library.

Does that help?

Mike J.

Posted by Jeff Ledbetter on 12-Jan-2015 07:02
Yes, that does help. Without the THREAD-SAFE attribute and using queueing, will the performance be similar to a traditional appserver then?
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: Michael Jacobs [mailto:bounce-mjacobs@community.progress.com]
Sent: Friday, January 9, 2015 3:00 PM
To: TU.OE.General@community.progress.com
Subject: RE: [Technical Users - OE General] upgrades from 9.1E -> 11.5 + 11.3 -> 11.5
 
Reply by Michael Jacobs

Complicated question.

When your ABL application uses a non-threaded safe/non-reentrant shared library the ABL sessions have to line up in a queue and wait their turn to use the shared library.  Queueing access to an external shared library is the default condition because OE cannot detect whether a shared library is thread-safe and reentrant or not and queueing the calls guards the application against data corruption and/or OS process crashes.  Obviously having each ABL session wait can have serious performance implications, especially if the shared library calls take a significant amount of time.  

When you ( the developer ) choose thread-safe and reentrant shared libraries in your application you can set the THREAD-SAFE attribute.  With THREAD-SAFE on OE does not queue ABL session calls into the shared library and all of the concurrently running ABL session's requests can access the shared library simultaneously.   This is the ideal situation for selecting external shared library support for your application because it will safeguard your application without impacting performance.  (OpenEdge has already certified as thread-safe all of the external shared libraries we standardly load as part of the ABL language engine so no ABL session queueing occurs)

If you ( the developer) insist on setting the THREAD-SAFE attribute on a non thread-safe / non-reentrant shared library you can expect that possibility exists for some data corruption and/or OS process crashes.   The fix for data corruption or OS process crashed instigated by the shared library is to remove the THEAD-SAFE attribute and have OE queue the ABL session's call to the library.

Does that help?

Mike J.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by Michael Jacobs on 12-Jan-2015 07:27
Jeff,
That is hard to determine without knowing the exact behavior of the application.   If the external shared library is executed infrequently where only one server's client would be executing it at any given time - I would not expect any performance degradation as the queuing would simply disappear as background noise.  On the other hand if the behavior is one where multiple client requests would be trying to access the library simultaneously, you can have no expectations that performance would be the same as a classic AppServer.

Best advice: avoid using non-thread safe external shared libraries at all costs when executing in any type of threaded process environment.

Mike J.

[collapse]
From: Jeff Ledbetter <bounce-jeffledbetter@community.progress.com>
Reply-To: "TU.OE.General@community.progress.com" <TU.OE.General@community.progress.com>
Date: Monday, January 12, 2015 at 8:03 AM
To: "TU.OE.General@community.progress.com" <TU.OE.General@community.progress.com>
Subject: RE: [Technical Users - OE General] upgrades from 9.1E -> 11.5 + 11.3 -> 11.5

Reply by Jeff Ledbetter
Yes, that does help. Without the THREAD-SAFE attribute and using queueing, will the performance be similar to a traditional appserver then?
 
Jeff Ledbetter
skype: jeff.ledbetter
 
[collapse]
From: Michael Jacobs [mailto:bounce-mjacobs@community.progress.com]
Sent: Friday, January 9, 2015 3:00 PM
To: TU.OE.General@community.progress.com
Subject: RE: [Technical Users - OE General] upgrades from 9.1E -> 11.5 + 11.3 -> 11.5
 
Reply by Michael Jacobs

Complicated question.

When your ABL application uses a non-threaded safe/non-reentrant shared library the ABL sessions have to line up in a queue and wait their turn to use the shared library.  Queueing access to an external shared library is the default condition because OE cannot detect whether a shared library is thread-safe and reentrant or not and queueing the calls guards the application against data corruption and/or OS process crashes.  Obviously having each ABL session wait can have serious performance implications, especially if the shared library calls take a significant amount of time.  

When you ( the developer ) choose thread-safe and reentrant shared libraries in your application you can set the THREAD-SAFE attribute.  With THREAD-SAFE on OE does not queue ABL session calls into the shared library and all of the concurrently running ABL session's requests can access the shared library simultaneously.   This is the ideal situation for selecting external shared library support for your application because it will safeguard your application without impacting performance.  (OpenEdge has already certified as thread-safe all of the external shared libraries we standardly load as part of the ABL language engine so no ABL session queueing occurs)

If you ( the developer) insist on setting the THREAD-SAFE attribute on a non thread-safe / non-reentrant shared library you can expect that possibility exists for some data corruption and/or OS process crashes.   The fix for data corruption or OS process crashed instigated by the shared library is to remove the THEAD-SAFE attribute and have OE queue the ABL session's call to the library.

Does that help?

Mike J.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse][/collapse]
Posted by Peter Judge on 12-Jan-2015 11:42

2. The PASOE will label operating modes differently, if you have ABL code that actively checks the SESSION:SERVER-OPERATING-MODE you'll need to double-check that.

Also check the SESSION:CLIENT-TYPE ... there's a new "MULTI-SESSION-AGENT" value.
 

1. You'll need to double-check the AppServer connection strings, as the pasoe will be defined by URL only.

If you are coming from a state-reset or state-aware appserver, you will need some extra code to make sure things continue to work as expected.
 
 
-- peter
 
 
[collapse]
From: Frank Meulblok [mailto:bounce-fmeulblo@community.progress.com]
Sent: Thursday, 08 January, 2015 09:05
To: TU.OE.General@community.progress.com
Subject: RE: [Technical Users - OE General] upgrades from 9.1E -> 11.5 + 11.3 -> 11.5
 
Reply by Frank Meulblok

Speaking from ABL perspective only.

"What would it take to migrate from the old appserver to pasoe, is there a preferably not too verbose instruction doc?"

4 points of attention I can think of:

1. You'll need to double-check the AppServer connection strings, as the pasoe will be defined by URL only.

2. The PASOE will label operating modes differently, if you have ABL code that actively checks the SESSION:SERVER-OPERATING-MODE you'll need to double-check that.

3. If you're using .dll's / shared libraries on the AppServer side, you really will want to verify if the external functions you're calling are thread-safe, and if they are update the ABL definition with the THREAD-SAFE keyword. Otherwise only one request can be calling the dll at once, and you may end up causing unneccesary queues in the processing.

4. Also if you're using .dll's / shared libraries on the server side, keep in mind that PASOE is only available in 64-bit releases. So if you've not had to update the ABL code to take into account different pointer sizes & byte allignmnets yet, that becomes a requirement for the transition.

"But are V6 things like prompt for editing still working in 11.5?"

The syntax is still there, and that shoudl still work.

On the other hand, if you're coming across one of these things that's been deprecated for a long time already, you may want to consider phasing them out as part of the migration project.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
This thread is closed