Increased Programmer
Productivity
Programming is simplified in native mode.  External file descriptions, for example, reduce the time spent maintaining converted application source code.  You can even decide whether to externalize all of your internal RPG file descriptions at conversion time or to do it in stages once your programs are running in the native environment.
  Generating queries and DFU programs against a program's data files is also easier in native mode than on the S/36 or in the S/36E.  Once again, the predefined external database file definitions supply the necessary record information, so the programmer does not have to build detailed IDDU data dictionaries before creating reports using QUERY/400 or manually create file descriptions when generating DFU utility programs for the converted database files.
  Another advantage conversion offers is that it gives S/36 programmers the chance to learn native mode programming concepts by reviewing the differences between the converted application code and the original S/36 source code.  Unlike rewriting an application, which requires in-depth native-mode knowledge beforehand, running a conversion familiarizes programmers with CL/400 programming, external file descriptions and screen subfile processing in RPG/400, and DDS on the AS/400.

Improved Application
Performance
A good application conversion can also ensure better overall system utilization.  Because when you convert S/36 applications to native mode, you can automatically put to work several performance optimization techniques.
  For example, in S/36 OCL procedures, it's common practice to delete and re-create files (e.g., job files, scratch files) at runtime.  On the AS/400, however, deleting and re-creating files are resource-intensive activities. A well-converted application's database files will be created only once, and when they need to be reset, they'll simply be cleared.
  A converted application will also take advantage of open data path (OPD) sharing for its interactive screen programs to further improve response times.  The converted application will preopen any files it needs during a sign-on session, minimizing the overhead required to open and close disk files.
  To ensure effective CPU use, conversion removes RPG left-hand indicator references and replaces them with blocked variable indicator checks (e.g., *INxx IFEQ, ELSE) to cut down on the number of comparisons executed by the converted RPG/400 code.  Conversion also reduces unnecessary identical consecutive condition expressions (IF statements), ensuring that the converted CL programs perform only the minimum number of comparison checks.

And compiled CL/400 programs execute faster than interpreted S/36 OCL procedures on the AS/400, so converting OCL procedures to CL/400 programs will automatically improve your applications'  efficiency.
  Of course, all the upgrades I've mentioned here could be accomplished through an application rewrite.  But as a rule, automation is the most economical way to handle anything but smallest of computer tasks. Conversion offers a distinct advantage over a manual rewrite because it takes less programmer time and effort.

Operating at Full Capacity
When you run your applications in the S/36E, you're employing your AS/400 in a limited capacity.  Because of this, using the S/36E should be regarded as a transitory stage.  You can only fully exploit your hardware investment by moving your S/36 applications to native mode.
  Conversion is the process that effectively realizes this goal while protecting your S/36 software investment.  The end result of a good automated conversion is a solid, cost-effective, native-mode AS/400 application that can be brought into production at far less cost and in far less time than a manual redevelopment project or application rewrite would ever afford.

For more information please visit  www.epi-software.com or email [email protected] .