Skip:
I think you are on the money.
From 30 years of looking at SMF records the excp counts for load
libraries are notoriously under reported.
Ed
On Feb 18, 2013, at 6:44 PM, Skip Robinson wrote:
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 <IBM-
[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:IBM-
[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 <IBM-
[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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
