Lindy, I had decided to stay out of this, until you spoke. Now I am just going to say be very careful about the one ds idea. I am talking about mixing of libraries. This might be idea for a testing environment but a production environment can be a ball of worms. This becomes a very challenging as to who updates what and when. If you have one person that's one thing but when you have multiple people it can become nightmare. At one place we had a horror story that can be best described as how to get moral down to zero. We had many sysprogs updating the same ispf libraries and we had chaos.Talk about finger pointing. I had to step in and change the process and eliminate the problem by separating libraries and who could update what. The guys disliked it but came around after a few months no more complaining and no finger pointing.
Ed Sent from my iPad On Jun 11, 2011, at 5:27 PM, Lindy Mayfield <lindy.mayfi...@ssf.sas.com> wrote: > 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 ---------------------------------------------------------------------- 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
