What is the suggested approach to migrate the
@CAL and @CAU commands?
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,
@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,
@DC equations and
Is there a recommended approach for handling
@BFN (binary find)?
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.
How can the @HSH
command be migrated?
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.
What approach is suggested to handle @DFU,
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
and READ COMMITTED transaction isolation level is recommended to handle
@DFU, @CMU and
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.
How can error and abort routines registered by
@RER and @RAR
be modeled in a
One approach is to raise error or abort conditions as exceptions, and dispatch the
exceptions to handlers using a framework like Apache DeltaSpike.
What is suggested to migrate external functions compiled into MAPPER and
executed via @*cmd?
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.
Does MJ support MRI (MAPPER Relational Interface)?
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.
Does MJ suggest an approach for handling result RIDs?
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.
How does MJ process MAPPER line types?
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.
How to handle use of line number in migrated
MAPPER reports and applications?
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)
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.
How can updates that overlay
characters into column positions in a MAPPER line be handled?
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.
Does MJ provide an execution environment for migrated MAPPER RUNs?
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.
Is automated conversion of MAPPER code possible with MJ?
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.
Which platforms does MJ support?
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.
Does MJ include support for RADS (Rapid Application Development Studio)?
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.