Production PAS question (runtime compilation of ABL query programs) - Forum - OpenEdge Development - Progress Community

Production PAS question (runtime compilation of ABL query programs)

 Forum

Production PAS question (runtime compilation of ABL query programs)

This question is answered

I have a question about Pacific App Server (specifically related to the production license).  I've searched a little while already, but haven't found any previous discussion on this topic.  It surprises me a bit that this hasn't come up in the forums but I suppose there is a first time for everything.

Our legacy ERP code is written in ABL and has a mix of pre-compiled and uncompiled ABL source (ie. compiled at run-time).  One of the use-cases for the classic OE appserver was to generate datasets (temp-tables) from dynamically compiled ABL.  The ABL would conditionally use different compile-time parameters ({1}, {2}, etc).  The data generated into these temp-tables could then be browsed by a user in a datagrid U/I, or else rendered to a PDF report.

Our legacy ERP code has hundreds of these uncompiled ABL p-code source files; they can only be compiled dynamically after the conditional selection of compile-time parameters.  Many of these uncompiled source files have been used as-is for 10-20 years.

Will production PAS not allow us to use any of those uncompiled source programs anymore?  Is there an alternative approach that people are using as a work-around (perhaps installing another Progress license on the same server and shelling out to some other variation of _progres)?  I understand that some of our legacy uncompiled programs might be able to be re-written using dynamic queries, but that would be a substantial amount of work.  That would be considered a whole separate project outside the scope of a migration from classic appserver to PAS.  It would also introduce additional risk, since the programs would need to be substantially re-written.

Please let me know if this has come up as an issue in any other migrations from classic appserver to PAS.  I'd like to know what types of work-arounds are available.  

Thanks, David

PS.  Since I haven't actually tried the production PAS license yet, I may be completely mistaken about this perceived problem.  Am I correct to understand that production PAS will not allow us to use those runtime-compiled programs anymore?  That seems to be a significant limitation.  I was under the impression that OpenEdge ABL prided itself on the runtime compilation features in the AVM (making the language quite a bit more dynamic than others that were created in the same time period).

Verified Answer
  • David,

    If you install only PASOE Prod license then you can only execute .r code. If I have ABL code that I do not want to compile and execute it in PASOE Prod, then I install 4GL Development license in-addition to PASOE Prod license and it executes both rcode and uncompiled ABL source code.

    Regards,

    Irfan

