Enterprise PL/I V3R7

Enterprise PL/I V3R7

Slides have been copied from Peter Elderon presentation held at SHARE – February 2008 (Session 8212)

Link to presentation: http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_Orlando/S8212XX075453.pdf

Stephen RamaiBank Of [email protected]

Debugging Enhancements

The SOURCE view• With Enterprise PL/I, under Debug Tool you see the source as it was when fed

to the compiler

• But you may want to see the source after it has been processed by the MACRO preprocessor or by the CICS or SQL preprocessors – or after all of them

• These new suboptions of the TEST option allow you to do that:

• SOURCE• AFTERMACRO• AFTERCICS• AFTERSQL• AFTERALL

The SOURCE view• These suboptions are ignored unless TEST(SEPARATE) is also specified – but

then, the listing, Debug Tool and runtime error messages will all be affected:

• For example, under TEST(SEP,AFTERMACRO) the source listing will show the source as if it came from the MDECK from the last invocation, if any, of the MACRO preprocessor

• Debug Tool will also show this as the source view

• Any runtime error messages will use numbers that will match this same (after- MACRO-) source view

• SOURCE is, of course, the default suboption

Performance Enhancements

BASR• The BASR instruction will now be used instead of the BALR instruction

• This is a small improvement

• But it could affect a listing scanner:

• (Almost) all the O5EF will now be 0DEF

Data Type Conversions

• There are some data type conversions which have been improved by reducing the number of library calls, utilizing more inline coding techniques. ie: new instructions ect…

• Examples:

• FIXED BIN to FIXED DEC conversions now uses call free code.

• FIXED DEC to FLOAT conversions with large precision to FLOAT will be inlined and speeded up by the use of FIXED BIN(63) as an intermediary.

• PICTURE to WIDECHAR conversions uses instructions PKA, UNPKU, and MVCLU for a shorter inline code.

• CHAR to CHAR conversions using CHAR built-in will now always be inlined. Applying the CHAR built-in to a CHAR expression seems unnecessary, but is sometimes done (and sometime by code generated by macros etc).

FIXED BIN to FIXED DEC conversion example

• The code generated for conversions of FIXED BIN(p,q) to unscaled FIXED DEC has been significantly improved

• So, for example, given the simple program

test: proc( d, n );

dcl n fixed bin(31,16);dcl d fixed dec(05);

d = n; end;

• And this is less uncommon than might be imagined – since a FIXED BIN(31,16) source would also be produced by the divide of two FIXED BIN(15) variables

FIXED BIN to FIXED DEC conversions

• Under V3R6, this lengthy code with a library call would have been generated

58F0 1004 L r15,_addrN(,r1,4)C0E0 0000 0046 LARL r14,F'70'4100 D0B8 LA r0,#wtemp_1(,r13,184)4190 D0C0 LA r9,#wtemp_2(,r13,192)58F0 F000 L r15,_shadow2(,r15,0)4EF0 D0D8 CVD r15,#pd519_1(,r13,216)4140 D0C8 LA r4,#wtemp_3(,r13,200)4150 0018 LA r5,24A768 FFF0 LHI r6,H'-16'4170 000B LA r7,114180 000D LA r8,135820 1000 L r2,_addrD(,r1,0)D205 D0E0 D0DA MVC #pd520_1(6,r13,224),#pd519_1(r13,218)D206 D0B8 E000 MVC #wtemp_1(7,r13,184),+CONSTANT_AREA(r14,0)D205 D0C0 D0E0 MVC #wtemp_2(6,r13,192),#pd520_1(r13,224)58F0 3000 L r15,=V(@@PMPY)(,r3,0)4110 D098 LA r1,#MX_TEMP1(,r13,152)5040 D098 ST r4,#MX_TEMP1(,r13,152)5050 D09C ST r5,#MX_TEMP1(,r13,156)5060 D0A0 ST r6,#MX_TEMP1(,r13,160)5090 D0A4 ST r9,#MX_TEMP1(,r13,164)5070 D0A8 ST r7,#MX_TEMP1(,r13,168)5000 D0AC ST r0,#MX_TEMP1(,r13,172)5080 D0B0 ST r8,#MX_TEMP1(,r13,176)05EF BALR r14,r15F82F D0E8 D0C8 ZAP #pd526_1(3,r13,232),#wtemp_3(16,r13,200)D202 2000 D0E8 MVC _shadow1(3,r2,0),#pd526_1(r13,232)

FIXED BIN to FIXED DEC conversions

• But under V3R7, this shorter, call-free code would be generated

