-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth
John, the problem is that the same name exists on the system I am
running on. I think I might try iehmove.
Shouldn't make any difference. We have duplicate RESVOL sets for each
z/OS image we run,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth
Allan, the problem is that the datasets are on the target res vol
with
the same name as the dataset on the currently running res vol and they
are catalogged in the master cat. Eg. sys1.serblink,
Yes, you are both correct. The serious warning messages, some in red,
just scared the heck outta me. Now I have iebcopied the full datasets to
larger ones and done the renames manually with ispf being sure to only
affect the inactive resvol that is the target for my maint. Now the
target pack is
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Klein, Kenneth
Sent: Thursday, July 23, 2009 7:21 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What's the difference in SMP/E between the SOURCEID's
called RSU and PUT ???
Yes, you
Yes, that's how I remember it. And to correct myself we do have the
DDDef's hard coded with a specific volser. We clone the target.csi and
zonedit to create a new sandbox for maint.
Ken Klein
Sr. Systems Programmer
Kentucky Farm Bureau Insurance - Louisville
kenneth.kl...@kyfb.com
502-495-5000
Recommended service upgrade and ?
Should I apply them both?
SET BOUNDARY ( RESZS3 ) .
APPLY
SOURCEID(
PUT0902
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth
Recommended service upgrade and ?
http://www-03.ibm.com/servers/eserver/zseries/zos/servicetst
Should I apply them both?
That is entirely and exclusively your choice. In our shop, we choose to
PUT stands for Program Update Tape, I belive. A PUT tape is ALL the ptfs for
that month. RSU is just the 'important' ones. I think I recall Betty Brody
saying RSU was about 80% of the available PTFs.
Mary Anne
On Wed, Jul 22, 2009 at 7:49 AM, Klein, Kenneth kenneth.kl...@kyfb.comwrote:
There are those that believe that someone had a problem which IBM
fixed. Do I want the same problem?
If you don't the answer is to apply everything. I am in this group. If
I apply 500 ptfs by just including
RSU and HIPERS and 600 by applying everything what's the difference?
The amount and
I ran with the smp control cards I listed earlier. I got a lot of D37's
(11) but many recovered after the compress. Now 5 datasets are still
100% full so I can't tell if the module got loaded or not but probably
not. How can I expand these bad boys? I can iebcopy to a new dataset and
rename but
1) delete/define/copy the failed dataset to a larger size with the
original name. The failing datasets will be identified in SMPLOG.
2) Re-run the apply, unchanged.
OR
1) Create/copy to NEW
2) UPDATE SMP DDDEFs to point to NEW
3) Re-run the apply unchanged
4) UNDO steps 1 and 2. I.e. rename
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth
I ran with the smp control cards I listed earlier. I got a lot of
D37's
(11) but many recovered after the compress. Now 5 datasets are still
100% full so I can't tell if the module got loaded or
John, the problem is that the same name exists on the system I am
running on. I think I might try iehmove.
Ken Klein
Sr. Systems Programmer
Kentucky Farm Bureau Insurance - Louisville
kenneth.kl...@kyfb.com
502-495-5000 x7011
-Original Message-
From: IBM Mainframe Discussion List
Allan, the problem is that the datasets are on the target res vol with
the same name as the dataset on the currently running res vol and they
are catalogged in the master cat. Eg. sys1.serblink, isf..sisfload. I
can iebcopy them to new bigger datasets with new names on the target res
vol but I
Ken,
There is a program on the CBT web site (WWW.CBTTAPE.ORG) that has a rename
program that allows you to rename files that are in use. I can't remember
which file it is, but I'm sure that someone will give the number if you
can't find it. There is also a way to do that with ISPF, to give
AS LONG AS YOU KNOW WHAT YOU'RE DOING, the previously mentioned BYPASSNQ
program is great for reallocating these DSNs or you can stop LLA and
remove the XCFAS enqueues and do it normally BUT .
Jack Kelly
202-502-2390 (Office)
1) Create the new dataset, copy and load.
2) Uncat the new dataset
3) rename the original dataset on the ALTERNATE RESVOL with volser
reference
a) expect dsn in use conflict message. Reply to proceed.
b) if using ISPF you will see: Enter new name below: (The data set
will not be cataloged.)
AS Eric said. There is a facility profile, I think somewhere in the
STGADMIN set, that allows rename of an inuse dataset on a different
volume.
I doubt IEHMOVE will work. I would resist using IEHMOVE for anything.
The only excuse I can still think of would be restoring a file
originally
The approved method is documented in:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S350/2.6.3.4
Basically, there is a RACF profile called STGADMIN.DPDSRN.oldname in the
FACILITY class which can do this. With some restrictions.
--
John McKown
Systems Engineer IV
IT
I don't use it, but SETPROG LNKLST,UNALLOCATE and SETPROG
LNKLST,ALLOCATE...No need to stop LLA
Dave Gibney
Information Technology Services
Washington State University
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John Kelly
Sent:
If the PTF is marked applied, then SMPE is pretty certain that every
piece of it was installed where it should be. If the SMPE is marked
failed, I would expect SMPE to back out any pieces that were installed
before the piece that failed leaving you in the same condition as if you
had never tried
Thanks to all who helped me thru my confusion. I have them all allocated
now with PLENTY of space. The ones I checked were cataloged on
volser(**) so you guys were right about the renames. The message was
pretty scary. I've never had authority to do that before.
Now, could the out-of-space
I prefer to just use the PDS tool (from the CBT Tape) to add an extent to the
dataset (as long as it is not already in 16 extents). If it is already in 16
extents, then you may be able to compress it and release any unused extents -
and then add a large extent.
I also use PDS to add
On Wed, 22 Jul 2009 11:35:25 -0700 Schwarz, Barry A
barry.a.schw...@boeing.com wrote:
:If the PTF is marked applied, then SMPE is pretty certain that every
:piece of it was installed where it should be. If the SMPE is marked
:failed, I would expect SMPE to back out any pieces that were installed
These systems datasets, isf.sisfload for example all were allocated
with 0 for secondary allocation. The compress that smp does when it
finds a full file worked quite well on 6 or the 11 datasets that got
d37's. Dir blocks was not the issue with most of them. I have this all
sorted out now
Ken
You can still use PDS to add extents, even though the secondary is 0.
Klein, Kenneth kenneth.kl...@kyfb.com 7/22/2009 3:06 PM
These systems datasets, isf.sisfload for example all were allocated
with 0 for secondary allocation. The compress that smp does when it
finds a full file worked quite
26 matches
Mail list logo
