Subject: Re: Cobol and Performance Date: 01 Aug 2002 12:47:09 GMT From: Brian Walker Organization: Your Company Newsgroups: comp.lang.cobol "News" wrote in news:6MD09.12382$cU1.412067@news.chello.at: > I just started to do some research abt. performance and try to use it > for my work. > Years ago we used VS-Cobol II and still have some load modules out of > this time. > meanwhile we have LE/370 on OS/390 2.10 an Cobol for MVS Version > 2.2.1. > > Our Systemgroup defined compiler directives years ago and until today > there are no changes. > > So first I tried to change some things (according to > http://www-3.ibm.com/software/ad/cobol/library/booksabc/cobpf120.pdf): > > optimize(full), numproc(pfd, was mig), nossrange, norent, trunc(opt, > was > bin) > > the programs were avg. 6 percent faster (CPU-time) > > when possible I try to avoid "search all" (only with our national > zip-codes) I use a table with 10.000 Elements and load the zip-codes. > The tables is filled abt. 25% but now I am able to > move field (zip-code) to io-field > > all opt. together my programs are now faster for abt. 26 %. > > "Fastsrt" with dfsort brought 50% > > This week I changed inspect converting lowercase to uppercase with an > external subprogram > changing lower to upper. I can not use a function because of special > national character. > my external prg is 10 times faster (one million calls). > > Are there some more things to optimize ? > > thanks ! > Gerald Moritz > > > > > > > > > Hi I did a lot of work at my site on COBOL CPU optimisations and after testing various options decided to go with OPT(FULL) as the only really significant impator. The NORENT option made no measurable difference. To activate NORENT all programs in the load module must be NORENT and you need to link in the LE NORENT directive, else the load module is RENT. Same for REUSE. We already had NOSSRANGE as default. The SSRANGE option causes the compiler to generate heaps of extra assembler to bounds check all arrays, that's why it causes such a performance hit. A word of warning on the TRUNC option, if you use DB2 or anything else that uses INTEGER as a datatype then the TRUNC(OPT) option is a risk. The option allows the compiler to manipulate the data item EITHER on the byte boundary or as defined by the number of digits in the picture string. The only way to determine which method was generated for a particular COBOL statement is to read the assembler listing. The FASTSRT option only affects sorts that don't manipulate the data via input / output procedures. (If you code input or output procedures on the sort statement then FASTSRT has no affect). In conclusion, using OPT(FULL), For programs with loads of DB2 and / or IMS access, we achieved on average 4 percent improvement. For programs with little DB2 or IMS we achieved on average 25 percent improvement. I benchmarked approximately 300 programs for 2 weeks. There were other changes that were well worth while, for example I was able to changed a few utility programs to procedure division copybooks, though not as many as I wanted to. Another big thing was to ensure that programs called frequently (more than a million times per main program execution) didn't perform the initialise type code for every call. Obviously this depends on what the sub-program does. Another thing to watch for is that MVS time calls are very expensive and it is almost certainly worth writing an assembler program to return the current date and time rather that allowing COBOL to do it (accept date, function current date, all bad) for any program that does it many times. Using Strobe I saw several programs that executed for 10 CPU minutes and the date call used more than 10 percent of that CPU. Hope some of this helps. I have to go now, best of luck. Cheers.