(Seymour J.)
Sent: Friday, May 05, 2006 3:01 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
In [EMAIL PROTECTED], on 05/04/2006
at 05:05 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED]
said:
Sounds as if refresh means re-read the member pointed to by the
original TTR
What does the system allow?
I was vague, but basically you are *supposed* to use DISP=OLD for an output
data set of compress. If you don't, then you are asking for trouble, and
you may well get it.
The allocations done by the system are simply DISP=SHR so that if you truly
use DISP=OLD your
At 15:52 -0400 on 05/04/2006, Leverette, Melvin K. wrote about Re:
LINKLST into EXTENTS:
My recollection is that when you zap a module, the module is updated in
place in the load library.
Only if it is a PDS - If it is a PDSE then the ZAPPED version is
rewritten to a new location which
At 17:19 -0400 on 05/04/2006, (IBM Mainframe Discussion List) wrote
about Re: LINKLST into EXTENTS:
And what does LLA do when the directory entry's TTR points to a new location
that is beyond the end of the last extent which existed at the time the
library was added to the linklist set
IBM recommends no secondary extents for LNKLST data sets. There will be a
health check within the IBM Health Checker for z/OS that checks for exactly
that to alert you where you might have an exposure.
Someone mentioned compress and hope. You'd better do more than hope.
z/OS allocates the
Ted,
What sort of performance problem did multiple extents for a PDS ever cause?
From the IO point of view PDS access is a skip-sequential operation. You
read the directory and then access the member directly at its CCHHRR.
Seeking across other members is no different to seeking across extents of
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Relson
Sent: Friday, 5 May 2006 7:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
IBM recommends no secondary extents for LNKLST data sets. There will be a
health check within
If I recall, there is end of extents checking that happens whenever you
cross an extent boundary; plus in the old days extents would cause seek
time as you moved to the location of the new extent. If the PDS was on a
very active pack and poorly allocated, you could have the first extent at
On Thu, 4 May 2006 14:38:08 -0700, Edward Jaffe
[EMAIL PROTECTED] wrote:
IBM recommends no secondary extent allocation for data sets on LNKLST.
I have allowed them at times to be allocated with a secondary so SMP/E
maintenance doesn't have space problems. COMPRESS(ALL) only does
so much on
In a recent note, Peter Relson said:
Date: Fri, 5 May 2006 07:39:27 -0400
Someone mentioned compress and hope. You'd better do more than hope.
z/OS allocates the libraries so that if you do a legitimate compress it
won't go through. If you compress a library outside the bounds of
I'm using single Mod-27's for my sysres, and keep all the SMPE target
zone, target datasets serverpack supplied HFS datasets, plus a DFDSS
dump'd copy of the Serverpack supplied HFS's that matches that
maintenance level. The main reason why I dump the HFS's to flat file is
because we clone
In a message dated 5/5/2006 9:08:28 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
If I recall, there is end of extents checking that happens whenever you
cross an extent boundary;
Limits were always and still are placed on how far a multi-track search key
command could search
Nowadays an ECKD
channel program is built that will never stop searching until it comes to the end
of the directory, although seek time from one cylinder to the next is
involved,
I used to believe this was true, but it turns out it is not. A SEARCH
KEY CCW cannot execute in the domain of
In a message dated 5/5/2006 10:24:18 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
I used to believe this was true, but it turns out it is not. A SEARCH
KEY CCW cannot execute in the domain of a LOCATE RECORD, so the chain is
not strictly ECKD. The description of multi-track
In [EMAIL PROTECTED], on
05/04/2006
at 12:30 PM, Desi de la Garza [EMAIL PROTECTED] said:
Our LINKLIB has gone into extents and are gun shy about doing the
REFRESH. If there any way to define a new LINKLIB and make it hot
without having to IPL?
Create and activate a new linklist set, modeled
In [EMAIL PROTECTED], on 05/04/2006
at 05:05 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED]
said:
Sounds as if refresh means re-read the member pointed to by the
original TTR pointer.
No, it rereads the directory information. The x06 risk occurs when you
compress a linklist library
In [EMAIL PROTECTED], on 05/04/2006
at 05:19 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED]
said:
And what does LLA do when the directory entry's TTR points to a new
location that is beyond the end of the last extent which existed at
the time the library was added to the linklist
In [EMAIL PROTECTED],
on 05/04/2006
at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said:
There is no issue if the libraries have gone into extents.
Sure there is; LLA refresh only rereads the directories; it does not
rebuild the DEB. However, creating a new linklist set *does* create a
new DEB
In [EMAIL PROTECTED], on 05/05/2006
at 08:12 AM, Paul Gilmartin [EMAIL PROTECTED] said:
I was astonished to learn lately
that IEBCOPY will compress a data set allocated DISP=SHR, even while
another job has it allocated, also SHR. Does the system maintain
some sort of exclusive ENQ on LNKLST
Fellow Listeners,
We have applied a super zap to one of our 3rd party products and are
required to do a LLA,REFRESH to activate the zap.
Our LINKLIB has gone into extents and are gun shy about doing the REFRESH.
If there any way to define a new LINKLIB and make it hot without having to
IPL?
@BAMA.UA.EDU
Subject: LINKLST into EXTENTS
Fellow Listeners,
We have applied a super zap to one of our 3rd party products and are
required to do a LLA,REFRESH to activate the zap.
Our LINKLIB has gone into extents and are gun shy about doing the REFRESH.
If there any way to define a new LINKLIB
Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Clark, Kevin D, HRC-Alexandria/EDS
Sent: Thursday, May 04, 2006 2:08 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
Why not just add the member into another link list library until you fix
the extent issue. Do
Hey Dave,
You are rightonly 1 extent.
Used extents . . . : 1
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jousma, David
Sent: Thursday, May 04, 2006 2:12 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
Unless, I'm
Your display only shows 1 used extent - i.e. primary only. No problem.
Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209
--
For IBM-MAIN subscribe / signoff / archive access instructions,
Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
:Behalf Of Clark, Kevin D, HRC-Alexandria/EDS
:Sent: Thursday, May 04, 2006 2:08 PM
:To: IBM-MAIN@BAMA.UA.EDU
:Subject: Re: LINKLST into EXTENTS
:
:Why not just add the member into another link list library until you fix
:the extent issue. Do
In a message dated 5/4/2006 12:30:48 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Our LINKLIB has gone into extents and are gun shy about doing the REFRESH.
If there any way to define a new LINKLIB and make it hot without having to
IPL?
The display shows only one extent, so no
Our LINKLIB has gone into extents and are gun shy about doing the REFRESH.
There is no issue if the libraries have gone into extents.
There used to be performance issues, but with modern disks, there are no longer
any.
The linklist, like any library concatenation, has to be less than 256
: LINKLST into EXTENTS
Our LINKLIB has gone into extents and are gun shy about doing the
REFRESH.
There is no issue if the libraries have gone into extents.
There used to be performance issues, but with modern disks, there are
no longer
any.
The linklist, like any library concatenation, has
In a message dated 5/4/2006 2:49:11 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
If it has gone into extents since the linklist set was activated, then
there are concerns.
Right. My scenario was that they copied the module(probably a big one) to
see if the VER/REP worked and
My recollection is that when you zap a module, the module is updated in
place in the load library. The module remains at the same location, so
the pointer in the LNKLST is still correct. If the module is cached in
VLF, then it takes a refresh to pick up the change. If the module is
not cached
Of Leverette, Melvin K.
Sent: Thursday, May 04, 2006 2:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
My recollection is that when you zap a module, the module is updated in
place in the load library. The module remains at the same location, so the
pointer in the LNKLST
PROTECTED] On
Behalf
Of Desi de la Garza
Sent: Thursday, May 04, 2006 4:20 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
OK. Thanks to everyone that has responded. Everyone was been extremely
helpful.
I forwarded some of the responses to the vendor(Fischer Intn'l -IOF)
and
they have
The one thought I had is: Are there any application libraries in the Linklst?
Or are there any updates in this library other than the one you did?
Would you be bringing into the environment new changes that the applications
are not expecting.
I have had a couple of situations where someone
If it has gone into extents since the linklist set was activated, then there
are concerns.
Okay?
What are they?
That is the whole purpose of the refresh.
If you don't do the refresh, then there are definitely issues.
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
Ted MacNEIL wrote:
If it has gone into extents since the linklist set was activated, then there
are concerns.
Okay?
What are they?
That is the whole purpose of the refresh.
If you don't do the refresh, then there are definitely issues.
LLA refresh does not pick up new LNKLST
This was supposed to go to the list.
'Bad' REPLTYTO.
-
-teD
O-KAY! BLUE! JAYS!
Let's PLAY! BALL!
-Original Message-
From: Ted MacNEIL [EMAIL PROTECTED]
Date: Thu, 4 May 2006 20:58:49
To:[EMAIL PROTECTED]
Subject: Re: LINKLST into EXTENTS
The one thought I had is: Are there any
@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
Ted MacNEIL wrote:
If it has gone into extents since the linklist set was activated,
then there are concerns.
Okay?
What are they?
That is the whole purpose of the refresh.
If you don't do the refresh, then there are definitely issues
LLA refresh does not pick up new LNKLST extents. Only
building/activating/updating a new LNKLST set can do that.
Okay.
Any day you learn something new is a good day.
I can't believe I didn't know that.
At the Bank I used to work at, we didn't allow for secondary extents in link
list
In a message dated 5/4/2006 3:56:07 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
LLA refresh does not pick up new LNKLST extents.
Sounds as if refresh means re-read the member pointed to by the original TTR
pointer. So a refresh will only read in a changed member if that member
was
activated.
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Ted MacNEIL
Sent: Wednesday, May 03, 2006 8:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
LLA refresh does not pick up new LNKLST extents. Only
building
Discussion List)
Sent: Thursday, May 04, 2006 5:05 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
In a message dated 5/4/2006 3:56:07 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
LLA refresh does not pick up new LNKLST extents.
Sounds as if refresh means re-read the member
(IBM Mainframe Discussion List) wrote:
LLA refresh does not pick up new LNKLST extents.
Sounds as if refresh means re-read the member pointed to by the original TTR
pointer. So a refresh will only read in a changed member if that member was
superzapped in place? It won't go to the
In a message dated 5/4/2006 4:15:58 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
The refresh/update will re-read the directory, but subsequently only has
access to the extents which existed at the time the library was added to
the linklist set.
And what does LLA do when the
I did learn something new. Thanks listers
And here after we build the new linklst, 2ndry extents will no longer be
allowed also.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ted MacNEIL
Sent: Wednesday, May 03, 2006 7:00 PM
To: IBM
Some flavor of x06 abend (106, 806).
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of (IBM Mainframe Discussion List)
Sent: Thursday, May 04, 2006 5:20 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
In a message
(IBM Mainframe Discussion List) wrote:
And what does LLA do when the directory entry's TTR points to a new location
that is beyond the end of the last extent which existed at the time the
library was added to the linklist set?
It simply caches the new TTR value -- like always.
--
Edward
. . . and the result is fetch failures when someone needs the modules in
question.
Jon == bitten before
snip
(IBM Mainframe Discussion List) wrote:
And what does LLA do when the directory entry's TTR points to a new location
that is beyond the end of the last extent which existed at the
Imbriale, Donald (Exchange) wrote:
Some flavor of x06 abend (106, 806).
No! (You were fine until then.) LLA will refresh the directory cache
without incident. The abends you speak of will occur only if/when some
program attempts to use that cached TTR value to load a module.
--
Edward E
In a message dated 5/4/2006 4:27:20 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
It simply caches the new TTR value -- like always.
It would seem that a validation against the maximal TTR would be friendlier
than simply caching the new value and letting program fetch break some
Been there, OUCH!!!
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jon Brock
Sent: Thursday, May 04, 2006 4:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
. . . and the result is fetch failures when someone needs
: Thursday, May 04, 2006 5:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: LINKLST into EXTENTS
Imbriale, Donald (Exchange) wrote:
Some flavor of x06 abend (106, 806).
No! (You were fine until then.) LLA will refresh the directory cache
without incident. The abends you speak of will occur only if/when
(IBM Mainframe Discussion List) wrote:
It simply caches the new TTR value -- like always.
It would seem that a validation against the maximal TTR would be friendlier
than simply caching the new value and letting program fetch break some
unpredictable time later.
IBM recommends no
In a message dated 5/4/2006 4:38:32 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
IBM recommends no secondary extent allocation for data sets on LNKLST.
Problem solved! Enhance the documentation.
Bill Fairchild
53 matches
Mail list logo
