The Raincode JCL interpreter
The Raincode JCL (Job Control Language) Interpreter is plug-compatible with the zOs JCL. It makes the transition of the intricate business logic embedded in JCLs to the Azure and .NET platforms as smooth and as painless as possible. It is a proven, in-use product that is both robust and versatile.
Comes with replacements for many utilities (DF-SORT, IDCAMS, IEBGENER and more).
Full catalog support
Features efficient locking using Win32 API’s, which is much lighter and faster than using a database as lock server.
Runs code compiled by the Raincode COBOL, PL/I, and ASM compilers, but can also run steps written in virtually any code.
Support for a scan mode (for validation, without executing steps)
Support for a repository database gathering all the information regarding the JCL for statistics and portfolio analysis tasks
Support for Control-M’s Autoedit extensions
Can be configured and fine-tuned with user-written code adapt it to your own needs.
Comes with a versatile parser generator for the convenient development of additional utilities if necessary.
Exclusive: Run unmodified DB2 code on SQL Server
In theory, the DB2 SQL statements included in your COBOL programs should be usable as is on SQL Server. However, the reality is that it’s more complicated than that.
Even though SQL is a standard, there are so many discrepancies between SQL dialects that it is common to see portfolios where as many as 60% of the SQL statements require some level of transformation when moving from one database to another. Differences can include built-in functions, operators, implicit type conversion, controlling locking, and the number of records to fetch.
Migrating an application from one database to another used to be a migration project in its own right, but not anymore. The Raincode COBOL compiler transforms DB2 SQL statements into equivalent SQL Server statements at compile time, allowing you to run the unmodified code directly on the target database.
Compiled programs can target either DB2 or SQL Server based on a runtime flag, and since it all happens at compile time, there is no performance penalty to your system. Statements run as fast as if they had originally been coded for SQL Server.