Enterprise COBOL Education Using Rational Developer for System Z Performance Optimization Jon Sayles, IBM Software Group, ...
IBM Trademarks and Copyrights  <ul><ul><li>© Copyright IBM Corporation 2007,2008, 2009.  All rights reserved.  </li></ul><...
Course Contributing Authors  <ul><li>Thanks to the following individuals, for assisting with this course: </li></ul><ul><u...
Purpose of This Document <ul><ul><li>Course Name:  COBOL Foundation Training - with RDz </li></ul></ul><ul><ul><li>Course ...
Course Details  <ul><li>Audience </li></ul><ul><ul><li>This course is designed for application developers who have learned...
Source of COBOL Optimization Strategies  <ul><li>Virtually all of the information presented in this course on COBOL langua...
<ul><li>At the end of this course, you will be able to: </li></ul><ul><ul><li>Discuss the general tuning options for COBOL...
Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li>...
<ul><li>The coding style you use can affect how the optimizer handles your code.  </li></ul><ul><li>You can improve optimi...
Tuning your program – 1 of 2  <ul><li>When a program is &quot;well-structured&quot;, you can assess its performance.  </li...
Tuning your program – 2 of 2  <ul><li>The following areas affect program performance:  </li></ul><ul><ul><li>Coding techni...
Using structured programming <ul><li>Using structured programming statements, such as EVALUATE and inline PERFORM, makes y...
Using structured programming – specific recommendations <ul><li>Misconception#1 – Inline PERFORM is faster than Out-of-lin...
Factoring Expressions <ul><li>By factoring expressions in your programs, you can potentially eliminate a lot of unnecessar...
Using Symbolic Constants <ul><li>To have the optimizer recognize a data item as a constant throughout the program, initial...
<ul><li>Having finished this section you now should able to explain: </li></ul><ul><ul><li>How the coding style you use ca...
Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li>...
<ul><li>Choosing the appropriate data type and PICTURE clause: </li></ul><ul><ul><li>Can produce more efficient code </li>...
Choosing efficient computational data items – 1 of 2 <ul><li>When you use a data item mainly for arithmetic or as a subscr...
Choosing efficient computational data items – 2 of 2 <ul><li>To produce the most efficient code for a BINARY data item, en...
Using consistent data types <ul><li>In operations on operands of different types, one of the operands must be converted to...
Making floating point arithmetic expressions efficient <ul><li>Computation of arithmetic expressions that are evaluated in...
Making large exponentiations efficient <ul><li>Use floating point for exponentiations for large exponents to achieve faste...
<ul><li>Having finished this section, you now should be able to: </li></ul><ul><ul><li>Choose the appropriate data type an...
Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li>...
Table Elements – 1 of 4 <ul><li>A table element has a collective name, but the individual items within it do not have uniq...
Table Handling – 2 of 4 <ul><li>You can use several techniques to improve the efficiency of table-handling operations, and...
Handling Tables – 3 of 4 <ul><li>Whether you use indexes or subscripts, the following coding guidelines can help you get b...
Table Handling – General Performance Tips – 4 of 4 <ul><li>You can also improve the efficiency of tables by using these gu...
Subscripting – 1 of 2 <ul><li>The lowest possible subscript value is 1, which references the first occurrence of a table e...
Subscripting – 2 of 2 <ul><li>You can change part of a table element rather than the whole element. To do so, refer to the...
Workshop – Proving out the theory <ul><li>In the last three sections you have ingested quite a # of &quot;Best Practices&q...
Workshop – Steps <ul><li>Create a new program in a Local COBOL Project, named: cobperf.cbl </li></ul><ul><li>From the slid...
Workshop – z/OS Results <ul><li>If time permits, use the JCL in the    Notes section to: </li></ul><ul><ul><li>Compile und...
Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li>...
<ul><li>At the end of this course, you will be able to: </li></ul><ul><ul><li>Discuss the general tuning options for COBOL...
COBOL Application Tuning - Overview  <ul><li>There are many opportunities for the COBOL programmer to tune the COBOL appli...
Tuning the Run-Time - Overview  <ul><li>This section focuses on some of the options that are available for tuning an appli...
Compiler Directives – Overview and List <ul><li>Here are the compiler options we'll be focusing on: </li></ul><ul><ul><li>...
ARITH - EXTEND or COMPAT <ul><li>The ARITH compiler option allows you to control the maximum number of digits allowed for ...
AWO or NOAWO <ul><li>The AWO compiler option causes the APPLY WRITE-ONLY clause to be in effect for all physical sequentia...
Storage and its addressability <ul><li>When you run COBOL programs, the programs and the data that they use reside in virt...
DATA(24) or DATA(31) <ul><li>Using DATA(31) with your RENT program will help to relieve some below the line virtual storag...
DYNAM or NODYNAM <ul><li>The DYNAM compiler option specifies that all subprograms invoked through the CALL literal stateme...
FASTSRT or NOFASTSRT <ul><li>For eligible sorts, the FASTSRT compiler option specifies that the SORT product will handle a...
NUMPROC - NOPFD, MIG, or PFD – 1 of 2 <ul><li>Using the NUMPROC(PFD) compiler option generates significantly more efficien...
NUMPROC - NOPFD, MIG, or PFD – 2 of 2 <ul><li>NUMPROC(MIG) generates code that is similar to that of OS/VS COBOL.  </li></...
OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE – 1 of 3 <ul><li>To assist in the optimization of the code, you should use th...
OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE – 2 of 3 <ul><li>Additionally, with the OPTIMIZE(FULL) option in effect, you ...
OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE – 3 of 3 <ul><li>WARNING:  </li></ul><ul><ul><li>If your program relies upon ...
RENT or NORENT <ul><li>Using the RENT compiler option causes the compiler to generate some additional code to ensure that ...
RMODE - AUTO, 24, or ANY <ul><li>The RMODE compiler option determines the RMODE setting for the COBOL program.  </li></ul>...
SSRANGE or NOSSRANGE <ul><li>Using SSRANGE generates additional code to verify that all subscripts, indexes, and reference...
TEST or NOTEST  – 1 of 3 <ul><li>The TEST compiler option produces object code that enables Debug Tool to perform batch an...
TEST or NOTEST  – 2 of 3 <ul><li>Using TEST with a value other than NONE can cause a significant performance degradation w...
TEST or NOTEST  – 3 of 3 <ul><li>Performance considerations using TEST: </li></ul><ul><ul><li>On the average, TEST(ALL,SYM...
THREAD or NOTHREAD <ul><li>The THREAD compiler option enables the COBOL program for execution in a Language Environment en...
TRUNC - BIN, STD, or OPT  – 1 of 3 <ul><li>When using the TRUNC(BIN) compiler option, all binary (COMP) sending fields are...
TRUNC - BIN, STD, or OPT  – 2 of 3 <ul><li>However, with TRUNC(OPT), the compiler assumes that the data conforms to the PI...
TRUNC - BIN, STD, or OPT  – 3 of 3 <ul><li>Performance considerations using TRUNC: </li></ul><ul><ul><li>On the average, T...
Summary <ul><li>Having finished this section, you should now be able to: </li></ul><ul><ul><li>Select the proper compiler ...
Checkpoint <ul><li>Under construction </li></ul>
Compiler Directives Course <ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options th...
Overview <ul><li>Selecting the proper run-time options is another factor that affects the performance of a COBOL applicati...
AIXBLD <ul><li>The AIXBLD option allows alternate indexes to be built at run time.  </li></ul><ul><li>However, this may ad...
ALL31 – 1 of 2 <ul><li>The ALL31 option allows LE to take advantage of knowing that there are  no  AMODE(24) routines in t...
ALL31 – 2 of 2 <ul><li>Note that when using ALL31(OFF), you must also use STACK(,,BELOW). </li></ul><ul><li>Note:  </li></...
CHECK <ul><li>The CHECK option activates the additional code generated by the SSRANGE compiler option, which requires more...
DEBUG <ul><li>The DEBUG option activates the COBOL batch debugging features specified by the USE FOR DEBUGGING declarative...
RPTOPTS ,  RPTSTG <ul><li>The RPTOPTS option allows you to get a report of the run-time options that were in use during th...
RTEREUS – 1 of 2 <ul><li>The RTEREUS option causes the LE run-time environment to be initialized for reusability when the ...
RTEREUS – 2 of 2 <ul><li>However, using the RTEREUS option does affect the semantics of the COBOL application: </li></ul><...
Modifying COBOL's Reusable Environment Behavior – 1 of 2 <ul><li>Using the IGZRREOP customization job can be used to impro...
Modifying COBOL's Reusable Environment Behavior – 2 of 2 <ul><li>REUSENV=OPT changes this behavior by allowing Language En...
STORAGE  – 1 of 2 <ul><li>The first parameter of this option initializes all heap allocations, including all external data...
STORAGE  – 2 of 2 <ul><li>Performance considerations using STORAGE: </li></ul><ul><ul><li>On the average, STORAGE(00,00,00...
TEST <ul><li>The TEST option specifies the conditions under which Debug Tool assumes control when the user application </l...
TRAP <ul><li>The TRAP option allows LE to intercept an abnormal termination (abend), provide the abend information, and th...
Other Tuning Options Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li...
Running efficiently with CICS, IMS, or VSAM  <ul><li>You can improve performance for online programs running under CICS or...
Improving VSAM performance – 1 of 2 <ul><li>Your system programmer is most likely responsible for tuning the performance o...
Improving VSAM performance – 1 of 2 <ul><li>Application methods for improving VSAM performance …. </li></ul>
SQL Performance – 1 of 3 <ul><li>   SQL Performance is a very big topic.  If you are responsible for writing EGL code tha...
SQL Performance – Rules of Thumb – 2 of 3 <ul><li>For Batch applications that process all or a significant % of table rows...
SQL Performance – Rules of Thumb – 3 of 3 <ul><li>Use custom SQLRecords to limit the number of: </li></ul><ul><ul><li>Rows...
Grouping duplicate computations*** (probably remove) <ul><li>When components of different expressions are duplicates, ensu...
Grouping Constant Computations*** (probably remove) <ul><li>When several items in an expression are constant, ensure that ...
Upcoming SlideShare
Loading in …5
×

Enterprise COBOL Performance Optimization.ppt

1,158 views
1,031 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,158
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
76
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • IDENTIFICATION DIVISION. PROGRAM-ID. cobperf. AUTHOR. IBM. * A program that allows you to test out the various * COBOL Optimization Techniques ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. DATA DIVISION. WORKING-STORAGE SECTION. **** Fields for your test cases **** Table and ALL Function 01 COBOL-DATE. 05 Cob-DATE. 10 Cob-YEAR PIC 9(4) Value 0. 10 Cob-MONTH PIC 99 Value 0. 10 Cob-DAY PIC 99 Value 0. 05 Cob-TIME. 10 Cob-HOUR PIC 99 Value 0. 10 Cob-MINUTES PIC 99 Value 0. 10 Cob-SECONDS PIC 99 Value 0. 10 Cob-SEC-HUND PIC 99 Value 0. 05 Cob-TIME-RDF REDEFINES Cob-TIME PIC 9(8). 05 Cob-TIME-Difference. 10 GMT-DIR PIC X Value space. 10 GMT-HOUR PIC 99 Value 0. 10 GMT-MINUTES PIC 99 Value 0. **** Important note - Lower these values (by a factor of 100 **** (at least) when running on RDz Local Workstations 77 multiplier pic s9(8) comp value 10000000. 77 multiplier-2 pic s9(8) comp value 2000000. 01 Hold-date. 05 pic x(8). 05 hold-time pic 9(8). 01 Hdr-rec-1. 05 Pic x(43) value &amp;quot;Use Case Details&amp;quot;. 05 Pic x(6) value &amp;quot;ML Sec&amp;quot;. 01 Hdr-rec-2. 05 Pic x(43) value &amp;quot;==========================================&amp;quot;. 05 Pic x(6) value &amp;quot;======&amp;quot;. 01 Out-rec. 05 msg-out Pic x(43). 05 Difference Pic z(6). 01 subscripts. 05 j pic s9(4) comp. 05 i pic s9(4) comp. 05 idsp pic s9(3). 05 zval pic s9(4) comp. 01 Table-Data. 05 dta pic x(32) value &amp;quot;11112222333344445555666677778888&amp;quot;. 05 dta-rdf redefines dta. 10 item occurs 8 times pic s99v99. 05 Total pic 9(11)V99 value zero. 05 Discount pic V99 value .03. 01 Table-Data-srch. 03 dt. 05 dt9 pic x(32) value &amp;quot;11112222333344445555666677778888&amp;quot;. 05 dtb pic x(32) value &amp;quot;99990000aaaabbbbccccddddeeeeffff&amp;quot;. 05 dtc pic x(32) value &amp;quot;gggghhhhiiiijjjjkkkkllllmmmmnnnn&amp;quot;. 05 dtd pic x(32) value &amp;quot;ooooppppqqqqrrrrssssttttuuuuvvvv&amp;quot;. 05 dte pic x(32) value &amp;quot;wwwwxxxxyyyyzzzzAAAABBBBCCCCDDDD&amp;quot;. 05 dtf pic x(32) value &amp;quot;EEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLL&amp;quot;. 05 dtg pic x(32) value &amp;quot;MMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTT&amp;quot;. 05 dth pic x(32) value &amp;quot;UUUUVVVVWWWWXXXXYYYYZZZZA111B111&amp;quot;. 05 dti pic x(32) value &amp;quot;C111D111E111F111G111H111I111J111&amp;quot;. 05 dtj pic x(32) value &amp;quot;K111L111M111N111O111P111Q111R111&amp;quot;. 05 dtk pic x(32) value &amp;quot;S111T111U111V111W111X111Y111Z111&amp;quot;. 05 dtl pic x(32) value &amp;quot;A222B222C222D222E222F222G222H222&amp;quot;. 05 dtm pic x(32) value &amp;quot;I222J222K222L222M222N222O222P222&amp;quot;. 05 dtn pic x(32) value &amp;quot;Q222R222S222T222U222V222W222X222&amp;quot;. 05 dto pic x(32) value &amp;quot;a111a222a333a444a555a666a777a888&amp;quot;. 05 dtp pic x(32) value &amp;quot;a999a000baaaabbbacccadddaeeeafff&amp;quot;. 05 dtq pic x(32) value &amp;quot;agggahhhaiiiajjjakkkalllammmannn&amp;quot;. 05 dtr pic x(32) value &amp;quot;aoooapppaqqqarrrasssatttauuuavvv&amp;quot;. 05 dts pic x(32) value &amp;quot;awwwaxxxayyyazzzbAAAbBBBbCCCbDDD&amp;quot;. 05 dtt pic x(32) value &amp;quot;bEEEbFFFbGGGbHHHbIIIJJJJKKKKLLLL&amp;quot;. 05 dtu pic x(32) value &amp;quot;bMMMbNNNbOOObPPPbQQQbRRRbSSSbTTT&amp;quot;. 05 dtv pic x(32) value &amp;quot;bUUUbVVVbWWWbXXXbYYYbZZZbb11b211&amp;quot;. 05 dtw pic x(32) value &amp;quot;ba11bb11bc11bd11be11bf11bg11bh11&amp;quot;. 05 dtx pic x(32) value &amp;quot;bi11bj11bk11bl11bm11bn11bo11bp11&amp;quot;. 05 dty pic x(32) value &amp;quot;bq11Tr11bs11bt11bu11bv11bw11bx11&amp;quot;. 05 dtz pic x(32) value &amp;quot;by22bz22b922b822b722b622b522b422&amp;quot;. 05 dt1 pic x(32) value &amp;quot;be22be22Ke22berebrewbrewqeq2Prew&amp;quot;. 05 dt2 pic x(32) value &amp;quot;basdfghjkl;mnopqurstuvwxyz123456&amp;quot;. 03 dt-rdf redefines dt. 05 itm occurs 224 times. 10 flddisp pic x(4). 01 Table-Data-srch-idx. 03 dtx. 05 dt9 pic x(32) value &amp;quot;11112222333344445555666677778888&amp;quot;. 05 dtb pic x(32) value &amp;quot;99990000aaaabbbbccccddddeeeeffff&amp;quot;. 05 dtc pic x(32) value &amp;quot;gggghhhhiiiijjjjkkkkllllmmmmnnnn&amp;quot;. 05 dtd pic x(32) value &amp;quot;ooooppppqqqqrrrrssssttttuuuuvvvv&amp;quot;. 05 dte pic x(32) value &amp;quot;wwwwxxxxyyyyzzzzAAAABBBBCCCCDDDD&amp;quot;. 05 dtf pic x(32) value &amp;quot;EEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLL&amp;quot;. 05 dtg pic x(32) value &amp;quot;MMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTT&amp;quot;. 05 dth pic x(32) value &amp;quot;UUUUVVVVWWWWXXXXYYYYZZZZA111B111&amp;quot;. 05 dti pic x(32) value &amp;quot;C111D111E111F111G111H111I111J111&amp;quot;. 05 dtj pic x(32) value &amp;quot;K111L111M111N111O111P111Q111R111&amp;quot;. 05 dtk pic x(32) value &amp;quot;S111T111U111V111W111X111Y111Z111&amp;quot;. 05 dtl pic x(32) value &amp;quot;A222B222C222D222E222F222G222H222&amp;quot;. 05 dtm pic x(32) value &amp;quot;I222J222K222L222M222N222O222P222&amp;quot;. 05 dtn pic x(32) value &amp;quot;Q222R222S222T222U222V222W222X222&amp;quot;. 05 dto pic x(32) value &amp;quot;a111a222a333a444a555a666a777a888&amp;quot;. 05 dtp pic x(32) value &amp;quot;a999a000baaaabbbacccadddaeeeafff&amp;quot;. 05 dtq pic x(32) value &amp;quot;agggahhhaiiiajjjakkkalllammmannn&amp;quot;. 05 dtr pic x(32) value &amp;quot;aoooapppaqqqarrrasssatttauuuavvv&amp;quot;. 05 dts pic x(32) value &amp;quot;awwwaxxxayyyazzzbAAAbBBBbCCCbDDD&amp;quot;. 05 dtt pic x(32) value &amp;quot;bEEEbFFFbGGGbHHHbIIIJJJJKKKKLLLL&amp;quot;. 05 dtu pic x(32) value &amp;quot;bMMMbNNNbOOObPPPbQQQbRRRbSSSbTTT&amp;quot;. 05 dtv pic x(32) value &amp;quot;bUUUbVVVbWWWbXXXbYYYbZZZbb11b211&amp;quot;. 05 dtw pic x(32) value &amp;quot;ba11bb11bc11bd11be11bf11bg11bh11&amp;quot;. 05 dtx pic x(32) value &amp;quot;bi11bj11bk11bl11bm11bn11bo11bp11&amp;quot;. 05 dty pic x(32) value &amp;quot;bq11Tr11bs11bt11bu11bv11bw11bx11&amp;quot;. 05 dtz pic x(32) value &amp;quot;by22bz22b922b822b722b622b522b422&amp;quot;. 05 dt1 pic x(32) value &amp;quot;be22be22Ke22berebrewbrewqeq2Prew&amp;quot;. 05 dt2 pic x(32) value &amp;quot;basdfghjkl;mnopqurstuvwxyz123456&amp;quot;. 03 dtx-rdf redefines dtx. 05 itx pic x(4) occurs 224 times indexed by ix. 01 Table-Data-srch-all-idx. 03 dtxa. 05 dt9 pic x(32) value &amp;quot;00010002000300040005000600070008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00110012001300140015001600170018&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00210022002300240025002600270028&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00310032003300340035003600370038&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00410042004300440045004600470048&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00510052005300540055005600570058&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00610062006300640065006600670068&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00710072007300740075007600770078&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00810082008300840085008600870088&amp;quot;. 05 dt9 pic x(32) value &amp;quot;00910092009300940095009600970098&amp;quot;. 05 dt9 pic x(32) value &amp;quot;01010102010301040105010601070108&amp;quot;. 05 dt9 pic x(32) value &amp;quot;02010202020302040205020602070208&amp;quot;. 05 dt9 pic x(32) value &amp;quot;03010302030303040305030603070308&amp;quot;. 05 dt9 pic x(32) value &amp;quot;04010402040304040405040604070408&amp;quot;. 05 dt9 pic x(32) value &amp;quot;05010502050305040505050605070508&amp;quot;. 05 dt9 pic x(32) value &amp;quot;06010602060306040605060606070608&amp;quot;. 05 dt9 pic x(32) value &amp;quot;07010702070307040705070607070708&amp;quot;. 05 dt9 pic x(32) value &amp;quot;08010802080308040805080608070808&amp;quot;. 05 dt9 pic x(32) value &amp;quot;09010902090309040905090609070908&amp;quot;. 05 dt9 pic x(32) value &amp;quot;10011002100310041005100610071008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;20012002200320042005200620072008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;30013002300330043005300630073008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;40014002400340044005400640074008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;50015002500350045005500650075008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;60016002600360046005600660076008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;70017002700370047005700670077008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;80018002800380048005800680078008&amp;quot;. 05 dt9 pic x(32) value &amp;quot;90019002900390049005900690079008&amp;quot;. 03 dtxa-rdf redefines dtxa. 05 itxa pic x(4) occurs 224 times ASCENDING KEY IS itxa indexed by ixa. 77 end-val pic x. 01 math-variables. ******* Integers 05 binaryVar pic s9(4) usage comp value +432. 05 displayVar pic s9(4) usage display value +432. 05 packedVar pic s9(5) usage comp-3 value +432. 05 binaryVarTot pic s9(8) usage comp. 05 displayVarTot pic s9(8) usage display. 05 packedVarTot pic s9(9) usage comp-3. ******* Decimal numbers 05 binaryDec pic s9(4)V99 usage comp value +432.98. 05 displayDec pic s9(4)V99 usage display value +432.98. 05 packedDec pic s9(5)V99 usage comp-3 value +432.98. 05 binaryDecTot10 pic s9(8)V99 usage comp. 05 binaryDecTot8 pic s9(6)V99 usage comp. 05 displayDecTot pic s9(8)V99 usage display. 05 packedDecTot pic s9(9)V99 usage comp-3. ******* WORK AREAS 05 work-fld-10B pic s9(8)V99 usage comp value +432.98. 05 work-fld-10T pic s9(8)V99 usage comp. 05 work-fld-8B pic s9(6)V99 usage comp value +432.98. 05 work-fld-8T pic s9(6)V99 usage comp. 05 work-fld-10P pic s9(8)V99 usage comp-3 value +432.98. 05 work-fld-10TP pic s9(8)V99 usage comp-3. PROCEDURE DIVISION. INITIALIZE math-variables. **** 1. Refactoring a Computation (remove a multiplication) **** Display &amp;quot;**************************************************&amp;quot;. Display &amp;quot;****** Refactoring Multiplication Example ********&amp;quot;. Display &amp;quot;**************************************************&amp;quot;. display &amp;quot; &amp;quot;. display Hdr-rec-1. DISPLAY Hdr-rec-2. Move Function Current-Date to COBOL-Date. Move COBOL-DATE to Hold-date. perform Goodperf thru Goodperf-exit multiplier times. GoodPerf. MOVE ZERO TO TOTAL PERFORM VARYING I FROM 1 BY 1 UNTIL I &gt; 8 COMPUTE TOTAL = TOTAL + ITEM(I) END-PERFORM COMPUTE TOTAL = TOTAL * DISCOUNT. Goodperf-exit. exit. Next-Para. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Use Case - Move factor out of equation&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. perform Badperf thru Badperf-exit multiplier times. BadPerf. MOVE ZERO TO TOTAL PERFORM VARYING I FROM 1 BY 1 UNTIL I = 8 COMPUTE TOTAL = TOTAL + ITEM(I) * DISCOUNT END-PERFORM. Badperf-exit. exit. Last-perf. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Use Case - Factor repeated in equation&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Internal data representation **** Part I - Integer math Display &amp;quot; &amp;quot;. Display &amp;quot;**************************************************&amp;quot;. Display &amp;quot;Efficient Computation Examples - Integer - Starts:&amp;quot;. Display &amp;quot;**************************************************&amp;quot;. DISPLAY &amp;quot; &amp;quot;. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Binary integer perform Binarycomp thru Binarycomp-exit multiplier times. Binarycomp. COMPUTE binaryVarTot = binaryVar * binaryVar. Binarycomp-exit. exit. Next-binary. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Use Case - Binary Integer Multiplication&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Display integer perform Displaycomp thru Displaycomp-exit multiplier times. Displaycomp. COMPUTE displayVarTot = displayVar * displayVar. Displaycomp-exit. exit. Next-Display. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Use Case - Display Integer Multiplication&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Packed integer perform Packedcomp thru Packedcomp-exit multiplier times. Packedcomp. COMPUTE packedVarTot = packedVar * packedVar. Packedcomp-exit. exit. Next-packed. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Use Case - Packed Decimal Integer Mult.&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Mixed integer #s - mix packed and binary perform Mixedcomp thru Mixedcomp-exit multiplier times. Mixedcomp. COMPUTE binaryVarTot = displayVar * packedVar. Mixedcomp-exit. exit. Next-Mixed. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Use Case - Mixed Types - Integer Mult.&amp;quot; to msg-out. display Out-rec. **** Part II - Decimal math ********************************* **** Display &amp;quot; &amp;quot;. Display &amp;quot;**************************************************&amp;quot;. Display &amp;quot;Efficient Computation Examples - Decimal - Starts:&amp;quot;. Display &amp;quot;**************************************************&amp;quot;. DISPLAY &amp;quot; &amp;quot;. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date **** Binary decimal &gt; 8 digits perform BinaryDcomp thru BinaryDcomp-exit multiplier times. BinaryDcomp. COMPUTE binaryDecTot10 = binaryDec * binaryDec. BinaryDcomp-exit. exit. Next-binary. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Binary S9(10) Decimal Multiplication&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Binary decimal = 8 digits perform BinaryD8comp thru BinaryD8comp-exit multiplier times. BinaryD8comp. COMPUTE binaryDecTot8 = binaryDec * binaryDec. BinaryD8comp-exit. exit. Next-binary8. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Binary S9(08) Decimal Multiplication&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Display decimal perform DisplayDcomp thru DisplayDcomp-exit multiplier times. DisplayDcomp. COMPUTE displayDecTot = displayDec * displayDec. DisplayDcomp-exit. exit. Next-Display. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Display Decimal Multiplication&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Packed decimal perform PackedDcomp thru PackedDcomp-exit multiplier times. PackedDcomp. COMPUTE packedDecTot = packedDec * packedDec. PackedDcomp-exit. exit. Next-packed. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Packed Decimal Multiplication&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Mixed decimal #s - mix packed result and binary * display perform MixedAcomp thru MixedAcomp-exit multiplier times. MixedAcomp. COMPUTE PackedDecTot = binaryDecTot8 * DisplayDecTot. MixedAcomp-exit. exit. Next-MixedA. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Mixed-type Decimal Mult. Packed Total&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Mixed decimal #s - mix binary result and packed * display perform MixedDcomp thru MixedDcomp-exit multiplier times. MixedDcomp. COMPUTE BinaryDecTot8 = PackedDecTot * DisplayDecTot. MixedDcomp-exit. exit. Next-Mixed. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Mixed-type Decimal Mult. Binary8 Total&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Consistent types and usage - Binary &gt; 8 digits perform Cons10comp thru Cons10comp-exit multiplier times. Cons10comp. COMPUTE work-fld-10T = work-fld-10B * work-fld-10B. Cons10comp-exit. exit. Next-Cons10. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Consistent Types Decimal Mult. Binary 10&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Consistent types and usage - Binary 8 digits perform Cons8comp thru Cons8comp-exit multiplier times. Cons8comp. COMPUTE work-fld-8T = work-fld-8B * work-fld-10B. Cons8comp-exit. exit. Next-Cons8. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Consistent Types Decimal Mult. Binary 8&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Consistent types and usage - packed &gt; 8 digits perform ConsPack thru ConsPack-exit multiplier times. ConsPack. COMPUTE work-fld-10TP = work-fld-10P * work-fld-10P. ConsPack-exit. exit. Next-ConsPack. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Consistent Types Decimal Mult. Packed 10&amp;quot; to msg-out. display Out-rec. **** Part III - Table Handling ********************************* **** Display &amp;quot; &amp;quot;. Display &amp;quot;**************************************************&amp;quot;. Display &amp;quot;Efficient Table Handling Examples - Starts:&amp;quot;. Display &amp;quot;**************************************************&amp;quot;. DISPLAY &amp;quot; &amp;quot;. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Table display subscript sequential process - at table end.. perform Table-no-idxe thru Table-no-idx-exite multiplier-2 times. Table-no-idxe. move 0 to zVal. perform varying idsp from 1 by 1 until zVal &gt; 0 if itm(idsp) = &amp;quot;3456&amp;quot; move +1 to zVal end-if end-perform. Table-no-idx-exite. exit. Next-Table-no-idx-exite. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Perform Varying Subscript - 244th Element&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Table display subscript sequential process - at table begin perform Table-no-idxb thru Table-no-idx-exitb multiplier-2 times. Table-no-idxb. move 0 to zVal. perform varying idsp from 1 by 1 until zVal &gt; 0 if itm(idsp) = &amp;quot;1111&amp;quot; move +1 to zVal end-if end-perform. Table-no-idx-exitb. exit. Next-table. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Perform Varying Subscript - 1st Element&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Table display subscript sequential process - end. perform Table-idx thru Table-idx-exit multiplier-2 times. Table-idx. set ix to 1. search itx varying ix when itx(ix) = &amp;quot;3456&amp;quot; move +0 to zVal. Table-idx-exit. exit. Next-table-dx. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Sequential Search - Find 244th Element&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Table display subscript sequential process - begin. perform Table-idxs thru Table-idx-exits multiplier-2 times. Table-idxs. set ix to 1. search itx varying ix when itx(ix) = &amp;quot;1111&amp;quot; move +0 to zVal. Table-idx-exits. exit. Next-table-dxs. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Sequential Search - Find 1st Element&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. **** Table display subscript sequential process - begin. perform Table-idxa thru Table-ida-exits multiplier-2 times. Table-idxa. set ix to 1. search all itxa when itxa(ixa) = &amp;quot;3456&amp;quot; move +0 to zVal. Table-ida-exits. exit. Next-table-dxa. Move Function Current-Date to COBOL-Date. subtract hold-time from Cob-TIME-RDF giving Difference. move &amp;quot;Search ALL - Find 244th Element&amp;quot; to msg-out. display Out-rec. Move Function Current-Date to COBOL-Date. move COBOL-DATE to Hold-date. display &amp;quot;End of COBPERF&amp;quot;. * accept end-val. STOP RUN.
  • Notes:
  • Notes:
  • Notes:
  • Enterprise COBOL Performance Optimization.ppt

    1. 1. Enterprise COBOL Education Using Rational Developer for System Z Performance Optimization Jon Sayles, IBM Software Group, Rational EcoSystems Team
    2. 2. IBM Trademarks and Copyrights <ul><ul><li>© Copyright IBM Corporation 2007,2008, 2009. All rights reserved. </li></ul></ul><ul><ul><li>The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. </li></ul></ul><ul><ul><li>This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. </li></ul></ul><ul><ul><li>IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM Rational products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. </li></ul></ul>
    3. 3. Course Contributing Authors <ul><li>Thanks to the following individuals, for assisting with this course: </li></ul><ul><ul><li>Tom Ross, IBM/Rational </li></ul></ul><ul><ul><li>Dave Myers, IBM/Rational </li></ul></ul>
    4. 4. Purpose of This Document <ul><ul><li>Course Name: COBOL Foundation Training - with RDz </li></ul></ul><ul><ul><li>Course Description: Learn the COBOL language, RDz and learn z/OS terms, concepts and development skills in this course. </li></ul></ul><ul><ul><li>Pre-requisites: Some experience in a 3rd or 4th Generation Language is expected. SQL is also recommended. </li></ul></ul><ul><ul><li>Course Length: 10 days </li></ul></ul><ul><ul><li>Topics (Agenda) </li></ul></ul><ul><ul><ul><li>Getting Started - installing and configuring RDz - and the course materials, and using Eclipse to edit COBOL </li></ul></ul></ul><ul><ul><ul><li>COBOL General Language Rules </li></ul></ul></ul><ul><ul><ul><li>Basic COBOL Statements </li></ul></ul></ul><ul><ul><ul><li>Structured Programming Concepts and Coding Patterns </li></ul></ul></ul><ul><ul><ul><li>Data - numeric and character - deep/dive </li></ul></ul></ul><ul><ul><ul><li>Records and table handling - deep/dive </li></ul></ul></ul><ul><ul><ul><li>Input/Output and Sequential File patterns </li></ul></ul></ul><ul><ul><ul><li>Debugging Programs - Note: Deep dive on using RDz for common COBOL programming errors (001, 0C4, 0C7, infinite loops, fall-thru, etc.) </li></ul></ul></ul><ul><ul><ul><li>COBOL Subprograms and the Linkage Section </li></ul></ul></ul><ul><ul><ul><li>Advanced Character Manipulation </li></ul></ul></ul><ul><ul><ul><li>COBOL Intrinsic Functions, Date and Time coding patterns, and Language Environment calls </li></ul></ul></ul><ul><ul><ul><li>Reports and report writing patterns </li></ul></ul></ul><ul><ul><ul><li>OS/390 Concepts and JCL (here's where the Sandbox/mainframe access starts) </li></ul></ul></ul><ul><ul><ul><li>Compile/Link & Run Procs on the mainframe </li></ul></ul></ul><ul><ul><ul><li>Indexed file Coding Patterns </li></ul></ul></ul><ul><ul><ul><li>Sort/Merge and Master File Update Coding Patterns </li></ul></ul></ul><ul><ul><ul><li>Accessing DB2 Data and Stored Procedures </li></ul></ul></ul><ul><ul><ul><li>COBOL in the Real World: </li></ul></ul></ul><ul><ul><ul><ul><li>CICS - lecture only </li></ul></ul></ul></ul><ul><ul><ul><ul><li>IMS (DL/I and TM) - ditto </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Batch processing - ditto </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Java calling COBOL </li></ul></ul></ul></ul><ul><ul><ul><ul><li>COBOL and XML Statements </li></ul></ul></ul></ul><ul><ul><ul><ul><li>SOA and COBOL - creating and calling Web Services </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Web 2.0 using Rich UI </li></ul></ul></ul></ul>
    5. 5. Course Details <ul><li>Audience </li></ul><ul><ul><li>This course is designed for application developers who have learned or programmed in a 3 rd or 4 th generation language – and who need to build leading-edge applications using COBOL and Rational Developer for System z. </li></ul></ul><ul><li>Prerequisites </li></ul><ul><ul><li>This course assumes that the student has a basic understanding and knowledge of software computing technologies, and general data processing terms, concepts and vocabulary. </li></ul></ul><ul><ul><li>Knowledge of SQL (Structured Query Language) is assumed for database access is assumed as well. </li></ul></ul><ul><ul><li>Basic PC and mouse-driven development skills, terms and concepts are also assumed. </li></ul></ul><ul><ul><ul><li>Note that we will be covering RDz's mainframe-editor-compliant function key idiom in this unit </li></ul></ul></ul>
    6. 6. Source of COBOL Optimization Strategies <ul><li>Virtually all of the information presented in this course on COBOL language and compiler optimization guidelines were drawn from IBM publication: </li></ul><ul><li>The paper includes </li></ul>http://www-01.ibm.com/support/docview.wss?uid=swg27001475 authored by Rick Arellanes
    7. 7. <ul><li>At the end of this course, you will be able to: </li></ul><ul><ul><li>Discuss the general tuning options for COBOL Applications </li></ul></ul><ul><ul><li>Define the trade-offs and functional characteristics of COBOL Compiler options that affect Run-time Performance </li></ul></ul><ul><ul><li>Distinguish COBOL statements that are candidates for performance re-writes </li></ul></ul><ul><ul><li>Re-code candidate COBOL statements into better performing code patterns </li></ul></ul>Course Objectives
    8. 8. Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li></ul><ul><li>Handling Tables Efficiently </li></ul><ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options that Affect Run-time Performance </li></ul><ul><li>Efficient COBOL Coding Techniques </li></ul><ul><li>Tuning CICS, IMS, DB2 and VSAM Access </li></ul><ul><li>Appendices </li></ul>Units:
    9. 9. <ul><li>The coding style you use can affect how the optimizer handles your code. </li></ul><ul><li>You can improve optimization by using structured programming techniques, factoring expressions, using symbolic constants, and grouping constant and duplicate computations. </li></ul><ul><ul><li>Using structured programming </li></ul></ul><ul><ul><li>Factoring expressions </li></ul></ul><ul><ul><li>Using symbolic constants </li></ul></ul><ul><ul><li>Grouping constant computations </li></ul></ul><ul><ul><li>Grouping duplicate computations </li></ul></ul>Unit Objectives
    10. 10. Tuning your program – 1 of 2 <ul><li>When a program is &quot;well-structured&quot;, you can assess its performance. </li></ul><ul><ul><li>A program that has a tangled control flow is difficult to understand and maintain. </li></ul></ul><ul><ul><li>The tangled control flow also inhibits the optimization of the code. </li></ul></ul><ul><ul><li>Therefore, before you try to improve the performance directly, you need to assess certain aspects of your program: </li></ul></ul><ul><li>Examine the underlying algorithms for your program. </li></ul><ul><ul><li>For top performance, a sound algorithm is essential. </li></ul></ul><ul><ul><li>For example, a sophisticated algorithm for sorting a million items can be hundreds of thousands times faster than a simple algorithm. </li></ul></ul><ul><li>Look at the data structures. </li></ul><ul><ul><li>They should be appropriate for the algorithm. </li></ul></ul><ul><ul><li>When your program frequently accesses data, reduce the number of steps needed to access the data wherever possible. </li></ul></ul><ul><li>After you have improved the algorithms and data structures, look at other details of the COBOL source code that affect performance. </li></ul><ul><li>You can write programs that result in better generated code sequences and use system services better. </li></ul>
    11. 11. Tuning your program – 2 of 2 <ul><li>The following areas affect program performance: </li></ul><ul><ul><li>Coding techniques. </li></ul></ul><ul><ul><ul><li>These include using a programming style that helps the optimizer, choosing efficient data types, and handling tables efficiently. </li></ul></ul></ul><ul><ul><li>Optimization. </li></ul></ul><ul><ul><ul><li>You can optimize your code by using the OPTIMIZE compiler option. </li></ul></ul></ul><ul><ul><li>Compiler options and USE FOR DEBUGGING ON ALL PROCEDURES. </li></ul></ul><ul><ul><ul><li>Certain compiler options and language affect the efficiency of your program. </li></ul></ul></ul><ul><ul><li>Runtime environment. </li></ul></ul><ul><ul><ul><li>Carefully consider your choice of runtime options and other runtime considerations that control how your compiled program runs. </li></ul></ul></ul><ul><ul><li>Running under CICS, IMS, or using VSAM. </li></ul></ul><ul><ul><ul><li>Various tips can help make these programs run efficiently. </li></ul></ul></ul>
    12. 12. Using structured programming <ul><li>Using structured programming statements, such as EVALUATE and inline PERFORM, makes your program more comprehensible and generates a more linear control flow. </li></ul><ul><li>As a result, the optimizer can operate over larger regions of the program, which gives you more efficient code. </li></ul><ul><li>Use top-down programming constructs. </li></ul><ul><ul><li>And design your code using the notion of functional decomposition: </li></ul></ul><ul><ul><ul><li>http://en.wikipedia.org/wiki/Functional_decomposition </li></ul></ul></ul>
    13. 13. Using structured programming – specific recommendations <ul><li>Misconception#1 – Inline PERFORM is faster than Out-of-line (standard) PERFORM: </li></ul><ul><ul><li>Inline PERFORM vs. Out-of-line (standard) PERFORM </li></ul></ul><ul><ul><ul><li>Out-of-line PERFORM statements are a natural means of realizing a top-down structured design, with top-down programming. </li></ul></ul></ul><ul><ul><ul><li>Out-of-line PERFORM statements can often be as efficient as inline PERFORM statements, because the optimizer can simplify or remove the linkage code. </li></ul></ul></ul><ul><li>Misconception#2 – GO TO and branching is faster than PERFORM chaining: </li></ul><ul><ul><li>Avoid using the following constructs: </li></ul></ul><ul><ul><ul><li>GO TO - other than to a Paragraph Exit – which is PERFORM'd THRU </li></ul></ul></ul><ul><ul><ul><li>Backward branches </li></ul></ul></ul><ul><ul><ul><ul><li>Except as needed for loops for which PERFORM is unsuitable </li></ul></ul></ul></ul><ul><ul><ul><li>PERFORM procedures that involve irregular control flow </li></ul></ul></ul><ul><ul><ul><ul><li>Such as preventing control from passing to the end of the procedure and returning to the end of the PERFORM chain </li></ul></ul></ul></ul><ul><li>Definitely avoid using ALTER - as it: </li></ul><ul><ul><li>Makes maintenance and support a nightmare </li></ul></ul><ul><ul><li>Removes some important optimization options from the compiler </li></ul></ul>
    14. 14. Factoring Expressions <ul><li>By factoring expressions in your programs, you can potentially eliminate a lot of unnecessary computation. </li></ul><ul><li>For example, the first block of code below is more efficient than the second block of code: </li></ul><ul><ul><ul><li>MOVE ZERO TO TOTAL </li></ul></ul></ul><ul><ul><ul><li>PERFORM VARYING I FROM 1 BY 1 UNTIL I = 10 </li></ul></ul></ul><ul><ul><ul><li>COMPUTE TOTAL = TOTAL + ITEM(I) </li></ul></ul></ul><ul><ul><ul><li>END-PERFORM </li></ul></ul></ul><ul><ul><ul><li>COMPUTE TOTAL = TOTAL * DISCOUNT </li></ul></ul></ul><ul><ul><ul><li>MOVE ZERO TO TOTAL </li></ul></ul></ul><ul><ul><ul><li>PERFORM VARYING I FROM 1 BY 1 UNTIL I = 10 </li></ul></ul></ul><ul><ul><ul><li>COMPUTE TOTAL = TOTAL + ITEM(I) * DISCOUNT </li></ul></ul></ul><ul><ul><ul><li>END-PERFORM </li></ul></ul></ul>
    15. 15. Using Symbolic Constants <ul><li>To have the optimizer recognize a data item as a constant throughout the program, initialize it with a VALUE clause and do not change it anywhere in the program. </li></ul><ul><li>If you pass a data item to a subprogram BY REFERENCE , the optimizer treats it as an external data item and assumes that it is changed at every subprogram call. </li></ul><ul><ul><li>CALL … BY REFERENCE is the COBOL language default </li></ul></ul><ul><ul><li>Moral: If you know that you are passing immutable values from one program to the next in a CALL statement, pass them by value </li></ul></ul><ul><li>If you move a literal to a data item, the optimizer recognizes the data item as a constant only in a limited area of the program after the MOVE statement. </li></ul>
    16. 16. <ul><li>Having finished this section you now should able to explain: </li></ul><ul><ul><li>How the coding style you use can affect how the optimizer handles your code. </li></ul></ul><ul><ul><li>How you can improve optimization by using structured programming techniques, factoring expressions, using symbolic constants, and grouping constant and duplicate computations. </li></ul></ul>Unit Objectives – Summary
    17. 17. Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li></ul><ul><li>Handling Tables Efficiently </li></ul><ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options that Affect Run-time Performance </li></ul><ul><li>Efficient COBOL Coding Techniques </li></ul><ul><li>Appendices </li></ul>Units:
    18. 18. <ul><li>Choosing the appropriate data type and PICTURE clause: </li></ul><ul><ul><li>Can produce more efficient code </li></ul></ul><ul><ul><li>As can avoiding USAGE DISPLAY and USAGE NATIONAL data items in areas that are heavily used for computations. </li></ul></ul><ul><li>Consistent data types can reduce the need for conversions during operations on data items. </li></ul><ul><ul><li>Making code significantly more efficient at run-time </li></ul></ul><ul><li>You can also improve program performance by carefully determining when to use fixed-point and floating-point data types. </li></ul>Unit Objectives
    19. 19. Choosing efficient computational data items – 1 of 2 <ul><li>When you use a data item mainly for arithmetic or as a subscript, code USAGE BINARY (comp) on the data description entry for the item. </li></ul><ul><ul><li>The operations for manipulating binary data are faster than those for manipulating decimal data. Note that this is especially important for integer math, and not as hard and fast a rule for decimal computations, although USAGE DISPLAY data is almost always less efficient for doing math in COBOL </li></ul></ul><ul><li>If a fixed-point arithmetic statement has intermediate results with a large precision (number of significant digits), the compiler uses decimal arithmetic anyway, after converting the operands to packed-decimal form. </li></ul><ul><ul><li>You will see this in some of the labs you complete </li></ul></ul><ul><li>For fixed-point arithmetic statements, the compiler normally uses binary arithmetic for simple computations with binary operands if the precision is eight or fewer digits. </li></ul><ul><ul><li>Above 18 digits, the compiler always uses decimal arithmetic. </li></ul></ul><ul><ul><li>With a precision of nine to 18 digits, the compiler uses either form. </li></ul></ul>COBOL Math Variable Type &quot;Efficiency-o-meter&quot; USAGE BINARY (COMP) USAGE PACKED DECIMAL (COMP-3) USAGE DISPLAY Generally More Efficient Generally Less Efficient
    20. 20. Choosing efficient computational data items – 2 of 2 <ul><li>To produce the most efficient code for a BINARY data item, ensure that it has: </li></ul><ul><ul><li>A sign (an S in its PICTURE clause) </li></ul></ul><ul><ul><li>Eight or fewer digits </li></ul></ul><ul><li>For a data item that is larger than eight digits or is used with DISPLAY or NATIONAL data items, use PACKED-DECIMAL (comp-3) data items </li></ul><ul><ul><li>The code generated for PACKED-DECIMAL data items can be as fast as that for BINARY data items in some cases, especially if the statement is complicated or specifies rounding. </li></ul></ul><ul><li>To produce the most efficient code for a PACKED-DECIMAL data item, ensure that it has: </li></ul><ul><ul><li>A sign (an S in its PICTURE clause) </li></ul></ul><ul><ul><li>An odd number of digits (9s in the PICTURE clause), so that it occupies an exact number of bytes without a half byte left over </li></ul></ul><ul><ul><li>(when business requirements permit) 15 or fewer digits in the PICTURE specification to avoid using library routines for multiplication and division </li></ul></ul>
    21. 21. Using consistent data types <ul><li>In operations on operands of different types, one of the operands must be converted to the same type as the other. </li></ul><ul><li>Each conversion requires several instructions. </li></ul><ul><ul><li>For example, one of the operands might need to be scaled to give it the appropriate number of decimal places. </li></ul></ul><ul><li>You can largely avoid conversions by using consistent data types and by giving both operands the same usage and also appropriate PICTURE specifications. </li></ul><ul><ul><li>That is, you should ensure that two numbers to be compared, added, or subtracted not only have the same usage but also the same number of decimal places (9s after the V in the PICTURE clause). </li></ul></ul><ul><ul><ul><li>This means that, for COBOL work areas in the DATA DIVISION – (not file and database buffers) – ensure consistent PIC clauses as follows: </li></ul></ul></ul>Change this  to this:
    22. 22. Making floating point arithmetic expressions efficient <ul><li>Computation of arithmetic expressions that are evaluated in floating point is most efficient when the operands need little or no conversion. </li></ul><ul><li>Use operands that are COMP-1 or COMP-2 to produce the most efficient code. </li></ul><ul><li>Declare integer items as BINARY or PACKED-DECIMAL with nine or fewer digits to afford quick conversion to floating-point data. </li></ul><ul><li>Also, conversion from a COMP-1 or COMP-2 item to a fixed-point integer with nine or fewer digits, without SIZE ERROR in effect, is efficient when the value of the COMP-1 or COMP-2 item is less than 1,000,000,000. </li></ul>
    23. 23. Making large exponentiations efficient <ul><li>Use floating point for exponentiations for large exponents to achieve faster evaluation and more accurate results. </li></ul><ul><li>For example, the first statement below is computed more quickly and accurately than the second statement: </li></ul><ul><ul><li>COMPUTE fixed-point1 = fixed-point2 ** 100000.E+00 </li></ul></ul><ul><ul><li>COMPUTE fixed-point1 = fixed-point2 ** 100000 </li></ul></ul><ul><li>A floating-point exponent causes floating-point arithmetic to be used to compute the exponentiation. </li></ul>
    24. 24. <ul><li>Having finished this section, you now should be able to: </li></ul><ul><ul><li>Choose the appropriate data type and PICTURE clause: </li></ul></ul><ul><ul><li>Discuss the benefits of consistent data-type declarations </li></ul></ul><ul><ul><li>Discuss the benefits of different floating point operations </li></ul></ul>Unit Objectives - Summary
    25. 25. Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li></ul><ul><li>Handling Tables Efficiently </li></ul><ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options that Affect Run-time Performance </li></ul><ul><li>Efficient COBOL Coding Techniques </li></ul><ul><li>Appendices </li></ul>Units:
    26. 26. Table Elements – 1 of 4 <ul><li>A table element has a collective name, but the individual items within it do not have unique data-names. </li></ul><ul><li>To refer to an item, you have a choice of three techniques: </li></ul><ul><ul><li>Use the data-name of the table element, along with its occurrence number (called a subscript) in parentheses. </li></ul></ul><ul><ul><ul><li>This technique is called subscripting. </li></ul></ul></ul><ul><ul><li>Use the data-name of the table element, along with a value (called an index) that is added to the address of the table to locate an item (as a displacement from the beginning of the table). </li></ul></ul><ul><ul><ul><li>This technique is called indexing, or subscripting using index-names. </li></ul></ul></ul><ul><ul><li>Use both subscripts and indexes together </li></ul></ul>
    27. 27. Table Handling – 2 of 4 <ul><li>You can use several techniques to improve the efficiency of table-handling operations, and to influence the optimizer. </li></ul><ul><li>The return for your efforts can be significant, particularly when table-handling operations are a major part of an application. </li></ul><ul><li>The following two guidelines affect your choice of how to refer to table elements: </li></ul><ul><ul><li>Use indexing rather than subscripting. </li></ul></ul><ul><ul><ul><li>Although the compiler can eliminate duplicate indexes and subscripts, the original reference to a table element is more efficient with indexes (even if the subscripts were BINARY). </li></ul></ul></ul><ul><ul><ul><ul><li>The value of an index has the element size factored into it, whereas the value of a subscript must be multiplied by the element size when the subscript is used. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>The index already contains the displacement from the start of the table, and this value does not have to be calculated at run time. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>However, subscripting might be easier to understand and maintain. Note that this is especially important during development and testing. </li></ul></ul></ul></ul><ul><ul><li>Use relative indexing. </li></ul></ul><ul><ul><ul><li>Relative index references (that is, references in which an unsigned numeric literal is added to or subtracted from the index-name) are executed at least as fast as direct index references, and sometimes faster. </li></ul></ul></ul><ul><ul><ul><li>There is no merit in keeping alternative indexes with the offset factored in. </li></ul></ul></ul>
    28. 28. Handling Tables – 3 of 4 <ul><li>Whether you use indexes or subscripts, the following coding guidelines can help you get better performance: </li></ul><ul><ul><li>Put constant and duplicate indexes or subscripts on the left. </li></ul></ul><ul><ul><ul><li>You can reduce or eliminate runtime computations this way. Even when all the indexes or subscripts are variable, try to use your tables so that the rightmost subscript varies most often for references that occur close to each other in the program. </li></ul></ul></ul><ul><ul><ul><li>This practice also improves the pattern of storage references and also paging. If all the indexes or subscripts are duplicates, then the entire index or subscript computation is a common sub-expression. </li></ul></ul></ul><ul><ul><li>Specify the element length so that it matches that of related tables. </li></ul></ul><ul><ul><ul><li>When you index or subscript tables, it is most efficient if all the tables have the same element length. That way, the stride for the last dimension of the tables is the same, and the optimizer can reuse the rightmost index or subscript computed for one table. If both the element lengths and the number of occurrences in each dimension are equal, then the strides for dimensions other than the last are also equal, resulting in greater commonality between their subscript computations. </li></ul></ul></ul><ul><ul><ul><li>The optimizer can then reuse indexes or subscripts other than the rightmost. </li></ul></ul></ul><ul><ul><li>Avoid errors in references by coding index and subscript checks into your program. </li></ul></ul><ul><ul><ul><li>If you need to validate indexes and subscripts, it might be faster to code your own checks than to use the SSRANGE compiler option . </li></ul></ul></ul>
    29. 29. Table Handling – General Performance Tips – 4 of 4 <ul><li>You can also improve the efficiency of tables by using these guidelines: </li></ul><ul><ul><li>Use binary data items for all subscripts. </li></ul></ul><ul><ul><ul><li>When you use subscripts to address a table, use a BINARY signed data item with eight or fewer digits. </li></ul></ul></ul><ul><ul><ul><ul><li>In some cases, using four or fewer digits for the data item might also improve processing time. </li></ul></ul></ul></ul><ul><ul><li>Use binary data items for variable-length table items. </li></ul></ul><ul><ul><ul><li>For tables with variable-length items, you can improve the code for OCCURS DEPENDING ON (ODO). </li></ul></ul></ul><ul><ul><ul><li>To avoid unnecessary conversions each time the variable-length items are referenced, specify BINARY for OCCURS . . . DEPENDING ON objects. </li></ul></ul></ul><ul><ul><li>Use fixed-length data items whenever possible. </li></ul></ul><ul><ul><ul><li>Copying variable-length data items into a fixed-length data item before a period of high-frequency use can reduce some of the overhead associated with using variable-length data items. </li></ul></ul></ul><ul><ul><li>Organize tables according to the type of search method used. </li></ul></ul><ul><ul><ul><li>If the table is searched sequentially, put the data values most likely to satisfy the search criteria at the beginning of the table. </li></ul></ul></ul><ul><ul><ul><li>If the table is searched using a binary search algorithm, put the data values in the table sorted alphabetically on the search key field. </li></ul></ul></ul>
    30. 30. Subscripting – 1 of 2 <ul><li>The lowest possible subscript value is 1, which references the first occurrence of a table element. </li></ul><ul><ul><li>In a one-dimensional table, the subscript corresponds to the row number. </li></ul></ul><ul><li>You can use a literal or a data-name as a subscript. </li></ul><ul><ul><li>If a data item that has a literal subscript is of fixed length, the compiler resolves the location of the data item. </li></ul></ul><ul><li>When you use a data-name as a variable subscript, you must describe the data-name as an elementary numeric integer. </li></ul><ul><ul><li>The most efficient format is COMPUTATIONAL (COMP) with a PICTURE size that is smaller than five digits. </li></ul></ul><ul><ul><li>You cannot use a subscript with a data-name that is used as a subscript. The code generated for the application resolves the location of a variable subscript at run time. </li></ul></ul><ul><li>You can increment or decrement a literal or variable subscript by a specified integer amount. </li></ul><ul><ul><li>For example: </li></ul></ul><ul><ul><li>TABLE-COLUMN (SUB1 - 1, SUB2 + 3) </li></ul></ul>
    31. 31. Subscripting – 2 of 2 <ul><li>You can change part of a table element rather than the whole element. To do so, refer to the character position and length of the substring to be changed. </li></ul><ul><li>For example: </li></ul><ul><ul><li>01 ANY-TABLE. </li></ul></ul><ul><ul><li>05 TABLE-ELEMENT PIC X(10) OCCURS 3 TIMES VALUE &quot;ABCDEFGHIJ&quot; </li></ul></ul><ul><ul><li>. . . . MOVE &quot;??&quot; TO TABLE-ELEMENT (1) (3 : 2). </li></ul></ul><ul><li>The MOVE statement in the example above moves the string '??' into table element number 1, beginning at character position 3, for a length of 2 characters. </li></ul>
    32. 32. Workshop – Proving out the theory <ul><li>In the last three sections you have ingested quite a # of &quot;Best Practices&quot; for COBOL optimization </li></ul><ul><li>Wouldn't it be nice to actually see whether or not making certain changes to a program improved performance? </li></ul><ul><ul><li>Our bet… yes </li></ul></ul><ul><li>On the next few slides are steps for you to run a program that contains use cases as isolated variable in just such an experiment. </li></ul><ul><li>You will run this program on: </li></ul><ul><ul><li>Workstation RDz </li></ul></ul><ul><ul><li>A z/OS mainframe </li></ul></ul><ul><li>After the completing the job you should: </li></ul><ul><ul><li>Verify each of the use cases – tying the coding example to one (or more) of the best practices in this section </li></ul></ul><ul><ul><li>Confirm or deny that the best practice is – just that </li></ul></ul>
    33. 33. Workshop – Steps <ul><li>Create a new program in a Local COBOL Project, named: cobperf.cbl </li></ul><ul><li>From the slide notes, Copy/Paste the code into cobperf.cbl </li></ul><ul><ul><li>Edit the program, and as described in the comments, lower the multiplier and multiplier-2 factors by removing at least one zero </li></ul></ul><ul><li>In your project: </li></ul><ul><ul><li>Nominate cobperf.cbl as the Entry Point </li></ul></ul><ul><ul><li>Rebuild your project </li></ul></ul><ul><ul><li>Clean up any syntax errors </li></ul></ul><ul><ul><li>Create a new Run Configuration for cobperf.exe </li></ul></ul><ul><ul><li>Run the program </li></ul></ul><ul><ul><li>Note the results in the Display (DOS box) </li></ul></ul><ul><ul><li>Verify results by returning to the section in this course where the particular coding construct was described </li></ul></ul>
    34. 34. Workshop – z/OS Results <ul><li>If time permits, use the JCL in the Notes section to: </li></ul><ul><ul><li>Compile under z/OS </li></ul></ul><ul><ul><li>Run under z/OS </li></ul></ul><ul><li>When complete, check out the SYSOUT displays: </li></ul><ul><ul><li>Compare/Contrast with the Workstation run </li></ul></ul><ul><ul><li>Compare with the Best Practices </li></ul></ul><ul><ul><li>Note especially, that: </li></ul></ul><ul><ul><ul><li>Binary fields and decimal math do not always get along </li></ul></ul></ul><ul><ul><ul><li>Efficient table-handling depends on a large # of variables </li></ul></ul></ul>
    35. 35. Compiler Directives Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li></ul><ul><li>Handling Tables Efficiently </li></ul><ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options that Affect Run-time Performance </li></ul><ul><li>Efficient COBOL Coding Techniques </li></ul><ul><li>Appendices </li></ul>Units:
    36. 36. <ul><li>At the end of this course, you will be able to: </li></ul><ul><ul><li>Discuss the general tuning options for COBOL Applications </li></ul></ul><ul><ul><li>Define the trade-offs and functional characteristics of COBOL Compiler options that affect Run-time Performance </li></ul></ul>Unit Objectives
    37. 37. COBOL Application Tuning - Overview <ul><li>There are many opportunities for the COBOL programmer to tune the COBOL application program and run-time environment for better CPU time performance and better use of system resources. </li></ul><ul><li>The COBOL programmer has many compiler options, run-time options, data types, and language features from which to select </li></ul><ul><ul><li>The proper choice may lead to significantly better performance. </li></ul></ul><ul><ul><li>Conversely, making the wrong choice can lead to significantly degraded performance. </li></ul></ul><ul><li>The goal of this course is to make you aware of the various options that are available so that you both the system programmer installing the product as well as the COBOL programmer responsible for the application – can choose the right ones for your application program that will lead to the best performance for your environment. </li></ul>
    38. 38. Tuning the Run-Time - Overview <ul><li>This section focuses on some of the options that are available for tuning an application, as well as the overall LE run-time environment. </li></ul><ul><li>This in itself may not produce high performing code since both the coding style and the data types can have a significant impact on the performance of the application. </li></ul><ul><li>In fact, the coding style and data types usually have a far greater impact on the performance of an application than that of tuning the application via external means </li></ul><ul><ul><li>Compiler options </li></ul></ul><ul><ul><li>Run-time options </li></ul></ul><ul><ul><li>Space management tuning </li></ul></ul><ul><ul><li>Placing the library routines in shared storage </li></ul></ul><ul><ul><li>Adding buffers via DCB=BUFNO= or AMP= JCL statements to both input and output files </li></ul></ul><ul><ul><li>Running in a high priority batch initiator </li></ul></ul><ul><ul><li>Verify your files are not on high-traffic disk channels or packs </li></ul></ul><ul><ul><li>Don't write data if you don't have to -- the fastest I/O is the one you don't do </li></ul></ul><ul><ul><li>Etc. </li></ul></ul>
    39. 39. Compiler Directives – Overview and List <ul><li>Here are the compiler options we'll be focusing on: </li></ul><ul><ul><li>ARITH - EXTEND or COMPAT </li></ul></ul><ul><ul><li>AWO or NOAWO </li></ul></ul><ul><ul><li>DATA(24) or DATA(31) </li></ul></ul><ul><ul><li>DYNAM or NODYNAM </li></ul></ul><ul><ul><li>FASTSRT or NOFASTSRT </li></ul></ul><ul><ul><li>NUMPROC - NOPFD, MIG, or PFD </li></ul></ul><ul><ul><li>OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE </li></ul></ul><ul><ul><li>RENT or NORENT </li></ul></ul><ul><ul><li>RMODE - AUTO, 24, or ANY </li></ul></ul><ul><ul><li>SSRANGE or NOSSRANGE </li></ul></ul><ul><ul><li>TEST or NOTEST </li></ul></ul><ul><ul><li>THREAD or NOTHREAD </li></ul></ul><ul><ul><li>TRUNC - BIN, STD, or OPT </li></ul></ul><ul><li>You will note that the use of the above is not one-dimensional, in that you will have take into many account factors </li></ul>
    40. 40. ARITH - EXTEND or COMPAT <ul><li>The ARITH compiler option allows you to control the maximum number of digits allowed for decimal numbers (packed decimal, zoned decimal, and numeric-edited data items and numeric literals). </li></ul><ul><li>Options: </li></ul><ul><ul><li>ARITH(EXTEND), the maximum number of digits is 31 </li></ul></ul><ul><ul><li>ARITH(COMPAT), the maximum number of digits is 18. </li></ul></ul><ul><li>Issue: </li></ul><ul><ul><li>ARITH(EXTEND) will cause some degradation in performance for all decimal data types due to larger intermediate results. </li></ul></ul><ul><ul><li>The amount of degradation that you experience depends directly on the amount of decimal data that you use. </li></ul></ul><ul><li>Performance considerations using ARITH: </li></ul><ul><ul><li>On the average, ARITH(EXTEND) was 1% slower than ARITH(COMPAT), </li></ul></ul><ul><ul><li>Range of equivalent to 38% slower. </li></ul></ul><ul><li>Default: </li></ul><ul><ul><li>ARITH(COMPAT) </li></ul></ul>
    41. 41. AWO or NOAWO <ul><li>The AWO compiler option causes the APPLY WRITE-ONLY clause to be in effect for all physical sequential, variable-length, blocked files, even if the APPLY WRITE-ONLY clause is not specified in the program. </li></ul><ul><li>Options: </li></ul><ul><ul><li>With APPLY WRITE-ONLY (AWO) in effect, the file buffer is written to the output device when there is not enough space in the buffer for the next record. </li></ul></ul><ul><ul><li>Without APPLY WRITE-ONLY (NOAWO) the file buffer is written to the output device when there is not enough space in the buffer for the maximum size record. </li></ul></ul><ul><li>If the application has a large variation in the size of the records to be written, using APPLY WRITE-ONLY can result in a performance savings since this will generally result in fewer calls to Data Management Services to handle the I/Os. </li></ul><ul><li>Performance considerations using AWO: </li></ul><ul><ul><li>One program using variable-length files and AWO was 88% faster than NOAWO. </li></ul></ul><ul><ul><li>This faster processing was the result of using 98% fewer EXCPs to process the writes. </li></ul></ul><ul><li>Default: </li></ul><ul><ul><li>NOAWO </li></ul></ul>
    42. 42. Storage and its addressability <ul><li>When you run COBOL programs, the programs and the data that they use reside in virtual storage. Storage that you use with COBOL can be either below the 16-MB line or above the 16-MB line but below the 2-GB bar. Two modes of addressing are available to address this storage: 24-bit and 31-bit. </li></ul><ul><li>You can address storage below (but not above) the 16-MB line with 24-bit addressing. You can address storage either above or below the 16-MB line with 31-bit addressing. </li></ul><ul><ul><li>Unrestricted storage is addressable by 31-bit addressing and therefore encompasses all the storage available to your program, both above and below the 16-MB line. </li></ul></ul><ul><li>Enterprise COBOL does not directly exploit the 64-bit virtual addressing capability of z/OS; however, COBOL applications running in 31-bit or 24-bit addressing mode are fully supported on 64-bit z/OS systems. </li></ul><ul><ul><li>Addressing mode (AMODE) is the attribute that tells which hardware addressing mode is supported by your program: 24-bit addressing, 31-bit addressing, or either 24-bit or 31-bit addressing. This attribute is AMODE 24, AMODE 31, or AMODE ANY, respectively. The object program, the load module, and the executing program each has an AMODE attribute. All Enterprise COBOL object programs are AMODE ANY. </li></ul></ul><ul><ul><li>Residency mode (RMODE) is the attribute of a program load module that identifies where in virtual storage the program will reside: below the 16-MB line, or either below or above. This attribute is RMODE 24 or RMODE ANY. </li></ul></ul>
    43. 43. DATA(24) or DATA(31) <ul><li>Using DATA(31) with your RENT program will help to relieve some below the line virtual storage constraint problems. </li></ul><ul><li>When you use DATA(31) with your RENT programs, most QSAM file buffers can be allocated above the 16MB line. </li></ul><ul><li>When you use DATA(31) with the run-time option HEAP(,,ANYWHERE), all non-EXTERNAL WORKING-STORAGE and non-EXTERNAL FD record areas can be allocated above the 16MB line. </li></ul><ul><li>With DATA(24), the WORKING-STORAGE and FD record areas will be allocated below the 16 MB line. </li></ul><ul><li>Notes: </li></ul><ul><ul><li>1. For NORENT programs, the RMODE option determines where non-EXTERNAL data is allocated. </li></ul></ul><ul><ul><li>2. See “QSAM Files” on page 27 for additional information on QSAM file buffers. </li></ul></ul><ul><ul><li>3. Data(24) can be combined with the Run-time option: ALL31 </li></ul></ul>
    44. 44. DYNAM or NODYNAM <ul><li>The DYNAM compiler option specifies that all subprograms invoked through the CALL literal statement will be loaded dynamically at run time. </li></ul><ul><li>This allows you to share common subprograms among several different applications, allowing for easier maintenance of these subprograms since the application will not have to be re-link-edited if the subprogram is changed. </li></ul><ul><li>DYNAM also allows you to control the use of virtual storage by giving you the ability to use a CANCEL statement to free the virtual storage used by a subprogram when the subprogram is no longer needed. </li></ul><ul><li>However, when using the DYNAM option, you pay a performance penalty since the call must go through a library routine, whereas with the NODYNAM option, the call goes directly to the subprogram. </li></ul><ul><li>Hence, the path length is longer with DYNAM than with NODYNAM. </li></ul><ul><li>Performance considerations using DYNAM with CALL literal (measuring CALL overhead only): </li></ul><ul><ul><li>On the average, for a CALL intensive application, the overhead associated with the CALL using </li></ul></ul><ul><ul><li>DYNAM ranged from 16% slower to 100% slower than NODYNAM. </li></ul></ul>
    45. 45. FASTSRT or NOFASTSRT <ul><li>For eligible sorts, the FASTSRT compiler option specifies that the SORT product will handle all of the I/O and that COBOL does not need to do it. </li></ul><ul><li>This eliminates all of the overhead of returning control to COBOL after each record is read in or after processing each record that COBOL returns to sort. </li></ul><ul><li>The use of FASTSRT is recommended when direct access devices are used for the sort work files since the compiler will then determine which sorts are eligible for this option and generate the proper code. </li></ul><ul><li>If the sort is not eligible for this option, the compiler will still generate the same code as if the NOFASTSRT option were in effect. </li></ul><ul><li>A list of requirements for using the FASTSRT option is in the COBOL programming guide. </li></ul><ul><li>Performance considerations using FASTSRT: </li></ul><ul><ul><li>One program that processed 100,000 records was 35% faster when using FASTSRT compared to using NOFASTSRT. </li></ul></ul>
    46. 46. NUMPROC - NOPFD, MIG, or PFD – 1 of 2 <ul><li>Using the NUMPROC(PFD) compiler option generates significantly more efficient code for numeric comparisons. </li></ul><ul><li>It also avoids the generation of extra code that NUMPROC(NOPFD) or NUMPROC(MIG) generates for most references to COMP-3 and DISPLAY numeric data items to ensure a correct sign is being used. </li></ul><ul><ul><li>With NUMPROC(NOPFD), sign fix-up processing is done for all references to these numeric data items. </li></ul></ul><ul><ul><li>With NUMPROC(MIG), sign fix-up processing is done only for receiving fields (and not for sending fields) of arithmetic and MOVE statements. </li></ul></ul><ul><ul><li>With NUMPROC(PFD), the compiler assumes that the data has the correct sign and bypasses this sign fix-up processing </li></ul></ul>
    47. 47. NUMPROC - NOPFD, MIG, or PFD – 2 of 2 <ul><li>NUMPROC(MIG) generates code that is similar to that of OS/VS COBOL. </li></ul><ul><li>Using NUMPROC(NOPFD) or NUMPROC(MIG) may also inhibit some other types of optimization. </li></ul><ul><li>However, not all external data files contain the proper sign for COMP-3 or DISPLAY signed numeric data, and hence, using NUMPROC(PFD) may not be applicable for all application programs. </li></ul><ul><li>For performance sensitive applications, NUMPROC(PFD) is recommended when possible. </li></ul><ul><li>Performance considerations using NUMPROC: </li></ul><ul><ul><li>On the average, NUMPROC(PFD) was 1% faster than NUMPROC(NOPFD), with a range of 20% faster to equivalent. </li></ul></ul><ul><ul><li>On the average, NUMPROC(PFD) was 1% faster than NUMPROC(MIG), with a range of 9% faster to equivalent. </li></ul></ul><ul><ul><li>On the average, NUMPROC(MIG) was equivalent to NUMPROC(NOPFD), with a range of 13% faster to equivalent. </li></ul></ul>
    48. 48. OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE – 1 of 3 <ul><li>To assist in the optimization of the code, you should use the OPTIMIZE compiler option. </li></ul><ul><li>With the OPTIMIZE(STD) or OPTIMIZE(FULL) options in effect, you may receive optimizations that include: </li></ul><ul><ul><li>eliminating unnecessary branches </li></ul></ul><ul><ul><li>simplifying inefficient branches </li></ul></ul><ul><ul><li>simplifying the code for the out-of-line PERFORM statement, moving the performed paragraphs in-line, where possible </li></ul></ul><ul><ul><li>simplifying the code for a CALL to a contained (nested) program, moving the called statements in-line, where possible </li></ul></ul><ul><ul><li>eliminating duplicate computations </li></ul></ul><ul><ul><li>eliminating constant computations </li></ul></ul><ul><ul><li>aggregating moves of contiguous, equal-sized items into a single move </li></ul></ul><ul><ul><li>deleting unreachable code </li></ul></ul>
    49. 49. OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE – 2 of 3 <ul><li>Additionally, with the OPTIMIZE(FULL) option in effect, you may also receive these optimizations: </li></ul><ul><ul><li>deleting unreferenced data items and the associated code to initialize their VALUE clauses </li></ul></ul><ul><li>Many of these optimizations are not available with OS/VS COBOL, but are available with IBM Enterprise COBOL. </li></ul><ul><li>Application Development Considerations: </li></ul><ul><ul><li>NOOPTIMIZE is generally used while a program is being developed when frequent compiles are necessary. </li></ul></ul><ul><ul><li>NOOPTIMIZE also makes it easier to debug a program since code is not moved; </li></ul></ul><ul><ul><li>NOOPTIMIZE is required when using the TEST compiler option with a value other than TEST(NONE). </li></ul></ul><ul><ul><li>OPTIMIZE requires more CPU time for compiles than NOOPTIMIZE, but generally produces more efficient run-time code. </li></ul></ul><ul><ul><li>For production runs, OPTIMIZE is recommended. </li></ul></ul>
    50. 50. OPTIMIZE(STD), OPTIMIZE(FULL), or NOOPTIMIZE – 3 of 3 <ul><li>WARNING: </li></ul><ul><ul><li>If your program relies upon unreferenced level 01 or level 77 data items, you should not use OPTIMIZE(FULL), since OPTIMIZE(FULL) will delete all unreferenced data items. </li></ul></ul><ul><li>One way to prevent the data item from being deleted by the OPTIMIZE(FULL) option is to refer to the data item in the PROCEDURE DIVISION </li></ul><ul><ul><li>For example, initialize the data item with a PROCEDURE DIVISION statement instead of with VALUE clauses). </li></ul></ul><ul><li>Performance considerations using OPTIMIZE: </li></ul><ul><ul><li>On the average, OPTIMIZE(STD) was 1% faster than NOOPTIMIZE, with a range of 12% faster to equivalent. </li></ul></ul><ul><ul><li>On the average, OPTIMIZE(FULL) was equivalent to OPTIMIZE(STD). </li></ul></ul><ul><ul><li>One RENT program calling a RENT subprogram with 500 unreferenced data items with VALUE clauses was 9% faster with OPTIMIZE(FULL) or OPT(STD) compared to NOOPT. </li></ul></ul><ul><ul><li>The same RENT program calling a RENT subprogram with 500 unreferenced data items with VALUE clauses using the IS INITIAL clause on the PROGRAM-ID statement was 90% faster with OPTIMIZE(FULL) compared to OPT(STD). </li></ul></ul>
    51. 51. RENT or NORENT <ul><li>Using the RENT compiler option causes the compiler to generate some additional code to ensure that the program is reentrant. </li></ul><ul><li>Reentrant programs can be placed in shared storage like the Link Pack Area (LPA) or the Extended Link Pack Area (ELPA). </li></ul><ul><li>Also, the RENT option will allow the program to run above the 16 MB line. </li></ul><ul><li>Producing reentrant code may increase the execution time path length slightly. </li></ul><ul><li>Note: The RMODE(ANY) option can be used to run NORENT programs above the 16 MB line. </li></ul><ul><li>Performance considerations using RENT: </li></ul><ul><ul><li>On the average, RENT was equivalent to NORENT. </li></ul></ul>
    52. 52. RMODE - AUTO, 24, or ANY <ul><li>The RMODE compiler option determines the RMODE setting for the COBOL program. </li></ul><ul><li>When using RMODE(AUTO), the RMODE setting depends on the use of RENT or NORENT. </li></ul><ul><li>For RENT, the program will have RMODE ANY. For NORENT, the program will have RMODE 24. </li></ul><ul><li>When using RMODE(24), the program will always have RMODE 24. When using RMODE(ANY), the program will always have RMODE ANY. </li></ul><ul><li>Note: When using NORENT, the RMODE option controls where the WORKING-STORAGE will reside. </li></ul><ul><ul><li>With RMODE(24), the WORKING-STORAGE will be below the 16 MB line. </li></ul></ul><ul><ul><li>With RMODE(ANY), the WORKING-STORAGE can be above the 16 MB line. </li></ul></ul>
    53. 53. SSRANGE or NOSSRANGE <ul><li>Using SSRANGE generates additional code to verify that all subscripts, indexes, and reference modification expressions do not refer to data beyond the bounds of the subject data item. </li></ul><ul><li>This in-line code occurs at every reference to a subscripted or variable-length data item, as well as at every reference modification expression, and it can result in some degradation at run time. </li></ul><ul><li>In general, if you need to verify the subscripts only a few times in the application instead of at every reference, coding your own checks may be faster than using the SSRANGE option. </li></ul><ul><li>For performance sensitive applications, NOSSRANGE is recommended (see prior discussion of this in the coding section of this course) </li></ul><ul><li>Performance considerations using SSRANGE: </li></ul><ul><ul><li>On the average, SSRANGE with the run-time option CHECK(ON) was 1% slower than NOSSRANGE, with a range of equivalent to 27% slower. </li></ul></ul><ul><ul><li>On the average, SSRANGE with the run-time option CHECK(OFF) was 1% slower than NOSSRANGE, with a range of equivalent to 9% slower. </li></ul></ul><ul><ul><li>On the average, SSRANGE with the run-time option CHECK(ON) was 1% slower than SSRANGE with the run-time option CHECK(OFF) with a range of equivalent to 16% slower. </li></ul></ul>
    54. 54. TEST or NOTEST – 1 of 3 <ul><li>The TEST compiler option produces object code that enables Debug Tool to perform batch and interactive debugging. </li></ul><ul><li>The amount of debugging support available depends on which TEST sub-options you use. </li></ul><ul><li>The TEST option also allows you to request that symbolic variables be included in the formatted dump produced by Language Environment. </li></ul><ul><li>When using the SYM suboption of the TEST option, you can control where the symbolic information will be kept. </li></ul><ul><li>If you use TEST(,SYM,NOSEPARATE), the symbolic information will be part of the object module, which could result in a much larger object module. </li></ul><ul><li>If you use TEST(,SYM,SEPARATE), the symbolic information will be placed in a separate file and will be loaded only as needed. </li></ul><ul><li>Note: If you used the FDUMP option with VS COBOL II, TEST(NONE,SYM) is the equivalent option with IBM Enterprise COBOL. </li></ul>
    55. 55. TEST or NOTEST – 2 of 3 <ul><li>Using TEST with a value other than NONE can cause a significant performance degradation when used in a production environment since this additional code occurs at each COBOL statement. </li></ul><ul><ul><li>Hence, the TEST option with a value other than NONE should be used only when debugging an application. </li></ul></ul><ul><ul><li>Additionally, when TEST is used with a value other than NONE, the OPTIMIZE option is disabled. </li></ul></ul><ul><li>For production runs, NOTEST or TEST(NONE) is recommended. </li></ul><ul><li>Notes: </li></ul><ul><ul><li>With the latest levels of Debug Tool, you can step through your program even if there are no compiled-in hooks, by using the overlay hooks function of Debug Tool. </li></ul></ul><ul><ul><li>However, you must compile with the NOOPTIMIZE and TEST(NONE) options to use this feature. </li></ul></ul><ul><ul><li>You should also use the SYM and SEPARATE sub-options of TEST to get the symbolic debug information without substantially increasing the size of your load modules. </li></ul></ul><ul><ul><li>Additionally, when using TEST(NONE,SYM) with a large data division and an abend occurs producing a CEEDUMP, a significant amount of CPU time may be required to produce the CEEDUMP, depending on the size of the data division. </li></ul></ul>
    56. 56. TEST or NOTEST – 3 of 3 <ul><li>Performance considerations using TEST: </li></ul><ul><ul><li>On the average, TEST(ALL,SYM) was 20% slower than NOTEST, with a range of equivalent to 200% slower when not producing a CEEDUMP. </li></ul></ul><ul><ul><li>On the average, TEST(NONE,SYM) was equivalent to NOTEST when not producing a CEEDUMP. </li></ul></ul><ul><ul><li>On the average, TEST(NONE,SYM,NOSEPARATE) resulted in a 236% increase in the object module size compared to using NOTEST or TEST(NONE,SYM,SEPARATE), with a range of 9% larger to 670% larger. </li></ul></ul><ul><ul><li>On the average, TEST(NONE,SYM,SEPARATE) resulted in an increase of approximately 200 bytes in the object module size compared to using NOTEST </li></ul></ul><ul><ul><li>One program with a large data division (about 1 million items) using TEST(NONE,SYM) took 200 times more CPU time to produce a CEEDUMP with COBOL's formatted variables compared to using NOTEST to produce a CEEDUMP without COBOL's formatted variables. </li></ul></ul>
    57. 57. THREAD or NOTHREAD <ul><li>The THREAD compiler option enables the COBOL program for execution in a Language Environment enclave with multiple POSIX threads or PL/I tasks. </li></ul><ul><li>A program compiled with the THREAD compiler option can also run in a non-threaded environment, however there will be some degradation in the initialization and termination of the COBOL program due to the overhead of serialization logic that is done for these programs. </li></ul><ul><li>The THREAD compiler option also requires the use of the IS RECURSIVE clause on the PROGRAM-ID statement. </li></ul><ul><li>Performance considerations using THREAD (measuring CALL overhead only): </li></ul><ul><ul><li>One testcase (Assembler calling COBOL) using THREAD was 35% slower than using NOTHREAD. </li></ul></ul><ul><ul><li>One testcase (COBOL statically calling COBOL) using THREAD was 30% slower than using NOTHREAD. </li></ul></ul><ul><ul><li>One testcase (COBOL dynamically calling COBOL) using THREAD was 30% slower than using NOTHREAD. </li></ul></ul><ul><li>Note: </li></ul><ul><ul><li>The IS RECURSIVE clause was used in both the THREAD and NOTHREAD cases. </li></ul></ul>
    58. 58. TRUNC - BIN, STD, or OPT – 1 of 3 <ul><li>When using the TRUNC(BIN) compiler option, all binary (COMP) sending fields are treated as either half-word, full-word, or double-word values, depending on the PICTURE clause, and code is generated to truncate all binary receiving fields to the corresponding half-word, full-word, or double-word boundary (base 2 truncation). </li></ul><ul><li>The full content of the field is significant. </li></ul><ul><li>This can add a significant amount of degradation since typically some data conversions must be done, which may require the use of some library subroutines. </li></ul><ul><li>Considerations: </li></ul><ul><ul><li>BIN is usually the slowest of the three sub options for TRUNC. </li></ul></ul><ul><ul><li>When using the TRUNC(STD) compiler option, the final intermediate result of an arithmetic expression, or the sending field in the MOVE statement, is truncated to the number of digits in the PICTURE clause of the binary (COMP) receiving field (base 10 truncation). </li></ul></ul><ul><ul><ul><li>This can add a significant amount of degradation since typically the number is divided by some power of ten (depending on the number of digits in the PICTURE clause) and the remainder is used; a divide instruction is one of the more expensive instructions. </li></ul></ul></ul><ul><ul><li>TRUNC(STD) behaves in a similar way as TRUNC in OS/VS COBOL. </li></ul></ul>
    59. 59. TRUNC - BIN, STD, or OPT – 2 of 3 <ul><li>However, with TRUNC(OPT), the compiler assumes that the data conforms to the PICTURE and USAGE specifications and manipulates the result based on the size of the field in storage (half-word, full-word or double-word). </li></ul><ul><li>Although TRUNC(OPT) most closely resembles the behavior of NOTRUNC in OS/VS COBOL and is recommended for compatibility with NOTRUNC, there are some cases where the result will be different. </li></ul><ul><li>Please consult the COBOL Migration Guide and Programming Guide for additional details. </li></ul><ul><ul><li>TRUNC(STD) conforms to the ANSI and SAA standards, whereas TRUNC(BIN) and TRUNC(OPT) do not. </li></ul></ul><ul><ul><li>TRUNC(OPT) is provided as a performance tuning option and should be used only when the data in the application program conforms to the PICTURE and USAGE specifications. </li></ul></ul><ul><li>For performance sensitive applications, the use of TRUNC(OPT) is recommended when possible. </li></ul>
    60. 60. TRUNC - BIN, STD, or OPT – 3 of 3 <ul><li>Performance considerations using TRUNC: </li></ul><ul><ul><li>On the average, TRUNC(OPT) was 24% faster than TRUNC(BIN), with a range of 88% faster to equivalent. </li></ul></ul><ul><ul><li>On the average, TRUNC(STD) was 15% faster than TRUNC(BIN), with a range of 78% faster to equivalent. </li></ul></ul><ul><ul><li>On the average, TRUNC(OPT) was 6% faster than TRUNC(STD), with a range of 65% faster to equivalent. </li></ul></ul><ul><li>Note: </li></ul><ul><ul><li>On the average, TRUNC(BIN) with COBOL for OS/390 & VM Version 2 Release 2 and later is 15% faster than TRUNC(BIN) with COBOL for OS/390 & VM Version 2 Release 1 and prior, with a range of equivalent to 95% faster. </li></ul></ul><ul><ul><ul><li>BEFORE: on the average, 2.1.0 compiler with TRUNC(BIN) was 4.8 times slower than TRUNC(OPT), with a max of 30 times slower </li></ul></ul></ul><ul><ul><ul><li>AFTER: on the average, 2.2.0 compiler with TRUNC(BIN) was 1.8 times slower than TRUNC(OPT), with a max of 13 times slower </li></ul></ul></ul>
    61. 61. Summary <ul><li>Having finished this section, you should now be able to: </li></ul><ul><ul><li>Select the proper compiler options is another factor that affects the performance of a COBOL application. </li></ul></ul>
    62. 62. Checkpoint <ul><li>Under construction </li></ul>
    63. 63. Compiler Directives Course <ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options that Affect Run-time Performance </li></ul><ul><li>Efficient COBOL Coding Techniques </li></ul><ul><li>Appendices </li></ul>Units:
    64. 64. Overview <ul><li>Selecting the proper run-time options is another factor that affects the performance of a COBOL application. </li></ul><ul><li>Therefore, it is important for the system programmer responsible for installing and setting up the LE environment to work with the application programmers so that the proper run-time options are set up correctly for your installation. </li></ul><ul><li>Let's look at some of the options that can help to improve the performance of the individual application, as well as the overall LE run-time environment. </li></ul>
    65. 65. AIXBLD <ul><li>The AIXBLD option allows alternate indexes to be built at run time. </li></ul><ul><li>However, this may adversely affect the run-time performance of the application. </li></ul><ul><li>It is much more efficient to use Access Method Services to build the alternate indexes before running the COBOL application than using the NOAIXBLD run-time option. </li></ul><ul><li>Note that AIXBLD is not supported when VSAM datasets are accessed in RLS mode. </li></ul><ul><li>Performance considerations using AIXBLD: </li></ul><ul><ul><li>One VSAM program was 8% slower when using AIXBLD compared to using NOAIXBLD. </li></ul></ul>
    66. 66. ALL31 – 1 of 2 <ul><li>The ALL31 option allows LE to take advantage of knowing that there are no AMODE(24) routines in the application. </li></ul><ul><li>ALL31(ON) specifies that the entire application will run in AMODE(31). </li></ul><ul><li>This can help to improve the performance for an all AMODE(31) application because LE can minimize the amount of mode switching across calls to common run-time library routines. </li></ul><ul><li>Additionally, using ALL31(ON) will help to relieve some below the line virtual storage constraint problems, since less below the line storage is used. </li></ul><ul><ul><li>ALL31(ON) </li></ul></ul><ul><ul><ul><li>All EXTERNAL WORKING-STORAGE and EXTERNAL FD records areas can be allocated above the 16MB line if you also use the HEAP(,,ANYWHERE) run-time option and compile the program with either the DATA(31) and RENT compiler options or with the RMODE(ANY) and NORENT compiler options. </li></ul></ul></ul><ul><ul><li>ALL31(OFF) is required for all OS/VS COBOL programs that are not running under CICS, all VS COBOL II NORES programs, and all other AMODE(24) programs. </li></ul></ul>
    67. 67. ALL31 – 2 of 2 <ul><li>Note that when using ALL31(OFF), you must also use STACK(,,BELOW). </li></ul><ul><li>Note: </li></ul><ul><ul><li>Beginning with LE for z/OS Release 1.2, the run-time defaults have changed to </li></ul></ul><ul><ul><ul><li>ALL31(ON),STACK(,,ANY). </li></ul></ul></ul><ul><ul><ul><li>LE for OS/390 Release 2.10 and earlier run-time defaults were ALL31(OFF),STACK(,,BELOW). </li></ul></ul></ul><ul><li>Performance considerations using ALL31 (measuring CALL overhead only): </li></ul><ul><ul><li>On the average, ALL31(ON) was equivalent to ALL31(OFF). </li></ul></ul><ul><ul><li>One program with many library routine calls was 10% faster when using ALL31(ON). </li></ul></ul>
    68. 68. CHECK <ul><li>The CHECK option activates the additional code generated by the SSRANGE compiler option, which requires more CPU time resources for the verification of the subscripts, indexes, and reference modification expressions. </li></ul><ul><li>Using the CHECK(OFF) run-time option deactivates this code but still requires some additional CPU time resources at every use of a subscript, index, or reference modification expression to determine that this check is not desired during the particular run of the program. </li></ul><ul><li>This option has an effect only on a program that has been compiled with the SSRANGE compiler option. </li></ul><ul><li>Performance considerations using CHECK: </li></ul><ul><ul><li>On the average, CHECK(ON) with SSRANGE was 1% slower than CHECK(OFF) with SSRANGE, </li></ul></ul><ul><ul><li>With a range of equivalent to 16% slower. </li></ul></ul>
    69. 69. DEBUG <ul><li>The DEBUG option activates the COBOL batch debugging features specified by the USE FOR DEBUGGING declarative. </li></ul><ul><li>This may add some additional overhead to process the debugging statements. </li></ul><ul><li>This option has an effect only on a program that has the USE FOR DEBUGGING declarative. </li></ul><ul><li>Performance considerations using DEBUG: </li></ul><ul><ul><li>The eleven programs measured ranged from equivalent to 2080% slower when using DEBUG compared to using NODEBUG. </li></ul></ul><ul><li>Notes: </li></ul><ul><ul><li>The programs measured in this test were modified to use WITH DEBUGGING MODE on the SOURCE-COMPUTER paragraph and to contain a USE FOR DEBUGGING ON ALL PROCEDURES declarative that did a DISPLAY DEBUG-ITEM. </li></ul></ul><ul><ul><li>Since the debugging code in these cases is generated only for paragraph and section labels, other programs may have significantly different results. </li></ul></ul>
    70. 70. RPTOPTS , RPTSTG <ul><li>The RPTOPTS option allows you to get a report of the run-time options that were in use during the execution of an application. Generating the report can result in some additional overhead. Specifying RPTOPTS(OFF) will eliminate this overhead. </li></ul><ul><ul><li>For batch: On the average, RPTOPTS(ON) was equivalent to RPTOPTS(OFF). </li></ul></ul><ul><ul><ul><li>Note: Although the average for batch programs shows equivalent performance for RPTOPTS(ON), you may experience some degradation in a transaction environment (for example, CICS) where main programs are repeatedly invoked. </li></ul></ul></ul><ul><li>The RPTSTG option allows you to get a report on the storage that was used by an application. This report is produced after the application has terminated. </li></ul><ul><li>The data from this report can help you fine tune the storage parameters for the application, reducing the number of times that the LE storage manager must make system requests to acquire or free storage. </li></ul><ul><li>Collecting the data and generating the report can result in some additional overhead. Specifying RPTSTG(OFF) will eliminate this overhead. </li></ul><ul><ul><li>On the average, RPTSTG(ON) was 5% slower than RPTSTG(OFF), with a range of equivalent to 88% slower. </li></ul></ul><ul><ul><li>Note that when using call intensive applications, the degradation can be 200% slower or more. </li></ul></ul>
    71. 71. RTEREUS – 1 of 2 <ul><li>The RTEREUS option causes the LE run-time environment to be initialized for reusability when the first COBOL program is invoked. </li></ul><ul><li>The LE run-time environment remains initialized (all COBOL programs and their work areas are kept in storage) in addition to keeping the library routines initialized and in storage. </li></ul><ul><li>This means that, for subsequent invocations of COBOL programs, most of the run-time environment initialization will be bypassed. Most of the run-time termination will also be bypassed, unless a STOP RUN is executed or unless an explicit call to terminate the environment is made </li></ul><ul><ul><li>Note: using STOP RUN results in control being returned to the caller of the routine that invoked the first COBOL program, terminating the reusable run-time environment). </li></ul></ul><ul><ul><li>Because of the effect that the STOP RUN statement has on the run-time environment, you should change all STOP RUN statements to GOBACK statements in order to get the benefit of RTEREUS. </li></ul></ul><ul><li>The most noticeable impact will be on the performance of a non-COBOL driver repeatedly calling a COBOL subprogram (for example, an assembler driver that repeatedly calls COBOL applications). </li></ul><ul><li>The RTEREUS option helps in this case. </li></ul>
    72. 72. RTEREUS – 2 of 2 <ul><li>However, using the RTEREUS option does affect the semantics of the COBOL application: </li></ul><ul><ul><li>each COBOL program will now be considered to be a subprogram and will be entered in its last-used state on subsequent invocations </li></ul></ul><ul><ul><li>if you want the program to be entered in its initial state, you can use the INITIAL clause on the PROGRAM-ID statement. </li></ul></ul><ul><ul><li>WARNING: This means that storage that is acquired during the execution of the application will not be freed. Therefore, RTEREUS may not be applicable to all environments. </li></ul></ul><ul><li>Performance considerations using RTEREUS (measuring CALL overhead only): </li></ul><ul><ul><li>One test-case (Assembler calling COBOL) using RTEREUS was 99% faster than using NORTEREUS. </li></ul></ul>
    73. 73. Modifying COBOL's Reusable Environment Behavior – 1 of 2 <ul><li>Using the IGZRREOP customization job can be used to improve the performance of running in a COBOL reusable environment. REUSENV=COMPAT provides behavior that is compatible with VS COBOL II's reusable environment. </li></ul><ul><li>With this setting, when a program check occurs while the COBOL reusable environment is dormant (i.e., after returning from the topmost COBOL program back to the non-Language Environment conforming assembler caller), a S0Cx abend will occur, but it significantly affects the performance of a such an application running under Language Environment. </li></ul><ul><li>This degradation is due to an ESPIE RESET being issued prior to the return from COBOL to the assembler driver and then an ESPIE SET upon each re-entry to the topmost COBOL program. </li></ul>
    74. 74. Modifying COBOL's Reusable Environment Behavior – 2 of 2 <ul><li>REUSENV=OPT changes this behavior by allowing Language Environment to trap all program checks, including those that occur while the COBOL reusable environment is dormant. </li></ul><ul><li>This option provides behavior that is not the same as VS COBOL II and will result in an abend 4036 if a program check occurs while the COBOL reusable environment is dormant. </li></ul><ul><li>However, since an ESPIE RESET and ESPIE SET do not have to be issued between each invocation of the topmost COBOL program, performance will be improved over using REUSENV=COMPAT. </li></ul><ul><li>Sample source code to make these changes is in members IGZERREO and IGZWARRE of the SCEESAMP dataset. </li></ul><ul><li>Performance considerations using IGZRREOP: </li></ul><ul><ul><li>When using IGZRREOP with REUSENV=OPT, assembler programs calling COBOL programs repeatedly under COBOL's reusable run-time environment can be 60 to 90% faster than using IGZRREOP with REUSENV=COMPAT. </li></ul></ul>
    75. 75. STORAGE – 1 of 2 <ul><li>The first parameter of this option initializes all heap allocations, including all external data records acquired by a program, to the specified value when the storage for the external data is allocated. </li></ul><ul><li>This also includes the WORKING-STORAGE acquired by a RENT program (unless a VALUE clause is used on the dataitem) when the program is first called or, for dynamic calls, when the program is canceled and then called again. </li></ul><ul><li>Storage is not initialized on subsequent calls to the program. This can result in some overhead at runtime depending on the number of external data records in the program and the size of the WORKING-STORAGE section. </li></ul><ul><li>Note: </li></ul><ul><ul><li>If you used the WSCLEAR option with VS COBOL II, STORAGE(00,NONE,NONE) is the equivalent option with Language Environment. </li></ul></ul><ul><ul><li>The second parameter of this option initializes all heap storage when it is freed. </li></ul></ul><ul><ul><li>The third parameter of this option initializes all DSA (stack) storage when it is allocated. The amount of overhead depends on the number of routines called (subroutines and library routines) and the amount of LOCAL-STORAGE data items that are used. This can have a significant impact on the CPU time of an application that is call intensive. </li></ul></ul>
    76. 76. STORAGE – 2 of 2 <ul><li>Performance considerations using STORAGE: </li></ul><ul><ul><li>On the average, STORAGE(00,00,00) was 17% slower than STORAGE(NONE,NONE,NONE), with a range of equivalent to 130% slower. </li></ul></ul><ul><ul><ul><li>One RENT program calling a RENT subprogram using IS INITIAL on the PROGRAM-ID statement with a 40 MB WORKING-STORAGE was 28% slower. </li></ul></ul></ul><ul><ul><ul><li>Note that when using call intensive applications, the degradation can be 200% slower or more. </li></ul></ul></ul><ul><ul><li>On the average, STORAGE(00,NONE,NONE) was equivalent to STORAGE(NONE,NONE,NONE). </li></ul></ul><ul><ul><ul><li>One RENT program calling a RENT subprogram using IS INITIAL on the PROGRAM-ID statement with a 40 MB WORKING-STORAGE was 4% slower. </li></ul></ul></ul><ul><ul><li>On the average, STORAGE(NONE,00,NONE) was equivalent to STORAGE(NONE,NONE,NONE). </li></ul></ul><ul><ul><ul><li>One RENT program calling a RENT subprogram using IS INITIAL on the PROGRAM-ID statement with a 40 MB WORKING-STORAGE was 13% slower. </li></ul></ul></ul><ul><ul><li>On the average, STORAGE(NONE,NONE,00) was 17% slower than STORAGE(NONE,NONE,NONE), with a range of equivalent to 130% slower. </li></ul></ul><ul><ul><ul><li>One RENT program calling a RENT subprogram using IS INITIAL on the PROGRAM-ID statement with a 40 MB WORKING-STORAGE was 6% slower. Note that when using call intensive applications, the degradation can be 200% slower or more. </li></ul></ul></ul>
    77. 77. TEST <ul><li>The TEST option specifies the conditions under which Debug Tool assumes control when the user application </li></ul><ul><li>is invoked. Since this may result in Debug Tool being initialized and invoked, there may be some additional </li></ul><ul><li>overhead when using TEST. Specifying NOTEST will eliminate this overhead. </li></ul>
    78. 78. TRAP <ul><li>The TRAP option allows LE to intercept an abnormal termination (abend), provide the abend information, and then terminate the LE run-time environment. </li></ul><ul><li>TRAP(ON) also assures that all files are closed when an abend is encountered and is required for proper handling of the ON SIZE ERROR clause of arithmetic statements for overflow conditions. </li></ul><ul><li>TRAP(OFF) prevents LE from intercepting the abend. </li></ul><ul><li>In general there will not be any significant impact on the performance of a COBOL application when using TRAP(ON). </li></ul><ul><li>Performance considerations using TRAP: </li></ul><ul><ul><li>On the average, TRAP(ON) was equivalent to TRAP(OFF). </li></ul></ul>
    79. 79. Other Tuning Options Course <ul><li>Using an Optimal Programming Style </li></ul><ul><li>Choosing Efficient Datatypes </li></ul><ul><li>Handling Tables Efficiently </li></ul><ul><li>Compiler Options that Affect Run-time Performance </li></ul><ul><li>Run-time Options that Affect Run-time Performance </li></ul><ul><li>Efficient COBOL Coding Techniques </li></ul><ul><li>Tuning CICS, IMS, DB2 and VSAM Access </li></ul><ul><li>Appendices </li></ul>Units:
    80. 80. Running efficiently with CICS, IMS, or VSAM <ul><li>You can improve performance for online programs running under CICS or IMS, or programs that use VSAM, by following these tips. </li></ul><ul><ul><li>CICS: If your application runs under CICS, convert EXEC CICS LINK commands to COBOL CALL statements to improve transaction response time. </li></ul></ul><ul><ul><li>IMS: If your application runs under IMS, preloading the application program and the library routines can help reduce the overhead of loading and searching. It can also reduce the input-output activity. </li></ul></ul><ul><ul><ul><li>For better system performance, use the RENT compiler option and preload the applications and library routines when possible. You can also use the Language Environment library routine retention (LRR) function to improve performance in IMS/TM regions. </li></ul></ul></ul><ul><ul><li>VSAM: When you use VSAM files, increase the number of data buffers for sequential access or index buffers for random access. Also, select a control interval size (CISZ) that is appropriate for the application. A smaller CISZ results in faster retrieval for random processing at the expense of inserts. A larger CISZ is more efficient for sequential processing. </li></ul></ul><ul><ul><ul><li>For better performance, access the records sequentially and avoid using multiple alternate indexes when possible. If you use alternate indexes, access method services builds them more efficiently than the AIXBLD runtime option. </li></ul></ul></ul>
    81. 81. Improving VSAM performance – 1 of 2 <ul><li>Your system programmer is most likely responsible for tuning the performance of COBOL and VSAM. As an application programmer, you can control the aspects of VSAM that are listed below. </li></ul>
    82. 82. Improving VSAM performance – 1 of 2 <ul><li>Application methods for improving VSAM performance …. </li></ul>
    83. 83. SQL Performance – 1 of 3 <ul><li> SQL Performance is a very big topic. If you are responsible for writing EGL code that must generate to high-performance SQL database access statements you should research this topic on the Internet, and with books written by experts such as Joe Celko and Craig Mullins (among others) </li></ul><ul><li>Background </li></ul><ul><li>SQL efficiency is a direct correlation to the # of rows physically accessed by the DBMS versus the # of rows needed by your business logic. As an example, if a list page only displays 10 rows at a time, but accesses 2,000 rows from the database per execution of the SQL function this is probably inefficient. However, if a batch process needs 225,000 rows for its business process, and accesses 300,000 rows to get them, this is relatively efficient. It’s the correlation of # of rows needed, versus DBMS work-to-be-done to get those rows that is the true measure of SQL efficiency. </li></ul><ul><li>In order to determine the above, you must fully understand the service level requirements for your database access. Typically, you are concerned with web-page performance and user-wait time. Problems with pages occur when the SQL run to access the data for the page returns thousands (or tens or hundreds of thousands of rows). </li></ul><ul><li>So, you will need to understand both the logical AND physical structure of your database – and its choices of data access, in order to completely understand how much effort it takes the database to get the data you need. This can be (read, “usually is”) a very complex and time-consuming process, unique to every different business application </li></ul><ul><li>The best we can do in this tutorial is to give you general rules-of-thumb that will make queries “more” efficient. However, it is strongly recommended that you discuss this with your systems database administrator (DBA) – for any/all pages that require maximum SQL performance </li></ul><ul><li>Note that there is no end of decent SQL performance articles – mostly database-specific on this topic available freely on the internet – and a # of good books as well. </li></ul><ul><ul><li>http://www-128.ibm.com/developerworks/db2/library/techarticle/0210mullins/0210mullins.html </li></ul></ul><ul><ul><li>http://www.javaworld.com/javaworld/jw-02-2005/jw-0228-apm.html </li></ul></ul>
    84. 84. SQL Performance – Rules of Thumb – 2 of 3 <ul><li>For Batch applications that process all or a significant % of table rows, index access is often inefficient. This is because the database must first read the index dataset – then read the table dataset to retrieve each row. Index access is efficient only when your SQL requirements are for a small percentage of the entire table: (typically less than 20%). </li></ul><ul><li>For online/pages </li></ul><ul><ul><li>Attempt to limit the number of rows retrieved per get statement to the minimum needed per page view. This will require you to do at least two things (neither of which are easy or quick): </li></ul></ul><ul><ul><ul><li>Add additional WHERE clause conditions using SQL BETWEEN that reference database index columns – and in your EGL code manage the values so that the database is retrieving as close to the # of records needed per page view as possible </li></ul></ul></ul><ul><ul><ul><li>Code your own programmatic paging – by incrementing the values in the SQL BETWEEN clauses per page forward – and decrement the values for page backward. </li></ul></ul></ul><ul><ul><li>Separate the database access from the page fields by using basicRecords to render the fields. In this tutorial, you have primarily dragged and dropped database records onto a form. This is not as efficient as doing the database access through sqlRecords, then moving the records return </li></ul></ul><ul><ul><li>Using explicit SQL, select only the # of columns you need in your page view (i.e. if you are only showing 4 fields tied to a 30 column table row, delete the other 26 columns. </li></ul></ul><ul><ul><li>Attempt to avoid ORDER BY unless it is on an indexed column AND the index exists in the same order you need for your sort process. Obviously this is driven by the business requirements, but database sorting can be very expensive. Statements that force sorts include: </li></ul></ul><ul><ul><ul><li>ORDER BY </li></ul></ul></ul><ul><ul><ul><li>GROUP BY </li></ul></ul></ul><ul><ul><ul><li>TABLE JOINS </li></ul></ul></ul><ul><ul><ul><li>UNION </li></ul></ul></ul><ul><ul><ul><li>Certain Sub-selects </li></ul></ul></ul><ul><ul><li>Avoid using SQL WHERE clause keywords that disallow index access </li></ul></ul><ul><ul><ul><li>Computations in the where clause </li></ul></ul></ul><ul><ul><ul><li>Like – with the % or underscore before the literal data </li></ul></ul></ul>
    85. 85. SQL Performance – Rules of Thumb – 3 of 3 <ul><li>Use custom SQLRecords to limit the number of: </li></ul><ul><ul><li>Rows returned for SQL queries </li></ul></ul><ul><ul><ul><li>Use Programmatic Paging for SELECT statements that would return > 200 rows </li></ul></ul></ul><ul><ul><li>Columns of information </li></ul></ul><ul><ul><ul><li>Create custom SQLRecords that only access the information needed by your page </li></ul></ul></ul><ul><li>Attempt to limit the number of JSF dataTable cells rendered by EGL/JSF </li></ul><ul><ul><li>A cell is the intersection of a row and column in a dataTable, so that if you have 5,000 rows and 20 columns, you generating 100,000 cells. This will almost definitely cause severe page performance problems. As a rule of thumb, keep the number of total cells under 10,000 (i.e. 500 rows/20 columns), etc. Large-scale SQL performance improvements have been documented by so doing. </li></ul></ul><ul><li>SQL Stored Procedures will always out-perform dynamic SQL access. So for your ultra-performance-intensive pages, consider using SQL Stored Procedures. This has been well-documented in IBM Redbooks </li></ul><ul><li>Use the EGL MAXSIZE property - to halt the fetch process from the database on potentially large queries. MAXSIZE, which you specify as a property of a dynamic array interacts with the database engine’s fetch looping, and once reached, closes the cursor and stops the database access process. You should note that the majority of the cost of the database access occurs when a cursor is OPEN’d. However, if your page only renders 10 rows at a time, and you are doing programmatic paging, specifying MAXSIZE = 10 will help performance – somewhat </li></ul><ul><li>Use any of your DBMS’s SQL efficiency features. For example DB2 has several keywords that influence the Optimizer to access a stated # of rows: </li></ul><ul><ul><li>OPTIMIZE FOR n ROWS; //tells the optimizer you will probably only fetch n rows </li></ul></ul><ul><ul><li>FETCH FIRST n ROWS ONLY; //tells the optimizer you will ONLY fetch n rows </li></ul></ul><ul><ul><li>FOR READ ONLY //tells the optimizer you will not do any update where current of commands </li></ul></ul><ul><ul><li>WITH UR //allows you to read uncommitted rows </li></ul></ul>
    86. 86. Grouping duplicate computations*** (probably remove) <ul><li>When components of different expressions are duplicates, ensure that the compiler is able to optimize them. For arithmetic expressions, the compiler is bound by the left-to-right evaluation rules of COBOL. </li></ul><ul><li>Therefore, either move all the duplicates to the left side of the expressions or group them inside parentheses. </li></ul><ul><li>If V1 through V5 are variables, the computation V2 * V3 * V4 is a duplicate (known as a common sub-expression) in the following two statements: </li></ul><ul><ul><li>COMPUTE A = V1 * (V2 * V3 * V4) COMPUTE B = V2 * V3 * V4 * V5 </li></ul></ul><ul><li>In the following example, V2 + V3 is a common sub-expression: </li></ul><ul><ul><li>COMPUTE C = V1 + (V2 + V3) COMPUTE D = V2 + V3 + V4 </li></ul></ul><ul><li>In the following example, there is no common sub-expression: </li></ul><ul><ul><li>COMPUTE A = V1 * V2 * V3 * V4 </li></ul></ul><ul><ul><li>COMPUTE B = V2 * V3 * V4 * V5 </li></ul></ul><ul><ul><li>COMPUTE C = V1 + (V2 + V3) </li></ul></ul><ul><ul><li>COMPUTE D = V4 + V2 + V3 </li></ul></ul><ul><li>The optimizer can eliminate duplicate computations. </li></ul><ul><li>You do not need to introduce artificial temporary computations; a program is often more comprehensible without them. </li></ul>
    87. 87. Grouping Constant Computations*** (probably remove) <ul><li>When several items in an expression are constant, ensure that the optimizer is able to optimize them. The compiler is bound by the left-to-right evaluation rules of COBOL. </li></ul><ul><ul><li>Therefore, either move all the constants to the left side of the expression or group them inside parentheses. </li></ul></ul><ul><ul><li>For example, if V1, V2, and V3 are variables and C1, C2, and C3 are constants, the expressions on the left below are preferable to the corresponding expressions on the right: </li></ul></ul><ul><li>More efficient Less efficient </li></ul><ul><li>V1 * V2 * V3 * (C1 * C2 * C3) V1 * V2 * V3 * C1 * C2 * C3 </li></ul><ul><li>C1 + C2 + C3 + V1 + V2 + V3 V1 + C1 + V2 + C2 + V3 + C3 </li></ul><ul><li>In production programming, there is often a tendency to place constant factors on the right-hand side of expressions. </li></ul><ul><li>However, such placement can result in less efficient code because optimization is lost. </li></ul>

    ×