FREEZE is indeed the 'culprit' that complicates content management of LLA libraries. I honestly don't know what SMF data, if any, would suggest likely candidates. Historically the low hanging fruit has included Clist, Rexx, and STEPLIB libraries allocated to a large number of TSO users. But Clist/Rexx libraries are just those most likely to confound a variety folks who update them. Everything on the mainframe is so much faster than it used to be, from processor to DASD, that the improvement derived from LLA is harder than ever to measure. Or to even perceive.
On the other hand, the time it takes a programmer to solve a confounding mystery has been fairly constant over time. As Shmuel would say, it's your dog. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: Leonardo Vaz <[email protected]> To: [email protected], Date: 02/18/2013 06:06 AM Subject: Re: Improve LLA/VLF usage Sent by: IBM Mainframe Discussion List <[email protected]> Thank you very much for expressing your opinion Skip, I am aware and I agree that LLA can be a pain to manage, maybe even worse than a linklist dataset, because you also have to remember to freeze the library in LLA. In my search for good candidates I plan to exclude libraries that are updates regularly. I am not even sure if I will find any good candidates at all, but do you think SMF records type 14 is the way to go? Thanks again, Leonardo Vaz -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Skip Robinson Sent: Friday, February 15, 2013 5:20 PM To: [email protected] Subject: Re: Improve LLA/VLF usage However you finally select candidates, be aware of some behavior changes that *other* folks in your shop may find disturbing. Not to mention *yourself* later on down the road. A library managed by LLA will not show updated contents until after an LLA REFRESH. For example, if you update a member via IEBCOPY, you will continue to observe the old data via Browse. If you add a net new member, you will get 'not found' when trying to browse or get attributes for that specific member by name. You will see the member when you display the entire member list but get 'not found' when trying to select the specific member. In other words, give some thought to whether a smidgeon of performance improvement here and there is worth the larger hassle in managing library contents. We've resisted the urge to include new libraries in LLA/VLF for that reason. The more people in your shop who might need to manage these libraries, the wider and deeper the confusion factor. Just sayin'. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: Leonardo Vaz <[email protected]> To: [email protected], Date: 02/15/2013 01:13 PM Subject: Improve LLA/VLF usage Sent by: IBM Mainframe Discussion List <[email protected]> Hello All, I was looking into improving performance by placing load libraries that have a high quantity of fetches in LLA/VLF. I was thinking on using SMF type 14 records to find out the good candidates. Is that a good idea? Any other ideas on how I could find out the most used load libraries? Thank you! Leonardo Vaz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