58E0 1004 L r14,_addrN(,r1,4)5810 1000 L r1,_addrD(,r1,0)5800 E000 L r0,_shadow2(,r14,0)8A00 001F SRA r0,318800 0010 SRL r0,165E00 E000 AL r0,_shadow2(,r14,0)8A00 0010 SRA r0,164E00 D098 CVD r0,#pd532_1(,r13,152)D205 D0A0 D09A MVC #pd533_1(6,r13,160),#pd532_1(r13,154)F825 D0A8 D0A0 ZAP #pd534_1(3,r13,168),#pd533_1(6,r13,160)D202 1000 D0A8 MVC _shadow1(3,r1,0),#pd534_1(r13,168)

Better SEARCHR and VERIFYR

• SEARCHR and VERFIYR will now use the TRTR instruction

• In the same situations where SEARCH and VERFIFY use TRT

The compiler itself• The compiler performance is essentially the same as V3R5/V3R6

• However, as with V3R6, the compiler requires ARCH(5) machines. The front-and back-ends are compiled using ARCH(5)

• This is a trend you will see continuing

• Note also that as of April 2007, all LE releases in service also require ARCH(5) machines

Usability Enhancements

Codepage conversion• The new MEMCONVERT built-in function will allow you to convert arbitrary

lengths of data between arbitrary code pages • MEMCONVERT converts the data in a source buffer from the specified

source codepage to a specified target codepage, stores the result in a target buffer, and returns an unscaled REAL FIXED BINARY value specifying the number of bytes written to the target buffer.

• MEMCONVERT has 6 parameters • The target buffer address • The target buffer length • The target code page • The source buffer address • The source buffer length • The source code page

Codepage conversion• The buffer lengths must have computational type and will be

converted to FIXED BINARY(31,0). • The buffer lengths must be nonnegative.

• If either buffer length is zero, the result is zero. • The code pages must have computational type and will be

converted to FIXED BINARY(31,0).

• The code pages must specify valid, supported code pages. • The library routine involved has a storage leak: apply the PTF for

APAR PK59297

Better XML support

• The new XML option controls the case of the tags in the output of the XMLCHAR built-in function

• In particular, the CASE suboption determines the case of these tags

• Under the default CASE(UPPER) suboption, all tags will

be in upper case (as they were in all previous releases) • Under the CASE(ASIS) suboption, all tags will be in the

case which the associated variable was declared

Better XML support• So, for example, given

dcl

1 AA, 2 bb char(10) var init('cauchy'), 2 CC char(10) var init('schwarz'), 2 dd char(10) var init('jensen');

dcl xbuffer char(70); dcl bytes fixed bin(31);

bytes = xmlchar( a, addrdata(xbuffer), maxlength(xbuffer) );

• By default, bytes would be equal to 55 and xbuffer would contain <AA><BB>cauchy</BB><CC>schwarz</CC><DD>jensen</DD></AA>

• But under XML(CASE(ASIS)), it would contain <AA><bb>cauchy</bb><CC>schwarz</CC><dd>jensen</dd></AA>

User requirement (a)

• The new ONOFFSET built-in function returns the offset in the user procedure at which a condition was raised

• Gives you easy access to a piece of information formerly available only in the runtime error message or dump

• Like ONCODE, ONSOURCE etc, the ONOFFSET built-in function is valid

only in ON-units (or procedures called from ON-units)

User requirement (a)• This is the “entry offset” in the runtime message

IBM0482S ONCODE=310 The FIXEDOVERFLOW condition was raised.

From entry point NOSIZE at compile unit offset +0000016A at entry offset +0000016A at address 0BC00E22.

• And in the LE traceback

Traceback:

DSA Entry E Offset Statement Load Mod

1 CEEHDSP +00004A86 CEEPLPKA 2 NOSIZE +0000016A GO 3 IBMPMINV +000004DE IBMPEV11 4 CEEEV011 +00000202 IBMPEV11 5 CEEBBEXT +000001B6 CEEPLPKA

• So now you could put this offset (which can be correlated to a statement number via the output from the OFFSET option) into your own log file, etc

User requirement (b)• For compilations that produce no messages, the compiler will now include a line

saying "no compiler messages" where the compiler messages would have been listed

• This allows you to search for the string “compiler messages” and always get to the “bottom” of the listing

User requirement (c)

• The new MAXNEST option controls when the compiler will flag excessive nesting of BEGIN, DO, IF and PROC statements.

• The option has 3 suboptions: BLOCK, DO and IF, each of which has a value that is the limit for nesting of the corresponding statements (BLOCK covers both BEGIN and PROC) before the compiler issues a message flagging their nesting as excessive

• The nesting limit must be between 1 and 50 (inclusive)

• The default is MAXNEST( BLOCK(17) DO(17) IF(17) )

User requirement (d)• The RULES option will now accept ELSEIF and NOELSEIF as suboptions

• Under RULES(NOELSEIF), the compiler will flag any ELSE statement that is immediately followed by an IF statement and suggest that it be rewritten as a SELECT statement

