> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Lindy Mayfield > Sent: Saturday, June 11, 2011 6:28 PM > To: IBM-MAIN@bama.ua.edu > Subject: When is performance really an issue? Was: Running an ISPF > applicction from one pds <Snipped> > And if that module is Cobol, then, well, nobody can > really (or can they?) expect it to be re-written in assembler to make it > faster. (Can you write Cobol to be faster? And "structured" at the same > time?)
Most definitely COBOL programs can be written to be faster, and still structured. For example, in one program that I worked on I traded moving 8000-byte record areas around willy-nilly with the following: 1. Some of those record areas were moved to the LINKAGE SECTION; 2. A few pointer variables were defined in the WORKING-STORAGE SECTION; and 3. Replacing some of the willy-nilly MOVE statements with SET statements to make a LINKAGE record area address the WORKING-STORAGE record area that was previously MOVEd. That change alone saved some 10-15% of average CPU time in a program that processes many millions of records daily (statistically averaged over multiple runs). > And don't get me wrong here either, again, but a fairly simple Rexx/ISPF > application doesn't really need a lot of performance tuning? does it? Probably not. > And I've heard somewhere along my travels that sometimes it is better to > slow things down a bit when you are dealing with a user interface, like a > CICS application. That "too fast" is sometimes just, well, too fast. I never heard that one, but I can see the logic of it in the right circumstances. <Snipped> > I've actually written a fairly complex ISPF/DB2 application all using Rexx > and I have a half second response time (max). And since DB2 calls were > (though dynamic) fairly simple, I would expect a 1000+ users to have > similar response time. Did you by any chance get to measure it with 1000+ users? Or even with 100+ users? Measurements have trumped expectations in more cases than I care to remember. Not saying your expectation is wrong, but until you measure it you won't *really* know. > I'm sorry. Sometimes bigger performance isn't always better. IMHO. But > I like talking and thinking about it! So do some other folks here, I've noticed... :) > Someday I'll take the time to try to understand what "pipeline" means. > You guys talk about that a lot. A CPU pipeline is the hardware advance that makes measuring program CPU time a gambler's game, since there is no longer any guarantee at all that a program will consume the same CPU time from one execution to the next, even with totally identical inputs. Frustrates the heck out of those of us who are charged with reducing the time it takes a production program to do its job, since we are reduced to executing multiple runs and using statistical averages. And you know what they say about lies and statistics... :) Of course, the best CPU improvements are always gained from better application design rather than code tweaking, but that's not always a viable alternative. HTH Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
