will this be documented somewhere with LLA and/or VLF?
The health check is documented in the HC book.
The modify command and the COFVLFxx parmlib member are documented in their
normal places.
I don't know if there's a reference to those things within whatever more
general description of LLA
-can I use VLF trimming statistics as a good measure to
determine if my CSVLLA cache is large enough?
-If not, what measure does tell me this, besides the
LLAFETCH/PGMFETCH measures I get from CSVLLIX1/2?
Provided by the VLF owner:
Since LLA expects VLF to trim as needed to make room for
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Peter Relson
Sent: 02 December, 2014 13:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
-can I use VLF trimming statistics as a good measure to
determine if my CSVLLA cache is large enough?
-If not, what measure does tell me this, besides
I liked the health check.
If you have access to MXG, here is a sample of what I have used to manage VLF:
/*
// JCLLIB ORDER=ZELDEN.MXG.SOURCLIB
//STEP010 EXEC MXGSAS,WORK='50,50'
//*SMF DD
On 12/02/2014 11:00 AM, Mark Zelden wrote:
I liked the health check.
If you have access to MXG, here is a sample of what I have used to manage VLF:
SNIPPAGE
Thanks. I ran a quick test of this. I likes it.
It gave me some ideas...
Regards,
Steve Thompson
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Peter Relson
Sent: 30 November, 2014 16:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
Now, please put your wisdom in IBM books.
I think that most of my post was discussing internal details
Now, please put your wisdom in IBM books.
I think that most of my post was discussing internal details that are not
suitable for documentation (where by documenting them, customers and
programmers are allowed to rely on them, which in turn may hamstring
future desire to change). If there are
-627-3803
E: cblaic...@syncsort.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Peter Relson
Sent: Sunday, November 30, 2014 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
If LLA finds that a module that it had
In contrast to other VLF exploiters, LLA has decided
to fully control the VLF cache, it knows how large it
is, knows what is in there and how much room is
still left.
I'm afraid that this is not true.
Peter Relson
z/OS Core Technology Design
Peter Relson wrote:
I don't know what is being assumed or understood, but most of this thread
is somewhat technically inaccurate. Some of that is perhaps terminology, some
not.
Thanks Peter. Now, please put your wisdom in IBM books. Like Shane, I also
would like to congratulate you on your
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: 27 November, 2014 18:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
On 11/27/2014 02:22 AM, Vernooij, CP (ITOPT1) - KLM wrote:
SNIPPAGE
No, here I read
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: 27 November, 2014 18:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
On 11/27/2014 02:22 AM, Vernooij, CP (ITOPT1) - KLM wrote:
SNIPPAGE
No, here I read a common misconception about LLA and VLF working.
LLA
I don't know what is being assumed or understood, but most of this
thread is somewhat technically inaccurate. Some of that is perhaps
terminology, some not.
So let's start here:
VLF does not do caching.
In my view, this is at least misleading (although perhaps it's simply
being loose with
On 11/27/2014 02:22 AM, Vernooij, CP (ITOPT1) - KLM wrote:
SNIPPAGE
No, here I read a common misconception about LLA and VLF working.
LLA module caching and directory freeze are separate functions. Directories are
kept completely in LLA's private storage. Modules are cached in VLF.
LLA
VLF writes SMF 41 records, but they are unusable for LLA.
Since LLA manages its VLF cache and knows what is in it
and what is not, it will always have a 100% hitratio on
its VLF cache, which will be reported by VLF records 41.
That is not correct. It is true that LLA does know what it put into
VLF writes SMF 41 records, but they are unusable for LLA.
That is not correct. It is true that LLA does know what it put into the cache
(as would most VLF exploiters), but (as with all VLF exploiters) it has no
idea what VLF has taken out due to trimming.
I tend to agree with the OP. LLA will
On 11/26/2014 11:19 AM, Bob Shannon wrote:
snippage
I tend to agree with the OP. LLA will only check VLF for modules it previously
cached. Granted there may be some trimming, but I don't ever recall seeing less
than a 100% hit ratio for LLA. The other VLF exploiters behave differently and
the
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bob Shannon
Sent: 26 November, 2014 17:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
VLF writes SMF 41 records, but they are unusable for LLA.
That is not correct
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: 26 November, 2014 21:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF caching
On 11/26/2014 11:19 AM, Bob Shannon wrote:
snippage
I tend to agree with the OP. LLA
There is no rule of thumb. It's very likely that 16M is way too small, but
we're not likely to change the default.
128M is fairly common, I believe.
It's not necessarily the case that a bigger size is better. The more data
that is cached, the more likely you are to be able to retrieve from the
Thomas Conley wrote:
I've always had to review the SMF data, then make adjustments. No ROTs or
sizing recommendations I'm aware of.
Please forgive my ignorance, but what SMF records? Of course I have looked in
my SMF book, but must have missed something obvious or used wrong search
] On Behalf
Of Elardus Engelbrecht
Sent: 25 November, 2014 14:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
Thomas Conley wrote:
I've always had to review the SMF data, then make adjustments. No ROTs or
sizing recommendations I'm aware of.
Please forgive my ignorance, but what SMF records
Vernooij, CP (ITOPT1) - KLM wrote:
That a tricky question: VLF writes SMF 41 records, but they are unusable for
LLA. Since LLA manages its VLF cache and knows what is in it and what is not,
it will always have a 100% hitratio on its VLF cache, which will be reported
by VLF records 41. Via LLA
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: 25 November, 2014 14:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
Vernooij, CP (ITOPT1) - KLM wrote:
That a tricky question: VLF writes SMF 41 records, but they are unusable for
LLA. Since LLA manages its VLF cache
On 11/25/2014 08:03 AM, Elardus Engelbrecht wrote:
Thomas Conley wrote:
I've always had to review the SMF data, then make adjustments. No ROTs or
sizing recommendations I'm aware of.
Please forgive my ignorance, but what SMF records? Of course I have looked in
my SMF book, but must have
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: 25 November, 2014 15:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
On 11/25/2014 08:03 AM, Elardus Engelbrecht wrote:
Thomas Conley wrote:
I've always had to review the SMF data, then make
elardus.engelbre...@sita.co.za
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 25/11/2014 13:39
Subject:Re: VLF Caching
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Vernooij, CP (ITOPT1) - KLM wrote:
That a tricky question: VLF writes SMF 41 records, but they are unusable
On 11/25/2014 07:29 AM, Peter Relson wrote:
There is no rule of thumb. It's very likely that 16M is way too small, but
we're not likely to change the default.
128M is fairly common, I believe.
It's not necessarily the case that a bigger size is better. The more data
that is cached, the more
On 11/25/2014 08:03 AM, Elardus Engelbrecht wrote:
SNIPPAGE
Ok if you say so. Could that part of MFM not be included in Health Checker so
we all can see what sizes are recommended?
Groete / Greetings
Elardus Engelbrecht
--
Steve Thompson wrote:
MFM is a non-supported (Ok, support as time is available) product from IBM.
You have to sign some doc, etc. So it is not generally in use by z/OS sites.
I have used in ancient times. This is why I asked for inclusion in HC.
Groete / Greetings
Elardus Engelbrecht
Of Steve Thompson
Sent: 25 November, 2014 15:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
On 11/25/2014 07:29 AM, Peter Relson wrote:
There is no rule of thumb. It's very likely that 16M is way too small,
but we're not likely to change the default.
128M is fairly common, I believe
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, CP (ITOPT1) - KLM
Sent: 25 November 2014 15:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
I have 200MB and have a 99% hitratio on 20 LLA managed libraries, as reported
by LLA statistics (LLA fetches from its VLF cache)/(LLA fetches from
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tidy, David (D)
Sent: 25 November, 2014 16:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
I had thought (from
https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry
/ Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Tidy, David (D) dt...@dow.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 25/11/2014 15:04
Subject:Re: VLF Caching
Sent by:IBM Mainframe Discussion List IBM-MAIN
On 11/25/2014 8:03 AM, Elardus Engelbrecht wrote:
Thomas Conley wrote:
I've always had to review the SMF data, then make adjustments. No ROTs or
sizing recommendations I'm aware of.
Please forgive my ignorance, but what SMF records? Of course I have looked in
my SMF book, but must have
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: Tuesday, 25 November 2014 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
On 11/24/2014 05:29 PM, Thomas Conley wrote:
On 11/24/2014 4:30 PM, Steve Thompson wrote:
SNIP
Is there a ROT for setting of the MAXVIRT
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Anthony Thompson
Sent: 26 November, 2014 4:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VLF Caching
Not sure this is worth mentioning, but IBM's Health Checker has a check called
IBMVLF,VLF_MAXVIRT that tells you how many times VLF has trimmed
I'm using MFM (Module Fetch Monitor) and CP-Expert and we found
that we needed to increase the cache for CSVLLA. So we set it up
to 32MB (from the default of 16MB).
Well we ran for a bit like this to find that we need to set it
higher because of how often we are going through trim.
Is there
On 11/24/2014 4:30 PM, Steve Thompson wrote:
I'm using MFM (Module Fetch Monitor) and CP-Expert and we found that we
needed to increase the cache for CSVLLA. So we set it up to 32MB (from
the default of 16MB).
Well we ran for a bit like this to find that we need to set it higher
because of how
On 11/24/2014 05:29 PM, Thomas Conley wrote:
On 11/24/2014 4:30 PM, Steve Thompson wrote:
SNIP
Is there a ROT for setting of the MAXVIRT for CSVLLA class?
SNIP
I'm thinking we should go to 64MB, but perhaps we should go
higher. I'm
just not aware of anything that gives us an idea of how
40 matches
Mail list logo
