Re: PDSE cache
Hi Thank you. Exactly the same as our experience has shown. The point I don't understand , after activate PDSE cache for non SMS i.e the directory cache should work, we didn't noticed any performance change, but after put the libraries into LLA, the improvement was dramatic . We have some PDSE's opened very often by a server, we hope some performance after putting to SMS managed volumes. On 7/5/2011 7:58 PM, Elmer Latorre wrote: Hi Miklos, Adding to Peter Relson's mail. Member data for Non-SMS PDSEs are not cached. If The PDSE is not a pogram object then it must be an SMS managed for member caching to occur and the sequential response in the storage clase must be set to a very low value. Elmer Latorre PDSE Devepment Team On 7/2/2011 4:40 PM, Peter Relson wrote: Simple rule: if you want modules cached, the library needs to be managed by LLA. If LLA deems the module cache-worthy then it will either do the caching using VLF or may notify PDSE processing to do it. If I remember correctly, long ago, long before z/OS 1.11, PDSE processing used to try to cache almost everything. Then all of that caching was removed. And then it was put back for cases where LLA felt it worthwhile. Peter Relson z/OS Core Technology Design -- 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: PDSE cache
Hi Miklos, Adding to Peter Relson's mail. Member data for Non-SMS PDSEs are not cached. If The PDSE is not a pogram object then it must be an SMS managed for member caching to occur and the sequential response in the storage clase must be set to a very low value. Elmer Latorre PDSE Devepment Team On 7/2/2011 4:40 PM, Peter Relson wrote: Simple rule: if you want modules cached, the library needs to be managed by LLA. If LLA deems the module cache-worthy then it will either do the caching using VLF or may notify PDSE processing to do it. If I remember correctly, long ago, long before z/OS 1.11, PDSE processing used to try to cache almost everything. Then all of that caching was removed. And then it was put back for cases where LLA felt it worthwhile. Peter Relson z/OS Core Technology Design -- 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: PDSE cache
Hi With LLA and load modules it works fine, but I would need to cache other type PDSE members(AFP resources ). From the SMF 14 record cache section I see it was not from cache, but don't see the reason why and if I can change this . On 7/2/2011 4:40 PM, Peter Relson wrote: Simple rule: if you want modules cached, the library needs to be managed by LLA. If LLA deems the module cache-worthy then it will either do the caching using VLF or may notify PDSE processing to do it. If I remember correctly, long ago, long before z/OS 1.11, PDSE processing used to try to cache almost everything. Then all of that caching was removed. And then it was put back for cases where LLA felt it worthwhile. Peter Relson z/OS Core Technology Design -- 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: PDSE cache
With LLA and load modules it works fine, but I would need to cache other type PDSE members(AFP resources ). From the SMF 14 record cache section I see it was not from cache, but don't see the reason why and if I can change this . SMF Type 14 will NOT show you PDSE activity. PDSE have their own SMF record that you will need to check. Having said that, independent of SMS-management, if the complete size of the PDSE members that you need to cache exceeds the maximum size of the PDSE cache (16GB IIRC), you won't have any performance benefit, as only the most used members will stay in that cache. And if they are all evenly used, you'll get thrashing. In addition, beware recfm V in any shape or size. PDSE development told me that that will require extra I/O every time due to some sort of internal organization. (That I understand they have no plans of changing). How many members in your PDSE(s)? What is the size of the PDSE(s)? How long does it take to do an ISPF 3.4 from enter to seeing the directory? Regards, Barbara -- 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: PDSE cache
Hi Thank you Barbara, I see you are the proper expert in this field In my SMF 14 records there is the PDSE Statistic section, and I see the directory cache hits , but no data member hits. It is a AFP resource library (not SMS managed) , 600 members and all are relatively small (1 -4 K bytes), but a server application opens again and again. I hope to set the proper SMS PDSE1 options On 7/4/2011 9:41 AM, Barbara Nitz wrote: With LLA and load modules it works fine, but I would need to cache other type PDSE members(AFP resources ). From the SMF 14 record cache section I see it was not from cache, but don't see the reason why and if I can change this . SMF Type 14 will NOT show you PDSE activity. PDSE have their own SMF record that you will need to check. Having said that, independent of SMS-management, if the complete size of the PDSE members that you need to cache exceeds the maximum size of the PDSE cache (16GB IIRC), you won't have any performance benefit, as only the most used members will stay in that cache. And if they are all evenly used, you'll get thrashing. In addition, beware recfm V in any shape or size. PDSE development told me that that will require extra I/O every time due to some sort of internal organization. (That I understand they have no plans of changing). How many members in your PDSE(s)? What is the size of the PDSE(s)? How long does it take to do an ISPF 3.4 from enter to seeing the directory? Regards, Barbara -- 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: PDSE cache
In my SMF 14 records there is the PDSE Statistic section, and I see the directory cache hits , but no data member hits. It is a AFP resource library (not SMS managed) , 600 members and all are relatively small (1 -4 K bytes), but a server application opens again and again. I hope to set the proper SMS PDSE1 options How long does a 3.4 of the PDSE take? Barbara -- 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: PDSE cache
On 7/4/2011 1:49 PM, Barbara Nitz wrote: In my SMF 14 records there is the PDSE Statistic section, and I see the directory cache hits , but no data member hits. It is a AFP resource library (not SMS managed) , 600 members and all are relatively small (1 -4 K bytes), but a server application opens again and again. I hope to set the proper SMS PDSE1 options How long does a 3.4 of the PDSE take? Barbara -- 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 The dataset is not too big (555 members), the directory list is very fast (immediatly got the reply) . Seems the directory cache active, but the membe data cache only for SMS managed datasets . -- 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: PDSE cache
Simple rule: if you want modules cached, the library needs to be managed by LLA. If LLA deems the module cache-worthy then it will either do the caching using VLF or may notify PDSE processing to do it. If I remember correctly, long ago, long before z/OS 1.11, PDSE processing used to try to cache almost everything. Then all of that caching was removed. And then it was put back for cases where LLA felt it worthwhile. Peter Relson z/OS Core Technology Design -- 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
PDSE cache
Hi Started in zOS 1.11 the SMS PDSE1 address space with large cache, buffer_beyond_close etc. For my big surprise no any change in a program runtime, which is intensively using modules from PDSE libraries. -- 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: PDSE cache
Miklos Barbara Nitz has explored this area in great detail in various threads over the last few years. Check the archives and read her posts - they are excellent. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: 01 July 2011 14:53 To: IBM-MAIN@bama.ua.edu Subject: PDSE cache Hi Started in zOS 1.11 the SMS PDSE1 address space with large cache, buffer_beyond_close etc. For my big surprise no any change in a program runtime, which is intensively using modules from PDSE libraries. -- 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: PDSE cache
Hi Thank you, I will read her posts, but reading now it only works for SMS managed PDSE. My PDSE's are not SMS managed. D SMS,PDSE1,HSPSTATS says that all my dataset 's are cache eligible. On 7/1/2011 4:11 PM, Rob Scott wrote: Miklos Barbara Nitz has explored this area in great detail in various threads over the last few years. Check the archives and read her posts - they are excellent. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: 01 July 2011 14:53 To: IBM-MAIN@bama.ua.edu Subject: PDSE cache Hi Started in zOS 1.11 the SMS PDSE1 address space with large cache, buffer_beyond_close etc. For my big surprise no any change in a program runtime, which is intensively using modules from PDSE libraries. -- 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