• ELSEIF is the default (for compatibility with previous releases)

User requirement (d)• So, for example, given

if a = 0 then do; end; else if b = 0 then do; end; else do; end;

• RULES(NOELSEIF) would encourage you to rewrite it as

select;

when( a = 0 ) do; end;

when( b = 0 ) do; end;

otherwise do; end; end;

User requirement (e)• The MACRO preprocessor will support a new suboption that will allow the user to

specify whether it should process only %INCLUDE statements or whether it should process all macro statements

• Under the default suboption of NOINCONLY, the MACRO preprocessor will process all macro statements (as it did in past releases)

• Under the suboption of INCONLY, the MACRO preprocessor will process only %INCLUDE and %XINCLUDE statements

• PP(MACRO(INCONLY)) is like the old compiler’s INCLUDE option

User requirement (f)• The RULES option will now accept LAXSTG and NOLAXSTG as suboptions

• Under RULES(NOLAXSTG), the compiler will flag declares where a variable A is declared as BASED on ADDR(B) and STG(A) > STG(B) even (and this is the key part) if B is a parameter

• LAXSTG is the default (for compatibility with previous releases)

User requirement (f)• So, for example, given

test: proc( a );

dcl a char(1);

dcl b char(100) based(addr(a));

b = '';

end;

• The compiler will now issue message IBM2402 flagging these declares – but only under the option RULES(NOLAXSTG)

• The compiler doesn’t flag this unconditionally because too many customers have declares such as the above where A is simply a placeholder – although this is very poor coding practice

Changed options• The ARCH option will still accept values less than 5, but any such value will be reset

to 5 (since all the supported runtime releases require at least this level)

• And the same applies to TUNE

• FIRST is now the default for the CEESTART option

Changes to the listings• The length of the mnemonic field in the assembler listing will be increased to allow for

better support of the new z/OS instructions that have long mnemonics

• More of the right margin will be used in the attributes, cross-reference and message listings

New Messages

Poor ON ERROR• The compiler will now flag ON ERROR blocks not starting with ON

ERROR SYSTEM;

• So, for example, given

on error begin;

call plidump; put skip data;

end;

• The compiler will now issue message

• IBM2621I W ON ERROR block does not start with ON ERROR SYSTEM. An error inside the block may lead to an infinite loop.

CLOSE in ENDFILE• The compiler will now flag a CLOSE statement for a file if that statement occurs in an

ON-block ENDFILE for that file

• So, for example, given

on endfile(f) begin; display( 'endfile for f' ); close file(f);

end; • The compiler will now issue message

IBM2421I E A file should not be closed in its ENDFILE block.

Poor TRANSLATE and VERIFY• The compiler will now flag the use of AUTO (and STATIC) variables as tables in TRANSLATE and VERIFY (since

this can lead to poor performance)

• So, for example, given

test: proc( c );

dcl c char(20);

dcl upper char(26) static init('ABCDEFGHIJKLMNOPQRSTUVWXYZ');

dcl lower char(26) static init('abcdefghijklmnopqrstuvwxyz');

c = translate( c, upper, lower ); end;

• The compiler will now issue message

IBM2812I I Argument number 2 to TRANSLATE built-in would lead to much better code if declared with the VALUE attribute.

Poor DO loops• The compiler will now flag the use of a function to set the initial value in a DO loop (since this can

lead to unexpected results) • So, for example, given

dcl jx fixed bin; dcl last fixed bin init(10);

do jx = f() to last; display( jx );

end;

f: proc returns( fixed bin ); last = 4; return( 2 );

end; • The compiler will now issue message

IBM2622I W ENTRY used to set the initial value in a DO loop will be invoked after any TO or BY values are set.

Poor choices for BYVALUE • BYVALUE parameters should be small (integers, floats, pointers, etc), and the

compiler will now flag the use of the BYVALUE attribute with “large” parameters

• So, for example, given

test: proc( c ) options(nodescriptor);

dcl c char(33) byvalue; end;

• The compiler will now issue message

IBM2628I W BYVALUE parameters should ideally be no larger than 32 bytes

%DCL with no attributes• The compiler will now flag any %DECLARE that does specify any

attributes, thus leading to easier detection such as the extraneous comma in this statement

"%DCL A, CHAR, B FIXED;“

So, for example, given

test: proc; %dcl x;

end;

• The compiler will now issue message

IBM3325I W No data attributes specified in declare for X.

SUBSTR with zero length

• The compiler will now flag any SUBSTR reference where the third argument is zero since while technically valid, this is almost certainly a coding error.

• So, for example, given

test: proc( c ) options(nodescriptor);

dcl c char(33) byaddr;

display( substr(c,4,0) ); end;

• The compiler will now issue message

IBM2626I W Use of SUBSTR with a third argument equal to 0 is somewhat pointless since the result will always be a null string.

