On 01/21/2012 10:25 AM, Paul Gilmartin wrote:
On Sat, 21 Jan 2012 10:02:25 -0600, Joel C. Ewing wrote:
So the only functionally-equivalent, officially-sanctioned way to
accomplish this goal is still to
(1) create a new dataset with a different name and copy the data to it,
(2) modify PARMLIB LNKLST defs to replace the old library in linklist
with the new at next IPL,
(3) IPL.
And if for some reason you really must have the original dataset name,
repeat the process to get back to the old name.
Can LINKLIST contain aliases? If so:
(0) Place the alias name in PARMLIB LINKLIST defs;
IDCAMS DEFINE ALIAS to the real data set name.
(1) create a new dataset with a different name and copy the data to it,
(2) IDCAMS DELETE ALIAS; DEFINE ALIAS to identify the new data set.
(3) LLA REFRESH to identify members in the new data set.
Why not? (I know; I've been corrupted by UNIX symbolic links, and
imagine aliases are similar.)
-- gil
If an alias name is acceptable in linklist, that still wouldn't solve
the problem. Any system enqueues are always done on the real name at
the time of initial allocation for linklist, and the physical location
and size of the dataset becomes fixed to the linklist once the dataset
is initially allocated and is not changed by a REFRESH. If an active
linklist dataset is renamed, cataloged elsewhere, or even deleted,
linklist still points to the same original DASD tracks.
The only way to physically change the location and/or size of a linklist
library is to deallocate and reallocate it, which requires activating a
new linklist definition and eliminating any usage of the prior active
linklist. The latter is the difficult part because it can only be done
by forcing a linklist update on all long running address spaces, some
of which cannot be stopped/restarted without an IPL and others of which
cannot be restarted without disruption to end users. As has been
discussed in the past on this list, forcing a linklist update on an
arbitrary running address space is an "unnatural" act that involves
risk, and could in the worst case cause z/OS system failure and force an
IPL.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
