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

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.

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

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?

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.