Scale factors in float declares• The compiler will now flag the specification of a scale factor in a

FLOAT declaration since this is invalid and may point to a typo in the source ( for example, where FLOAT was typed but FIXED was meant)

• So, for example, given

test: proc( x ); dcl x float dec(15,3);

end; • The compiler will now issue message

IBM2424I E Scale factors are not allowed in FLOAT declarations.

NOT operator applied to non-bit• The compiler will now flag any bit prefix operand that does not have the BIT attribute

(as it already did for bit infix operands)

• So, for example, given

test: proc( x, y );

dcl (x,y) fixed bin;

if x = !y then call plidump;

end;

• The compiler will now issue message

IBM1206I W BIT operators should be applied only to BIT operands.

Duplicate WHEN values• The compiler will now scan for duplicate WHEN values in SELECT statements even if

a string literal is specified as a WHEN value

• Formerly, if the compiler found that the WHEN values were string literals, it would stop scanning for duplicates as soon as it found a string literal that was not a CHAR(1)

• So, the compiler will now flag, for example,

select (c); when ('', 'b', 'c', 'd') put skip list('1'); when ('', 'b') put skip list('2'); other put data(c);

end;

Decimal Floating Point (DFP)

DFP option• Nothing has changed unless you use the new DFP suboption of the FLOAT compiler

option

• The default is FLOAT( NODFP )

• And nothings works without ARCH(7) and LE 1.9

• The compiler will object to FLOAT(DFP) with ARCH(6) (or less)

FLOAT Decimal problems

• Consider this small program fragment:

DCL TXRM_F5V2 FIXED (5,2); DCL TXRM_FL FLOAT DEC(16); DCL TXRM_PIC PIC'999V99';

PUT SKIP LIST('ESSAI AVEC 3,50 %'); TXRM_F5V2 = 3.50; TXRM_FL = TXRM_F5V2; TXRM_PIC = TXRM_FL; PUT SKIP DATA(TXRM_F5V2,TXRM_FL,TXRM_PIC);

• It produces the expected output

ESSAI AVEC 3,50 % TXRM_F5V2= 3.50; TXRM_FL= 3.500000000000000E+00; TXRM_PIC=00350;

FLOAT DECIMAL problems• But change the input value:

DCL TXRM_F5V2 FIXED (5,2); DCL TXRM_FL FLOAT DEC(16); DCL TXRM_PIC PIC'999V99';

PUT SKIP LIST('ESSAI AVEC 3,60 %'); TXRM_F5V2 = 3.60; TXRM_FL = TXRM_F5V2; TXRM_PIC = TXRM_FL; PUT SKIP DATA(TXRM_F5V2,TXRM_FL,TXRM_PIC);

• It produces the unexpected output

ESSAI AVEC 3,60 % TXRM_F5V2= 3.60; TXRM_FL= 3.600000000000000E+00; TXRM_PIC=00359;

FLOAT DECIMAL problems• Or consider this small program fragment:

dcl f1 float dec(6); dcl f2 fixed dec(5,3); dcl f3 float dec(6);

f1 = 4; f2 = f1 / 100e0; put skip data( f2 ); f3 = 100 * f2; put skip data( f3 );

• It produces the disconcerting result that 100*(4/100) = 3.9

F2= 0.039; F3= 3.90000E+00;

Decimal Floating Point• The new DFP instructions and hardware will remedy this

• There is a new chapter in the z/OS Principle of Operations • You can download this from

http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/r9pdf/zarchpops.html Or, perhaps more simply, go to the useful page

http://www-03.ibm.com/servers/eserver/zseries/zos/

• Then click on “library” (on the right) and then click on V1.9 under “z/OS elements and

features publications”

Decimal Floating Point• If you look at the z/OS Principles of Operations, you will see 3

chapters with titles:

• Hexadecimal-floating-point instructions • Binary-floating-point instructions • Decimal-floating-point instructions

• The first is the only kind supported by OS PL/I and PL/I for MVS

• The second is supported by Enterprise PL/I under the compiler option DEFAULT( IEEE )

• The third is now also supported by Enterprise PL/I

Floating Point• All 3 have short, long and extended forms

• All use the base ( 16, 2, 10 ) implied by their name

• All have a sign bit, an exponent and a mantissa

• For Avogadro’s number 6.02214199E23 • Its exponent is 23 • Its mantissa is 6.02214199

• But the actual format in which these are held as well as the range of values (including

possibly special values such as infinity) vary widely

DFP option• To repeat: • Nothing has changed unless you use the new DFP suboption of the FLOAT compiler

option

• The default is FLOAT( NODFP )

• And nothings works without ARCH(7) and LE 1.9

• The compiler will object to FLOAT(DFP) with ARCH(6) (or less)

Thank You !

Questions?