The newest version of CL offers enhancements in recovery, productivity, capacity, and serviceability.

With all of the wonderful enhancements to Control Language (CL) in V5R3 (multiple files, DOxxx loops, SELECT, etc.), V5R4 (subroutines, structures, pointers, etc.), and V6R1 (CLOSE, INCLUDE, DCLPRCOPT enhancements, etc.), you may have wondered what IBM would deliver for CL in the IBM i 7.1 release. Well, it turns out that 7.1 certainly does have some great new features for the CL developer.

Better Recovery and Productivity

Most of us had all but given up hope, but Retrieve CL Source (RTVCLSRC) for ILE is here! If you're unfamiliar with RTVCLSRC, it's a command that can be used to retrieve the CL source statements that were used in compiling a program—a wonderful time-saver for companies when the source for a program cannot be readily found (or when you suspect the program version isn't what it should be). Both the Create CL Module (CRTCLMOD) and Create Bound CL Program (CRTBNDCL) commands now support the Allow RTVCLSRC (ALWRTVSRC) keyword to indicate that the source for the program should be saved with the program. The Retrieve CL Source (RTVCLSRC) command now supports the new keywords SRVPGM and MODULE to specify the name and library of the service program or module from which the source will be retrieved (a new keyword wasn't necessary for programs as RTVCLSRC already had the PGM keyword for OPM CL programs). For completeness, even the Declare Processing Options (DCLPRCOPT) command has been updated to reflect that the ALWRTVSRC keyword now applies to ILE programs as well as original program model (OPM) CL programs. Historically, one of the key inhibitors for CL developers moving from OPM CL to Integrated Language Environment (ILE) CL has been the reluctance to give up the capability to retrieve or recover the source statements used to create a CL program. CL developers now have virtually no reason not to move to an ILE-based application environment.

In addition to adding RTVCLSRC support for ILE CL, V7R1 also provides improved source code sharing across modules, programs, and service programs. In V6R1, IBM provided the new Include CL Source (INCLUDE) command, which can be used to copy source from one source file member into the source program being compiled. The source being included (or copied) can be declarative commands, such as Declare (DCL) or Declare File (DCLF), or processing logic, such as shared subroutines (introduced with V5R4), common error-handling logic, etc. One limitation, however, exists with V6R1 INCLUDE support. The limitation is that the source member being included could not, itself, have INCLUDE commands imbedded within it. With V7R1, this limitation has been removed. You can now have a virtually unlimited number of nested INCLUDE commands within your CL source, providing for much greater sharing of common declarations and processing logic.

While we're on the topic of programmer productivity, a new OPTION value has also been added to the various CRT* commands for ILE and OPM CL. This new value, *DOSLTLVL for the Do/Select nesting-level option, indicates that two new columns of the CL compiler listing are to be produced, showing the nesting level for various control flow commands. One column indicates the level of loop-oriented commands, such as DOFOR, DOUNTIL, and DOWHILE, while the other column indicates SELECT-level processing. With the nasty habit of editors such as SEU to align all prompted commands to the same column, having nesting levels clearly identified in the compile listing certainly speeds up the process of finding the start and end of logical command groupings, a task I (and I'm sure you) frequently perform when looking at a CL source listing.

Higher Capacity

IBM has also enhanced the ability to declare integer variables within a CL program. Back in V5R3, the CL DCL command added support for 2-byte and 4-byte signed and unsigned integer variables (removing the need in many cases to use the %bin CL built-in). The 4-byte signed integer values could range from -2147483648 to 2147483647, and unsigned integers from 0 to 4294967295. While these are large numbers, they are not large enough for some applications. One specific type of application, where larger numeric value support is needed, is in the area of systems management.

Many systems are tuned throughout the day using CL commands, and this results in quite a few of the systems management applications being written, at least in part, using CL. The problem is that many of the system APIs that return system-level information, information that a systems management application needs access to in order to effectively manage a system, have evolved to using 8-byte integer values in order to reflect the high workloads that IBM i is capable of supporting. Compared to 4-byte integer values, 8-byte signed integers can store a value ranging from -9223372036854775808 to 9223372036854775807, and 8-byte unsigned integers a range from 0 to 18446744073709551615. With V7R1, CL developers who need access to these expanded ranges can simply DCL the appropriate variables as TYPE(*INT) or TYPE(*UINT) with LEN(8).

There are two considerations related to 8-byte integer support, neither of which I consider to be very limiting. The first is that 8-byte integers can be declared only within an ILE CL program. So if you're still writing for the OPM environment, my only comment is that it's time to move into the 21st century! The second consideration is that while the DCL command supports 8-byte signed and unsigned integers, the Parameter definition (PARM) and Element definition (ELEM) commands used in creating user commands do not. I have never encountered a need to supply a numeric value, to a command, even approaching the size of a 4-byte integer, and I really don't know that I would even want a user trying to supply such a number, at a command prompt, in any case. So I do not see this as being a problem. And I'm sure IBM could remove this limitation if it were to become a problem, just as they did for DCL and the need for CL programs to access system API information efficiently.

More Serviceability

What if you're not a CL developer? For users who administer or manage a system running CL programs, there is also good news in V7R1 for you. In addition to adding the ALWRTVSRC keyword to the CRTBNDCL and CRTCLMOD commands, these commands (along with the equivalent commands for RPG, COBOL, C, and C++) also added the Debug encryption key (DBGENCKEY) keyword. This support allows an ILE module or program to be created with the listing-level debugging view encrypted. For a company that develops CL programs strictly for their own use, this new capability may not be of much interest or value. But for companies that develop software products that run on IBM i for use by other companies, and, most importantly from your point of view, for the companies that install their software, this ability to encrypt debug data can lead to improved software serviceability.

Many companies that produce software products treat their source code as a valuable asset to be protected (so don't expect too many of these companies to provide their CL programs compiled with ALWRTVSRC(*YES)). This asset-protection view also means that historically no source-level or listing-level debug views were provided with the software that their users installed. Not having these debug views available can, as most CL developers who have ever tried to debug a problem with and without interactive debug can confirm, lead to longer problem determination times. The ability to encrypt the debug views, ship these encrypted views with the product software, and then, when necessary, decrypt the views on the customer system using the system-provided debuggers, can have a significant impact on the ability for software providers to more quickly determine the cause of a problem and provide a fix for the problem. This in turn leads to more timely correction of software problems for you—what I would consider a definite win-win situation for both software providers and the users of their software.

A Broad Range

The V7R1 CL enhancements touch many areas of your system. The ones touched on in this article include the following:

• Support for RTVCLSRC, providing improved source recovery
• Improved INCLUDE command support, enabling greater sharing of common code
• Access to a wider range of numeric values for CL variables
• Encrypted debug views, enabling improved software serviceability for third-party applications

These improvements can have a positive impact on your use of CL, whether you are a developer of CL programs or a user of CL-based application programs. With CL, life just keeps getting better.

My thanks to Guy Vig for providing these CL enhancements in 7.1. Guy is widely known, inside and outside of IBM, as "Mr. CL" and has been the driving force behind all of the CL enhancements we've seen in V5R3 through V7R1.