The functionality of @CAL may be attained using a combination of record projection, record traversal with the visitor pattern and custom formulas that support aggregate functions like VSUM and VMAX.

One of the challenges in migrating MAPPER applications is that commands like @CAL, @CAU, @ART, @CHG, @DC and @SC employ a specific syntax when invoked from a MAPPER RUN, but also use their own internal directives, expressions, terms and verbs. MJ supports parsing of @CAL, @ART, @CHG and @DC equations and @SC directives.

MAPPER's @BFN statement allows an application to find the position of a simple or compound key value in one or more reports, to count occurrences of a key value and to build an index for faster report access. MAPPER utilizes line number to denote the position where a key value occurs (or should occur) and assumes reports are sorted by the key.

MJ supports finding and counting of key values, but not indexing or verification of key order since these are handled by the RDBMS. The position where a key value occurs is represented by the key value itself and not a line number. However, a custom implementation of MJLineNumber wraps the key value, preserving the pattern of traversal by line number in migrated applications.

As descrived above, @BFN can be emulated in the initial version of a migrated application, but is obviously a prime candidate for re-factoring since relational databases hide such details about data access.

When the hash value returned by @HSH serves as a numeric identifier to index information (for example, hashing a last name to a report ID), modern practices such as table partitioning should be considered as an alternative to keeping a large number of union-compatible tables. The shadow table employed by MJ contains MAPPER "metadata" such as cabinet, drawer and report, allowing hashed report IDs to be correlated with partitioned data.

MJ converts a RID containing data to an entity backed by a table in a relational database. The ACID behavior of MAPPER's deferred updates is best accomplished via database concurrency control and transactions. Hibernate ORM exploits these features in a database-independent way.

A combination of Hibernate transaction management, LockMode.UPGRADE_NOWAIT and READ COMMITTED transaction isolation level is recommended to handle @DFU, @CMU and @DCU. In some situations, locking the affected tables may be a useful alternative to LockMode.UPGRADE_NOWAIT.

Statements @LOK and @ULK may be handled by locking the affected tables and using transaction isolation level SERIALIZABLE.

One approach is to raise error or abort conditions as exceptions, and dispatch the exceptions to handlers using a framework like Apache DeltaSpike.

The answer depends on the functionality provided. External functions that perform unique, complex processing may require JNI (Java Native Interface) to retain code from the C-based solution, while simpler external functions may benefit from re-factoring in Java.

MJ supports statements @LGN, @LGF, @FCH, @RAM and @SQL for databases accessible via JDBC and ODBC, but does not include tools such as MRIDBA or RDI to perform administrative tasks or execute DDL and DML.

As mentioned above, MJ converts a RID containing data to an entity backed by a table in a relational database. The entity (and underlying table) can be queried to obtain a result. The result is a collection of Java objects, or more specifically, tuples. A result may itself be queried, producing another result, i.e., collection of tuples. MJ promotes the use of CQEngine to store and access collections efficiently.

Entities may be queried using Hibernate's criteria query feature, while collections may be queried with a similar feature found in CQEngine. Both query capabilities are generally compatible with the conditional operators available in MAPPER's @SRH command.

MJ converts a line of data in a RID to an entity instance backed by a row in a relational table. The line type from the data is preserved in a shadow table that corresponds to the entity. In MAPPER, line types often distinguish different kinds of data in the same RID. For example, the line type differentiates trailer lines from tab lines. MJ can treat distinct line types as different entities.

Line types that convey information about entity state may be represented by a Java enumeration. For example, different lines types that signify an order that has been received, fulfilled or back-ordered are good candidates for enumeration.

MJ preserves the line type since the initial migration of a MAPPER application is likely to rely on this information. As the migrated application evolves away from paradigms carried over for compatibility, the shadow table that stores the line type may be dropped. Of course, this isn't required. One can continue to run the migrated code "as-is" indefinitely, but most organizations eventually move to an "enhance and evolve" phase where constructs like the shadow table are removed as an artifact of the migration.

Line numbers are used heavily in MAPPER to seek to a position within a MAPPER data report, but relational databases don’t support the concept of line numbers.

MJ bridges this gap with a shadow table that stores a line number for each row in a domain table. The line numbers in a shadow table contain gaps to allow positional insert of new data.

Variables that store line numbers in MAPPER RUNs (for example, <lines>i6) are represented by type MJLineNumber. This class encapsulates a domain table and a line number, allowing migrated applications to continue to seek into a table by line number. Once associated with a result, an MJLineNumber may be incremented or decremented to traverse the next or previous "N" rows.

To model this buffer-oriented paradigm in a migrated application, MJ supports the use of a "record projection". The line is populated with formatted attribute data extracted from a corresponding entity, and characters overlaid into the buffer are recognized as fields, parsed into attribute values and set into the entity.

MJ promotes the use of Java Servlets to provide a similar yet standard runtime environment for migrated MAPPER RUNs. Because Java Server Pages (JSP) are compiled to servlets, native ICE services that are migrated to JSPs also run well in this environment.

MJ parses the various line types that comprise a MAPPER report, including @ lines in a RUN that contain MAPPER statements. MJ can also parse the MAPPER statements themselves to produce a parse tree, symbol table and control flow graph. From these artifacts, Java statements can be generated using an API like CodeModel.

The most straightforward conversion of MAPPER code to Java uses labels in a switch statement to emulate MAPPER's @GTO statement, since Java does not have go-to statement, and Java labels aren't useful as a replacement for @GTO. Pragmas provide an alternative approach to recognize looping and if-then-else constructs in @GTO code.

MJ is fairly agnostic because it's based on Java and JEE. These technologies embrace application servers such as JBOSS/Redhat, Glassfish, Tomcat, WebSphere and WebLogic and databases like Oracle, SQL Server, MySQL, Postgres, DB2 and Derby. Multiple cloud hosting options exist, including Openshift, Heroku and AWS Elastic Beanstalk.

Yes, in the sense that MJ supports migration of MAPPER applications, and all applications created by RADS are MAPPER programs. Here are some points to consider about MJ and RADS:

• RADS applications are well-structured, lending themselves to migration in this respect.
• Shared screen definitions for GUI and Web UIs amenable to conversion to GWT and JSP.
• RADS "black-box" functionality (such as that invoked via @CALL) may be replicated in Java.
• Drill-down feature is a function of report design and may be emulated in migrated MAPPER reports.