I'm probably going to get myself into trouble with this. But as they say in Finnnish, Olkoon. Or in Savo, Olokoon.
Seems to me that often times people get hung up on performance when it isn't necessary. Now, don't get me wrong, talking about performance is cool. And don't get me wrong here either, sometimes performance is crucial. Like an application that gets run thousands of times a minute or hour or some such. And if we are talking assembler (or called modules), then you guys here and especially on the assembler list have a lot of cool things to say about it all. 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?) 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? 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. Ok here, I'm really being totally honest. In what sort of situation would performance be important in these examples (from a few users to a few thousand): 1) A simple ISPF application with all the panels, skeletons, etc buried at the end of the exec and sourceline() used to scan for it. 2) An ISPF application, complex or not, but let's say complex, that does LIBDEF's to all necessary ISPF libraries. 3) An ISPF application, complex or not, but let's say complex, that has all necessary ISPF libraries allocated in the logon proc. 4) Throw in PDSE's here. I don't use them, and I don't understand them. And because I don't understand them (and I've not taken the time to do so) I always seem to get myself into trouble when using them. 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. I'm sorry. Sometimes bigger performance isn't always better. IMHO. But I like talking and thinking about it! Someday I'll take the time to try to understand what "pipeline" means. You guys talk about that a lot. :-) Lindy ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin [paulgboul...@aim.com] Sent: 12 June 2011 00:45 To: IBM-MAIN@bama.ua.edu Subject: Re: Running an ISPF applicction from one pds On Sat, 11 Jun 2011 14:00:15 -0500, Mike Schwab wrote: >Slightly slower member search than if each DDNAME had only the members >for that DDNAME to search. Maybe an IEBCOPY to copy named members to >individual libraries for customers who want maximum performance? > PDSE? I understand PDSE directories are so structured that search for a member is more efficient than O(n). But other comments here cuggest that the coefficients are such that the benefit is reached only for extremely large numbers of members, if at all. -- gil ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
