490 likes | 682 Views
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 Ramai Bank Of Montreal
E N D
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 Ramai Bank Of Montreal Stephen.Ramai@bmo.com
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
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,24 A768 FFF0 LHI r6,H'-16' 4170 000B LA r7,11 4180 000D LA r8,13 5820 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,r15 F82F 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,31 8800 0010 SRL r0,16 5E00 E000 AL r0,_shadow2(,r14,0) 8A00 0010 SRA r0,16 4E00 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
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
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;
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?