Re: ISPF Preprocessed Panels
I looked at that years ago. The issue I kept coming up with was to remember to re process the panels after maintenance. It might be semi acceptable on a small shop but when you have various people applying maintenance is could cause headaches. To me it just wasn't worth the exposure. I certainly can understand the look at. I would suggest as a painless easyway for essentially buyback with little or no effort is to put the applicable ISPF libraries into LPALIB or lpalist (probably the second is easiest). We did that from DAY 1 and we never went back. We had a hotshot performance guy in and he suggested it and was surprised that we had already done it. Ed -snip- Hello everybody: I would like to request people's opinions on taking the trouble of preprocessing ISPF panels. We have been preprocessing ISPF and SDSF panels for a long time now (at least the portion of those that are preprocessable) and I never personally noticed any performance gain from preprocessing. That is, the non-ISPF and non-SDSF panels which we don't preprocess don't seem to load perceptibly slower that ISPF/SDSF ones. Also, all those preprocessed libraries at the top of the ISPPLIB concatenation: don't they make the search longer for any panel load? Thus offsetting any performance gain from preprocessing?Thanks, Nur Allen, Systems Pgmmer Analyst, County of Santa Clara unsnip--- I've never noticed any performance difference, even on a fairly small machine (z/800 0A1) -- 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
Re: ISPF Preprocessed Panels
cross posting to ISPF-L It seems that the consensus is *not* to compile the panels - that there are other means by which performance can be increased without the added headaches of processes/procedures associated with such action, and I guess that I would agree; everything being same old-same old. But, what about situations where the application is ISPF-intensive (for lack of a better term), where - for example - there are tons of AB items (therefore, most likely a lot of commands), let's say a huge tutorial, a lot of processing on the panel side of things, ya know? Where the programs do only what they need to do and ISPF is handling the rest; and newer features are used, such as panel REXX, etc., etc. (am I making sense?... don't really know, but I'll stick with it). Would it then make sense to pre-process the panels??? Just thinking out loud, which usually gets me into trouble. ;-) All the best, Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Saturday, March 13, 2010 10:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ISPF Preprocessed Panels I looked at that years ago. The issue I kept coming up with was to remember to re process the panels after maintenance. It might be semi acceptable on a small shop but when you have various people applying maintenance is could cause headaches. To me it just wasn't worth the exposure. I certainly can understand the look at. I would suggest as a painless easyway for essentially buyback with little or no effort is to put the applicable ISPF libraries into LPALIB or lpalist (probably the second is easiest). We did that from DAY 1 and we never went back. We had a hotshot performance guy in and he suggested it and was surprised that we had already done it. Ed -snip- Hello everybody: I would like to request people's opinions on taking the trouble of preprocessing ISPF panels. We have been preprocessing ISPF and SDSF panels for a long time now (at least the portion of those that are preprocessable) and I never personally noticed any performance gain from preprocessing. That is, the non-ISPF and non-SDSF panels which we don't preprocess don't seem to load perceptibly slower that ISPF/SDSF ones. Also, all those preprocessed libraries at the top of the ISPPLIB concatenation: don't they make the search longer for any panel load? Thus offsetting any performance gain from preprocessing?Thanks, Nur Allen, Systems Pgmmer Analyst, County of Santa Clara unsnip --- I've never noticed any performance difference, even on a fairly small machine (z/800 0A1) -- 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
Re: ISPF Preprocessed Panels
In 0039079945bb6f4cb09116d45fe978ac0240072...@cms1.sccgov.org, on 03/12/2010 at 02:10 PM, Allen, Nur nur.al...@isd.sccgov.org said: Hello everybody: I would like to request people's opinions on taking the trouble of preprocessing ISPF panels. I would only do it if 1. You're not updating panels so often that the preprocessing costs more than it saves. 2. You have CM procedures in place to automatically preprocess panels promoted into QA or production. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
ISPF Preprocessed Panels
Hello everybody: I would like to request people's opinions on taking the trouble of preprocessing ISPF panels. We have been preprocessing ISPF and SDSF panels for a long time now (at least the portion of those that are preprocessable) and I never personally noticed any performance gain from preprocessing. That is, the non-ISPF and non-SDSF panels which we don't preprocess don't seem to load perceptibly slower that ISPF/SDSF ones. Also, all those preprocessed libraries at the top of the ISPPLIB concatenation: don't they make the search longer for any panel load? Thus offsetting any performance gain from preprocessing?Thanks, Nur Allen, Systems Pgmmer Analyst, County of Santa Clara -- 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
Re: ISPF Preprocessed Panels
I never personally noticed any performance gain from preprocessing. Even back with slow DASD, I never saw a performance benefit that out-weighed the admin overhead. Today's DASD, I'd say forget it. - Too busy driving to stop for gas! -- 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
Re: ISPF Preprocessed Panels
Ted MacNEIL wrote: I never personally noticed any performance gain from preprocessing. Even back with slow DASD, I never saw a performance benefit that out-weighed the admin overhead. Today's DASD, I'd say forget it. If you're looking for improved DASD response time, you're looking in the wrong place. Pre-processed panels save on CPU. Every ISPF panel must be tokenized. Those that are pre-processed bypass the vast majority of that processing, thus reducing the path length required to load them. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: ISPF Preprocessed Panels
If you're looking for improved DASD response time, you're looking in the wrong place. Pre-processed panels save on CPU. Every ISPF panel must be tokenized. Those that are pre-processed bypass the vast majority of that processing, thus reducing the path length required to load them. And, how many beers can you buy with the 'saved' CPU? I've found very little response/resource savings with pre-processed panels. The only reason I mentioned I/O was because that was the question. With sub-half-second response, where is the saving? - Too busy driving to stop for gas! -- 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
Re: ISPF Preprocessed Panels
-snip- Hello everybody: I would like to request people's opinions on taking the trouble of preprocessing ISPF panels. We have been preprocessing ISPF and SDSF panels for a long time now (at least the portion of those that are preprocessable) and I never personally noticed any performance gain from preprocessing. That is, the non-ISPF and non-SDSF panels which we don't preprocess don't seem to load perceptibly slower that ISPF/SDSF ones. Also, all those preprocessed libraries at the top of the ISPPLIB concatenation: don't they make the search longer for any panel load? Thus offsetting any performance gain from preprocessing?Thanks, Nur Allen, Systems Pgmmer Analyst, County of Santa Clara unsnip--- I've never noticed any performance difference, even on a fairly small machine (z/800 0A1) -- 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
Re: ISPF Preprocessed Panels
I benchmarked pre-processing panels years ago and found sufficient measurable results to justify doing it. As an ISPF user I couldn't tell the difference. Bob Shannon Rocket Software -- 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
Re: ISPF Preprocessed Panels
If you're looking for improved DASD response time, you're looking in the wrong place. Pre-processed panels save on CPU. Every ISPF panel must be tokenized. Those that are pre-processed bypass the vast majority of that processing, thus reducing the path length required to load them. Having spent the last 2 years coding 10,000 lines into ISPF panels, among other things, I can definitely see the merit in Ed Jaffe's argument. On Fri, Mar 12, 2010 at 5:41 PM, Edward Jaffe edja...@phoenixsoftware.comwrote: Ted MacNEIL wrote: I never personally noticed any performance gain from preprocessing. Even back with slow DASD, I never saw a performance benefit that out-weighed the admin overhead. Today's DASD, I'd say forget it. If you're looking for improved DASD response time, you're looking in the wrong place. Pre-processed panels save on CPU. Every ISPF panel must be tokenized. Those that are pre-processed bypass the vast majority of that processing, thus reducing the path length required to load them. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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 -- George Henke (C) 845 401 5614 -- 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
Re: ISPF Preprocessed Panels
Having spent the last 2 years coding 10,000 lines into ISPF panels, among other things, I can definitely see the merit in Ed Jaffe's argument. And, have you measured the savings? Have you found it worth it? - Too busy driving to stop for gas! -- 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
