Mark,
Follow this thread backwards to learn about the DFSMS 'global connect'
prohibiting the deletion of a PDSE LNKLST'd at IPL. Also pay attention to
the warnings mentioned by many, know the environment you're doing this,
etc.
Paul
I have the same problem with z/os 1.6 SYS1.SIEALNKE which is a new link
list that IBM is pusing modules to. I can rename it, but not delete it. I
wonder what would happen if I renamed the PDSE and then allocated it under
it's original name. I dynamically removed it from LLA and XCFAS.
I dynamically removed it from LLA and XCFAS. Anybody try this?
Anybody consider that we are trying to keep the system up as long as possible?
Without corruption?
Why are we trying to outsmart protection.
If it doesn't work that way, why fart with it?
I'd rather have the system up an working,
I agree with Ed Jaffe's reply: Using CVTLINK is just fine. The system
treats that as use the LNKLST that this address space is using whether
that be the IPL-time LNKLST or some other..
LOAD with ADDR= is relatively absurd, imo, unless you provide a directory
entry (in which case you do not have
Isn't there still some code in the system that uses the original DEB?
No
No (IBM-owned) system code uses CVTLINK or its DCB/DEB directly. When the
system sees CVTLINK it translates CVTLINK into ASSBDLCB - DLCBDCB@ .
Code stll running with the IPL-time LNKLST will of course access the
original DEB
Peter Relson of z/OS Core Technology Design wrote:
No (IBM-owned) system code uses CVTLINK or its DCB/DEB
directly. When the system sees CVTLINK it translates
CVTLINK into ASSBDLCB - DLCBDCB@ .
Code stll running with the IPL-time LNKLST will of course
access the original DEB when using
Tony Harminc wrote:
I may misunderstand what you are saying... What is the correct way to load a
LNKLST module into a storage location of one's own choosing using ADDR= on
the LOAD macro? LOAD with ADDR= requires a non-zero DCB=, so I have been
using the CVTLINK DCB, but I'm presumably missing
In [EMAIL PROTECTED], on 04/23/2006
at 08:48 PM, Binyamin Dissen [EMAIL PROTECTED] said:
If the appropriate SETPROG is issued, each address space gets the new
linklist.
Isn't there still some code in the system that uses the original DEB?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
It is indeed DFSMS's global connect that prevents a PDSE in the IPL-time
LNKLST from being deleted.
It is this area and related areas that we intend to change in z/OS V1R8.
Peter Relson
z/OS Core Technology Design
--
For
- Original Message
From: Cox, Dave [EMAIL PROTECTED]
Works quite well here where we get JES2 down ( we forget about Z EOD
here - I was shocked that they did not do it here, but have gotten used
to it ), and follow steps 1 through 4 manually. It doesn't take me any
time at all to
On 4/19/2006 2:44 PM, Paul Dineen wrote:
I'm wondering if others have had difficulty with PDSE's which are included
in LNKLST at IPL time, specifically deletion of them?
There have been times where a LNKLST'd PDS needs expansion: the dataset can
be 'dequeued' via SETPROG LNKLST,UNALLOCATE,
I get very frustrated when I continue to read posts about deleting
libraries from the LNKLST. Anything that intends to delete a library from
the LNKLST should be prepared for unpredictable errors and immediate
re-IPL. This should be done as a last resort only.
The LNKLST UNALLOCATE command is NOT
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
On Wed, 19 Apr 2006 14:12:04 -0500, Mark Zelden
wrote:
Not an issue for PDSE. It always counts as one extent, and
if it takes
an extent during update the module is accessable
Jim,
Thanks for the reminder about program objects requiring PDSEs, something
not when considering the possiblity of converting PDSE's to PDS.
Paul
3) Converting IBM PDSEs back to PDS (with each version - annually
here).
You cannot do this. IBM PDSEs may contain members which use
Walt,
Regarding the concern of stopping MIM, the LPAR where MIM is stopped is a
SYSPROG only environment and MIM is not stopped in test or prod LPARs.
Anyone taking the risk of stopping MIM understands the risk, is working
alone in the LPAR and the stoppage is for a very short period. Don't
Thanks to all who've offered their thoughts.
To Peter Relson, let me apologize if I've added to your frustration level
in any way, shape or form. This is/was not my intent, I'm just trying to
understand why a new and improved DSORG prohibits actions allowed with an
older DSORG. I'm hoping
Hello,
I'm wondering if others have had difficulty with PDSE's which are included
in LNKLST at IPL time, specifically deletion of them?
There have been times where a LNKLST'd PDS needs expansion: the dataset can
be 'dequeued' via SETPROG LNKLST,UNALLOCATE, stopping LLA and (in this
shop) MIM.
On Wed, 19 Apr 2006 13:44:28 -0500, Paul Dineen [EMAIL PROTECTED] wrote:
Hello,
I'm wondering if others have had difficulty with PDSE's which are included
in LNKLST at IPL time, specifically deletion of them?
No, but I can see where it could cause some confusion since the
restriction isn't
In a recent note, Mark Zelden said:
Date: Wed, 19 Apr 2006 14:12:04 -0500
2) Allowing secondary allocation (and the LNKLST can of worms that opens).
Not an issue for PDSE. It always counts as one extent, and if it takes
an extent during update the module is accessable (an LLA
On Wed, 19 Apr 2006 14:12:04 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:
Not an issue for PDSE. It always counts as one extent, and if it takes
an extent during update the module is accessable
~~
accessible
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/19/2006
02:44:28 PM:
Thoughts to mitigate, but not all prevent the problem include:
1) Overallocation of PDSEs.
2) Allowing secondary allocation (and the LNKLST can of worms that
opens).
3) Converting IBM PDSEs back to PDS
Hi Paul,
define a new PDSE and copy the old into the new the activate a new LNKLST via T
PROG=xx.
PROG-Member (sample)
LNKLST DEFINE NAME(LNKLSTCBC) COPYFROM(CURRENT)
LNKLST DELETE NAME(LNKLSTCBC) DSNAME(SYS3.CBC140E.SCCNCMP.LINKLIB)
LNKLST ADDNAME(LNKLSTCBC)
22 matches
Mail list logo
