JCL 2018-01-15T12:29:02+00:00

The Raincode JCL interpreter for Microsoft .NET

The Raincode JCL (Job Control Language) Interpreter is aimed at making the transition to the .NET platform as smooth and as painless as possible. The exact same behaviour from the mainframe is reproduced. Unlike JCL’s original heavy syntax our JCL Interpreter is light.

  • Generated thread-safe code for .NET 4.5.1 and beyond in 32 or 64-bit mode, with a mainframe-compatible memory layout representation

  • Seamless integration with Raincode’s PL/I and COBOL; compilers as well as with C# and VB.NET code

  • Azure-ready

  • Populate a repository for statistics and portfolio analysis tasks

  • EBCDIC support

  • Support for advanced assembler constructs, including self-modifying code

  • Comprehensive coverage of the macros

Request a technical deep dive

Learn how to streamline your legacy code migration to .NET and understand the migration paths that apply to your applications’ portfolio. Reducing MIPS is the obvious company motivation while keeping reliability, availability and security is your mission.
Let’s deep dive and walk on the compilers’ wild side.

REQUEST A TECHNICAL DEEP DIVE

Exclusive: Run unmodified DB2 code on SQL Server

In theory, the DB2 SQL statements included in your JCL programs should be usable as is on SQL Server.

But that’s theory only.

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 include built-in functions, operators, implicit type conversion, controlling locking, the number of records to fetch and more.

Migrating an application from one database to another used to be a migration project in its own right. Not anymore. The Raincode JCL Interpreter transforms DB2 SQL statements into equivalent SQL Server statements at compile time so that the existing code can run on the target database without any changes whatsoever.

Compiled programs can even target either of the databases based on a runtime flag. And since it all happens at compile time, there is no performance penalty involved. Statements run as fast as if they had been coded for SQL Server in the first place.