All Replies
  • David,

    If you install only PASOE Prod license then you can only execute .r code. If I have ABL code that I do not want to compile and execute it in PASOE Prod, then I install 4GL Development license in-addition to PASOE Prod license and it executes both rcode and uncompiled ABL source code.

    Regards,

    Irfan

  • Thanks for the tip.  That is exactly the answer I was hoping for.  But I'm nervous that all the extra licenses for 4GL development may break the bank.

    I'm a bit surprised by the whole concept of R-code-only ABL.  I suppose ABL is expected to be written quite differently nowadays than the way we did it 20 yrs ago.  Perhaps others have done a better job of modernizing their ABL code over the years...

  • Rather than use a PAS for OE Development server, consider installing the 4GL Development System license to compile your .p modules at run-time.  

    If installing the 4GL Development System license is not the correct answer for your application, install both the PAS for OE Development and the PAS for OE Production license - that will give you a secured production server install without the run-time restrictions enforced by the Development license.

  • One of the most common reasons for compile on the fly coding back in the day was to create tailored queries for a rich set of criteria.  This is pretty much not required since the introduction of dynamic queries.  Admittedly, this can mean a lot of work to change over...

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • As Thomas mentioned, much of the reason for the dynamically-compiled ABL source is to generate temp table results from conditions that are formulated at runtime.  Other times it is because there is a datagrid in the U/I that needs to be bound directly to a very large OE datatable and this U/I needs to be conditionally sorted based on one OE index or another.  Finally I would add that many of the programs that generate reporting output are not precompiled as a matter of course because of similar reasons to the ones already mentioned.

    Can anyone point me to a warning or announcement about the deprecation of the runtime compilation features of ABL?  While I am personally aware of how to use dynamic queries, my reasoning for doing so is typically related to performance optimization (ie. to eliminate the extra fractions of a second that are required to compile ABL at runtime).  I would imagine that many ABL programmers are still taking advantage of runtime compilation features, and are unaware that these features are disallowed if/when their stuff is ever deployed to certain production licenses, such as production PAS.

    I'm still a bit surprised by the whole concept of R-code-only ABL.  It seems a bit abrupt for Progress to change the rules of the game without any forewarning.  It was not until I started reading about the production license of PAS that I first learned that large portions of our legacy ABL ERP would not be supported to run as-is.

  • David,
     
    The rules have not changed.  If you do not have a license installed which allows compilation then you can only run r-code.  It’s always been that way.
     
    Nor are we taking away runtime compile features.
     
    Brian

  • So, here are the licenses that allow us to run our current ERP codebase in production:

            Product Name:  OE Enterprise RDBMS

            Product Name:  OE Application Svr Ent

            Product Name:  Query/RESULTS

    There is a KB that describes what licenses have compile capabilities:

    knowledgebase.progress.com/.../P166195

    Based on your response, along with my reading of that KB, are you saying that I can simply swap out "OE Application Svr Ent" for the new "Pacific Prod AS for OE" and our code will run as-is?  (Irfan and Michael had very different recommendations, if you look at their comments above.  In particular they didn't mention anything about the "query/results" license - whatever that is.)

    If the "query/results" license is essentially behaving like a 4GL Development license, then we should be all set to use that with PAS too, right?

  • David,
     
    The Query/RESULTS license allows you to compile and run code that does /NOT/ update the database.
     
    What happens if you remove that license from your config?
     
    Brian

  • Also, a key piece of information that is missing is whether you are using encrypted source code for the stuff that gets runtime compiled

  • We never update the database except in pre-compiled r-code.  Thomas had pointed out the primary reasons for compiling things dynamically at runtime.  Those are the same reasons we have uncompiled programs in our ERP too.

    I'm not really sure how to remove that "query/results" license from our productoin or pre-prod servers and test the behavior of "OE Application Svr Ent".  I typically only work on the development servers (using PDSOE and the like).  Once we are in the process of setting up "Pacific Prod AS for OE" I will test it without "query/results" and then follow up with another test after "query/results" is applied (I'm assuming that the second tests are going to allow our uncompiled ABL to start working again, after initially failing the first tests).

    As far as I am aware we haven't used the source "encryption" in production for a number of years.  If I remember correctly, we once used the default encryption key for our internally deployed ABL applications but don't do that anymore.

  • >> We never update the database except in pre-compiled r-code
     
    Bingo!

  • Ok.  Sounds like "query/results" is the key.  

    Someone should really think up a better name for that license (eg. "Dynamic Production Compiler")?   It might be the most confusing OE license you have, perhaps aside from "client networking".  

    I guess the people responsible for software policy and licensing aren't being graded on making these names meaningful or easy to understand.  Another case in point... for the longest time we were paying for developers to have *both* OE Studio and Progress Developer Studio for OE.  And I still don't really know what OE Studio is/was.

  • Query/Results has always been the license for dynamic, compile on the fly reporting.  It was originally just Query, which was actually a pretty good description of its purpose, until the Results tool was added.  They were natural companions.

    As for the other two, they really are or were separate products.  OpenEdge Studio is the original non-Eclipse product and PDSOE the Eclipse-based product intended as its replacement.  When PDSOE was new, there were people who wanted to stick with the older product, but as time has gone on more and more of the functionality of that product has been incorporated into PDSOE.  I don't think there is much of a role for anything but PDSOE in the most recent versions.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • While I'm not certain if this applies to OEPAS, we had a similar issue many years ago with a server that only had the enterprise database and AppServer installed. The solution was to install a product named "OE Development Server".

    I believe Progress supplied this and appropriate serial numbers at no charge as we also owned development licenses but for 32 bit rather than 64 bit.