PL/I Cafe

Under the old OS PL/I and PL/I for MVS compilers, all extents (i.e. bounds and string lengths) for STATIC variables and for BASED variables (not using REFER) had to be optionally signed integers. This made it hard to parameterize your code (unless you used the macro preprocessor and then your listing would look much different than your source).

With Enterprise PL/I however, extents are required only to be what are known as "restricted expressions", i.e. expressions that the compiler can reduce to a constant at compile time, and variables declared with the VALUE attribute may be freely used in those expressions.

So, if you want to declare the variables old_name and new_name to both have length 100, you could now use

either

or, perhaps better,

And note that if you want to change the lengths of these variables, since that length has been parameterized, you just have to change one declare.

Also, if you then wanted to declare a variable big_name to be 4 times as long (perhaps because it will hold the utf-8 version), you could do this nicely as

The Enterprise compiler will reduce any arithmetic expression to a constant if the operands are constant, and it will also reduce almost all built-in functions references whose arguments are constant expressions.

So if you wanted to declare 200-element arrays of the above names, you could do this cleanly via

Also, if you want to initialize the first element of the last array to the value "default" and all the other elements to a null string, you could do this via

but it would be better to let the compiler do the math and to write

and perhaps best of all would be the even simpler and sleeker

In summation:

Let the compiler count (as in the last declare above) and let it do arithmetic (as in the penultimate example) while you write code that is both more elegant and easier to maintain.

Code reviews were once common practice, but at some companies they have been reduced or even eliminated entirely. Often this has been done in the name of cost savings even though the earlier a bug is found in the application life cycle, the less it costs.

Also, if you are still conducting code reviews, your coworkers are probably not perfect: they can miss some errors and can overlook violations of your coding standards .

Fortunately, the Enterprise PL/I compiler can help you with the latter:

For example,

There are many other suboptions to the RULES option, and their default setting is to cause the compiler to behave as the old OS PL/I and PL/I for MVS compilers did. But your code quality would be guaranteed to be better if you changed some of these defaults to match your coding standards.

Please examine these suboptions and turn on those (such as NOLAXDCL) that will help you.

And if you have a coding standard that these suboptions do not check, please submit a requirement for it so that we can add it in a future release.

There are three, perhaps overlooked, new features of Enterprise that let you "compile out" code either unconditionally or conditionally:

To cause the compiler to skip some code unconditionally, you could try to enclose it in comments. But this works only if that code itself contains no comments. However, as of the 3.9 release, you can enclose code in %DO SKIP; ... %END;, and then the compiler will unconditionally skip over the enclosed code.

To cause the compiler to skip over some code conditionally, you can enclose it in a %DO; ... %END; block that is conditional on the value of the SYSPARM compiler option. For example, this code

would be compiled into your object deck only if you specified SYSPARM('test') as a compiler option. Using this option in this manner makes it easy to compile a production or a test version of your code from the same source file.

And if all your test code consists only of PUT FILE statements - and if PUT FILES are not used elsewhere in your code, you could cause the compiler to skip over that code conditionally by using the IGNORE( PUT ) compiler option introduced in the 4.1 release.

There are many good things about the new PLI for AIX 3.1 release, but the biggest is that PL/I for AIX is now fully up-to-date: it had been stuck at its last release in 2004, but it now has all the language features added to Enterprise PL/I (and PL/I for Windows) in the years since then.

Recent blog entries point to documents with all the details of what's in the 3.1 release, but in brief, PL/I for AIX, Enterprise PL/I, and PL/I for Windows

support the same compiler options

accept the same syntax (and generate the same messages for incorrect programs)

support the same built-in functions

contain the same performance enhancements (when not tied to the platform)

The history of PL/I stretches back to the 1970s when IBM, at the prompting of the SHARE user group, delivered the first PL/I compiler so that users would have a language with the combined strengths of Fortran and COBOL. IBM then delivered three releases of OS PL/I Version 2 in the 1980s and PL/I for MVS and VM in the early 1990s. All of these releases were based on a common code base that gradually became old, plus both hard and expensive to enhance and maintain.

However, with the advent of the PC, IBM built a completely new PL/I compiler that was shipped first on IBM® Operating System/2® (OS/2) and then ported to Microsoft Windows, the IBM® AIX® operating system, and the mainframe. With this compiler and the 12 consecutive years with a new release of the IBM® z/OS® version, IBM has improved optimization of PL/I programs, enhanced their exploitation of IBM® System z® architecture, addressed many customer requirements, and introduced numerous application modernization features.

IBM continues to have a strong commitment to the PL/I language, particularly given its widespread use in many business-critical applications. The current family of IBM PL/I implementations consists of the Enterprise PL/I compiler for the mainframe and the PL/I for AIX compiler, both of which share a common, nearly identical front-end code base, which ensures portability between those platforms.

We are opening this forum to create more direct communication between users of our PL/I compilers and the IBM compiler development organization. We hope you'll find the content informative and interesting, and we look forward to your contributions through questions, comments, and ideas.

Do you want to prove the depth of your PL/I knowledge to a prospective employer? Or do you want to verify the PL/I skills of a company to whom you might outsource your PL/I code?

The PL/I certification, developed jointly by IBM and representatives from PL/I companies from Europe and the US, can help with these and similar tasks.

At the IBM PL/I professional certification site you will find that there are two certification levels for PL/I: one for the general PL/I programmer in your team and a harder test for the leader of that PL/I team.

Check it out.