Enterprise PL/I for z/OS has consistently delivered innovations to help developers maintain and create applications optimized for deployment on IBM System z servers. Like COBOL, PL/I also focuses on delivering new features to improve performance, productivity, and modernization of proven, business critical applications. IBM has delivered a new release of the PL/I compiler every year since 1999 on System z. The announcement of Enterprise PL/I for z/OS V4.4 has kept this streak alive and reaffirms IBM's commitment to PL/I on System z.
Enterprise PL/I for z/OS V4.4 fully exploits System z architecture, including the latest zEC12 and zBC12 servers. It also supports the new z/OS V2.1 operation environment. With this latest release, you can take advantage of new optimization features to improve application performance and reduce operating cost. You will also notice a 4X improvement in listing generation time, and improved program diagnostics, especially for programs that work with SQL. If you are an IMS user, you will be able to take advantage of new features to improve performance (e.g. Sparse arrays, XML cleaning and normalization; base 64 encoding and decoding). The size of the IMS convertor has also been significantly reduced, allowing more convertors to run in the same addressing space.
Enterprise PL/I for z/OS V4.4 is scheduled to GA on Sept. 6, 2013. For more information, visit http://www-03.ibm.com/software/products/us/en/plizos
At times, it is useful to be able to tailor the compiler to meet the needs of your organization. For example, you might want to suppress certain messages or alter the severity of others. You might want to perform a specific function with each compilation, such as logging statistical information about the compilation into a file.
A compiler user exit handles this type of functions. With PL/I, you can write your own user exit or use the exit provided with the product, either 'as is' or slightly modified depending on what you want to do with it.
IBM supplies you with the sample compiler user exit, IBMUEXIT, which filters messages for you. It monitors messages and, based on the message number that you specify, suppresses the message or changes the severity of the message.
There are several files that comprise IBMUEXIT:
Contains the PL/I source code.
Executable load module for IBMUEXIT.PLI that can be FETCHed. In order to build this file, issue the following commands from the AIX command line:
pli -e ibmuexit
Control file that specifies filtering of messages.
The PLI source file is provided for your information and modification. The INF control file contains the message numbers that should be monitored, and tells IBMUEXIT what actions to take for them. The executable module reads the INF control file, and either ignores the message or changes its severity.
Author: Carol Hu
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
See what's new with Enterprise PL/I for z/OS, V4.3 including enhancements to
leverage the latest z/OS. For all the details about the Enterprise
PL/I for z/OS, V4.3 announcement, see IBM Enterprise PL/I for z/OS V4.3 delivers performance improvements and usability enhancements. (Author: Stella Zhou, Carol Hu)
Interested in finding
out what PL/I support is available for the latest IBM zEnterprise® EC12
I recommend the following article published in IBMSystems magazine's latest
Mainframe Extra eNewsletter:
Hope you'll find it useful.
PL/I Compilers are now live on the Request for Enhancement (RFE)
Community. It is a great place where you can collaborate with
development teams and other product users. Our development team will
review your RFE and provide status updates throughout its lifecycle.
Here is links to the Community : PL/I RFE
Looking forward to hearing from you.
Check out this demo showing how to code PL/I to interface with AIX. Using the Power systems sandbox, you can try PL/I for AIX and create a network application in PL/I.
In the previous blog entry we showed how Character Large Objects (CLOBs)
can be manipulated with LOB locators. In this blog we will discuss
the use of LOB file references.
LOB file reference variables are also very useful when working with
LOBs. The are used to import or export data between a LOB column and
an external file outside the DB2 system.
The benefits of using LOB file reference variables are that they:
- use less CPU time than moving LOB data with a host variable
because the movement of the data would not be overlapped with
any DB2 processing or network transfer time.
- use less application storage because the LOB data is moved
directly from DB2 to a file and is not materialized in the
The pliclob sample program uses LOB file references to
create a new, trimmed down version of the resume in an external file.
In the pliclob sample program the host variable hv_clob_file is
declared as a LOB file reference.
The file name field of the LOB file reference is set to the fully
qualified file name and the file name length is set to its length.
For this example the 'overwrite' flag is set so any existing file
will be overwritten. These and other options are described fully
in the DB2 publication 'Application programming for SQL'.
Next the SQL VALUES statement is used to concatenate the resume name
and work history sections of the resume directly into the LOB file
You can see this in the following code sample, extracted from the
pliclob sample program.
dcl hv_clob_file sql type is clob_file;
name_string = '/SYSTEM/tmp/pliclob2.txt';
hv_clob_file.sql_lob_file_name_len = length(name_string);
hv_clob_file.sql_lob_file_name = name_string;
hv_clob_file.sql_lob_file_options = ior(sql_file_overwrite);
values ( substr(:hv_loc_resume,:start_resume,
Now go and have some LOB fun yourself!
To see all of these techniques in context, please
refer to the pliclob sample program.
This blog entry is the first of two articles that will provide some guidance on how to work
with DB2 large objects (LOBs) in PL/I. They both refer to the 'pliclob.pli' file in the PL/I Cafe 'Files'
section for samples of actual code.
One way to use LOB data from a DB2 table is to declare a host variable
large enough to hold all of the LOB data. This requires your program to
allocate large amounts of storage and requires DB2 to move large amounts
of data. This can be inefficient or impractical.
Or you can use LOB locators and LOB file references to manipulate the data
while it still resides in the data base.
LOB Locators are used to avoid materialization of the LOB data and all
the underlying requirements associated with it.
The benefits of using LOB locators are:
- saving storage when manipulating LOBs with LOB locators
- manipulating data without retrieving it from the data base
- avoiding the use of large amounts of storage to hold the LOB
- avoiding the time and resource expenditures for moving large
pieces of data thereby improving performance.
LOB locators are especially useful:
- when you only need a small part of a LOB
- when you don't have enough memory for the entire LOB
- when performance is important
- in a client/server environment to avoid moving data over the
network from one system to another
Look at the pliclob sample program in the 'Files' section of the
PL/I Cafe for some ideas on how to manipulate CLOBs in a PL/I and
For example, the pliclob sample program uses LOB locators to identify
and manipulate sections of the character large object (CLOB) resume
found in the DB2 V10 table dsn8a10.emp_photo_resume.
In the following code sample, extracted from the pliclob sample program,
the LOB locator 'hv_loc_resume' is set to the location of the resume of
the employee number 'hv_empno' in the emp_photo_resume table. Next the
start_resume host variable is set to the beginning of the 'Resume:'
section of the resume.
dcl hv_loc_resume sql type is clob_locator;
select resume into :hv_loc_resume
where empno = :hv_empno;
set :start_resume = (posstr(:hv_loc_resume, 'Resume:'));
From here it is possible to start manipulating the resume data while
the resume is still resident in the data base. For greater detail,
refer to the pliclob sample program.
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.
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).
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);
, the compiler will not unroll the loop, and the code generated would look like
000046 5810 1000 L r1,_addrA(,r1,0)
00004A 41F0 0000 LA r15,0
00004E 41E0 0004 LA r14,4
000052 4100 000A LA r0,10
000056 A71A FFFC AHI r1,H'-4'
00005A @1L2 DS 0H
00005A 5EFE 1000 AL r15,_shadow1(r14,r1,0)
00005E 41E0 E004 LA r14,#AMNESIA(,r14,4)
000062 A706 FFFC BRCT r0,@1L2
But under UNROLL(AUTO)
, it would generate the longer, but faster
000046 5810 1000 L r1,_addrA(,r1,0)
00004A 58F0 1000 L r15,_shadow1(,r1,0)
00004E 5EF0 1004 AL r15,_shadow1(,r1,4)
000052 5EF0 1008 AL r15,_shadow1(,r1,8)
000056 5EF0 100C AL r15,_shadow1(,r1,12)
00005A 5EF0 1010 AL r15,_shadow1(,r1,16)
00005E 5EF0 1014 AL r15,_shadow1(,r1,20)
000062 5EF0 1018 AL r15,_shadow1(,r1,24)
000066 5EF0 101C AL r15,_shadow1(,r1,28)
00006A 5EF0 1020 AL r15,_shadow1(,r1,32)
00006E 5EF0 1024 AL r15,_shadow1(,r1,36)
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: http://bit.ly/rs1rZn #POWER7
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.
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
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.
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.
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;
is conditional on the value of the SYSPARM
compiler option. For example, this code
%if sysparm = 'test' %then %do;
put skip list( procname() || sourceline() );
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.