Webcast - Feb 15th Boost performance, productivity and cost savings with IBM’s latest compilers for zEnterprise
Join our experts, Ray Jones, Vice President, IBM System z® Software, and Kevin Stoodley, IBM Fellow and CTO for Enterprise Modernization Tools, Compilers and Security, to learn how IBM’s latest compilers, middleware and tools can help you stay on the technology curve. In this complimentary webcast, Ray and Kevin will discuss best practices and approaches to plan and execute a successful compiler migration, alongside CICS®, IMS™ and DB2® upgrades. They will also go over IBM’s strategy for compilers and tools on System z to help you better plan your overall development and upgrade efforts.
Register online right now
Register now for this webcast by logging onto
Join us after the webcast for a live question-and-answer session. The webcast will also be available for replay after the event.
bbalk 1200006543 6,380 Views
One of the new options introduced in the new 4.2 release of Enterprise PL/I is the UNROLL option. However, to understand it, you first need to understand what the compiler does with loops.
Usually, the compiler turns a DO loop into a sequence of instructions which is followed by a test and then a conditional branch back to repeat those instructions with some updated values (and the sequence of instructions may be preceded by a conditional test to see if the loop should be run at all).
In some situations, the optimizer can make this generated code run faster by "unrolling" the loop. This means that instead of generating the instructions described above, the optimizer will eliminate the conditional branches (which are relatively expensive) and instead duplicate the loop body with the updated values (or it may do some of both).
The UNROLL option lets you control this. For example, given this code
dcl a(10) fixed bin(31) connected;
dcl jx fixed bin(31);
dcl sum fixed bin(31);
sum = 0;
do jx = 1 to 10;
sum += a(jx);end;
Under UNROLL(NO), the compiler will not unroll the loop, and the code generated would look like
But under UNROLL(AUTO), it would generate the longer, but faster
This is a very simple example, and the code under the default setting of UNROLL(AUTO) is probably better.
But note that even here the unrolled code is larger (if only by a bit). If the code needed inside the loop were bigger, unrolling the loop could significantly increase the object deck size.
There is no one correct setting for this option. You will have to decide what is best for your code: do you want the optimizer to decide which loops to unroll (that's what the default setting does and what all the previous releases did) or do you want to turn off all loop unrolling?
FREE newsletter - get IBM Software news, special #PowerSystems features - subscribe:
Check out all the information about the latest release of Enterprise PL/I for z/OS. You can get a summary of the release as well as all the announcement details.
bbalk 1200006543 6,933 Views
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
dcl old_name char( 100 );
dcl new_name char( length(old_name) );
or, perhaps better,
dcl name_size fixed bin(31) value( 100 );
dcl old_name char( name_size );
dcl new_name char( name_size );
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
dcl big_name char( 4*name_size );
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
dcl name_size fixed bin(31) value( 100 );
dcl max_names fixed bin(31) value( 200 );
dcl old_name( max_names ) char( name_size );
dcl new_name( max_names ) char( name_size );
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
dcl new_name( max_names ) char( name_size ) init( 'unknown', (199) ( '' ) );
but it would be better to let the compiler do the math and to write
dcl new_name( max_names ) char( name_size ) init( 'unknown', (max_names-1) ( '' ) );
and perhaps best of all would be the even simpler and sleeker
dcl new_name( max_names ) char( name_size ) init( 'unknown', (*) ( '' ) );
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.
bbalk 1200006543 5,646 Views
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:
You can change the defaults for the RULES compiler option to detect a wide variety of poor coding practices.
Declaring all variables is usually required in all professional code, but by default, the compiler issues only an information message for undeclared variables (which means the compilation, if it had no other problems, would end with a return code of 0).
However, under the RULES(NOLAXDCL) option, the compiler will flag all undeclared variables with an error message that would cause the compile to end with a return code of 8 at least.
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.
bbalk 1200006543 7,089 Views
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
including all the RULES suboptions to enforce code quality
accept the same syntax (and generate the same messages for incorrect programs)
including the INONLY, INOUT, and OUTONLY attributes for parameters
support the same built-in functions
including all the powerful UTF string-handling functions
contain the same performance enhancements (when not tied to the platform)
including all the inline mapping of structures with multiple REFER
Check out all the information about the latest release of PL/I for AIX. You can get a summary of the release as well as all the announcement details.
See what's new with PL/I for AIX V3.1 including enhancements to leverage the latest POWER7 hardware and interoperability with the latest middleware.
For all the details about the PL/I for AIX, V3.1 announcement, see IBM PL/I for AIX , V3.1 delivers support for the latest IBM POWER7 Systems architecture as well as many functional improvements and usability enhancements.
COBOL_Cafe 2700024MQ5 6,856 Views
Want to experience PL/I for AIX, productive and powerful development environment for building PL/I applications.
Check out these features in PL/I for AIX, V3.1:
Download a 60-day evaluation of PL/I for AIX, V3.1 today.
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.