Joined: 26 Nov 2002 Posts: 12382 Topics: 75 Location: San Jose
Posted: Wed Mar 24, 2004 5:00 am Post subject:
Endal,
Please follow the forum rules. Avoid putting "urgent" or "urgently" in your topics. Here are some of the performance tuning tips for PLI.
1) Data Conversion, review your compiler listings for IEL906I messages. Verify if you really need to convert the data from one data type to another, this action is really expensive. Also consider using PL/I PIC varibles instead of CHAR variables when dealing with character numbers.
2) Consider using the PLIXOPT variable to pass PLI/I run time data (ISASIZE...) . Not sure if this saves any time, but it's good programming practice.
3) Use ISASIZE , HEAP and ISAINC run time options to correctly configure the amount of storage that your program will use. The default values cause PL/I to use 1/2 of the available memory in the address space, which will cause the program to wait for MVS to get the storage, also under heavy system loads your program maybe targeted to be swapped out (wait a long time) due to its heavy memory size. You can use the PL/I REPORT option to correctly calculate the ISASIZE. Read on for more information on ISASIZE.
4) When creating array structures you should code them as:
Code:
DCL 1 RECORD
3 NAME(3000) CHAR(100)
3 NUMBER(3000) BIN FIXED(15)
Usually NAME(X) and NUMBER(X) will be on the same storage PAGE in memory, thus no additional paging required.
Versus
Code:
DCL 1 RECORD(3000)
3 NAME CHAR(100)
3 NUMBER BIN FIXED(15)
In this case NAME(X) and NUMBER(X) will be on different storage pages, if there is a memory problem then you can expect a page in to occur much more frequently, thus your program will take longer to run. In fact in really bad environments it could talk minutes/hours for your program to run.
5) Global Optimization, IEL 0919I message. Pl/I variable optimization is only done only done on the first 255 variables, To ensure that optimization is done on the more frequently used variables you should declare them in the last declare block in the main line program. Only arithmetic variables versus character variables are optimized.
6) Use the REORDER option on the outermost PROC statement. This option permits the optimizing compiler to move invariant expressions out of loop, use machine registers to hold values, and optimize subscript calculations. One word of warning, you may need to understand the effects of this option if you attempt error recovery and change variables in an ON block since the variable could be in a register versus memory.
7) Setting of variables in ON blocks inhibits common expression elimination, optimization, and register usage. Try not to do it. In fact the PL/I manual states that the usage of ON blocks should be avoid, try to check for errors before doing the condition that will cause the error.
8 ) Use of ON STRINGSIZE and STRINGRANGE can inhibit optimization, and cause an extra subroutine calls when you use SUBSTR.
9) A DO WHILE block will inhibit optimization of invariant expressions. A DO UNTIL is OK. (Minor issue in my opinion unless you write crummy code).
10) When assign data between identical structures use a straight assignment versus assignment BY NAME.
11) If you are dealing with CHARACTER NUMBERS, use PIC DECLARES versus CHAR. This will save an additional conversion process when converting to DECIMAL or FIXED.
12) Use BIN FIXED for FLAGS instead of BIT. Use of BIT variables require more instruction to be generated just to check its state. Using a BIN FIXED and setting it to 0 or 1 is much more efficient.
13) When working with Arrays consider the use of ARRAY arithmetic versus a DO LOOP structure.
Code:
DCL A(10) BIN FIXED,
B(10) BIN FIXED,
I BIN FIXED;
USE DO I = 1 to 10;
A=B; VERSUS A(I) = B(I);
END;
The PL/I compiler can generate much better code for you.
14) When using INDEX, TRANSLATE, VERIFY subroutines, try to code the second argument as a constant.
15) When using TRANSLATE,and VERIFY subroutines, try to code the first argument as fixed length variable versus a variable length variable.
16) Consider using BUFNO (in JCL) for sequential FILES.
17) CODE one OPEN or CLOSE statement versus multiple ones.
18 ) Use of PUT SKIP EDIT((A(I) DO I =1 to 100)(f(6)); is more efficient than coding a DO loop.
Joined: 02 Dec 2002 Posts: 429 Topics: 18 Location: Germany
Posted: Thu Mar 25, 2004 1:40 am Post subject:
There is a lot of tuning that can be done for Vsam datasets (minimize CA splits), for CICS (are you using LSRPOOLs ? are you using 31 bit (above the line) for your transactions/programs). But probably the biggest hog of CPU is just inefficient programming and poor design, also users that do not know what they are doing and waste countless browses through data.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
