Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
I still use IEHPROGM to delete members of a PDS. Because I can... On Thu, Jul 23, 2015 at 7:49 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On 2015-07-22 14:46, John Eells wrote: The syntax is pretty clearly documented in Access Method Services... It is. I was mostly commenting on your brevity. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i2a1/20.1.1?SHELF=all13be9DT=20120126090739CASE= Says: If you are deleting a member of a non-VSAM partitioned data set, the entryname must be specified in the format: pdsname(membername). If you specify the entryname in the format of a partition data set, pdsname(*), the command deletes all the members in the partition data set. Ooooh! But what if you have a member named *? Easy enough to do with standard IBM utilities and documented options nowadays: z/OS V2 R1 BINDER 15:12:43 WEDNESDAY JULY 22, 2015 BATCH EMULATOR JOB(MIXPROG ) STEP(STEP2 ) PGM= IEWL IEW2278I B352 INVOCATION PARAMETERS - CASE=MIXED IEW2322I 1220 1 INCLUDE -ATTR,SYSLIB(IEBGENER) IEW2322I 1220 2 NAME *(R) ... SAVE OPERATION SUMMARY: MEMBER NAME * LOAD LIBRARYSYSUID..TEMP.MIXLIB PROGRAM TYPELOAD MODULE VOLUME SERIAL TSO007 MAX BLOCK 32760 DISPOSITION ADDED NEW TIME OF SAVE15.12.44 JUL 22, 2015 (I know: Don't do that! I'm just wearing my Black Team cape today. Hmmm... Entering D as a line command in a member list deletes only member *; entering DEL /(*) on the DS list deletes * and all other members. Is there any way to specify I want literal member *, not the wildcard? Is there any way to specify that I want exactly those members that begin with a (yes, lower case)?) https://xkcd.com/1532/ ... tells me only (mostly) about DB2. Oops! I meant (I hope): https://www.google.com/search?q=coalesce+site%3Aibm.com I must confess that I see no connection between that xkcd cartoon and DB2. You're right. This comes closer: https://xkcd.com/327/ But maybe this will help? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u2b1/2.3.5.1?SHELF=all13be9DT=20120113165441CASE= Wow! Other contributors here have told me that since I'm not a storage administrator, I should *never* use ADRDSSU. I think I see why. But I believe also that I see some elitism. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Hello All,
Problem got resolved by stopping LLA etc and then renaming those
load module dataset and then creating new . Thanks to all for helping us.
Regards
Venkat.
On Thu, Jul 23, 2015 at 6:27 PM, Mark Pace pacemainl...@gmail.com wrote:
I've was taught the method to copy one RES to another and apply maintenance
to the alternate RES volume(s). And I have had many of the same space
issues being discussed here.
The method you describe of having an install set of RES and HFS volumes
sounds like a better method and I would like to try to setup one of my test
environments to work this way. Is this method documented somewhere?
On Wed, Jul 22, 2015 at 11:01 AM, J O Skip Robinson
jo.skip.robin...@sce.com wrote:
This is the same issue discussed in the recent thread Deleting data sets
in use. Please (re)read the last few posts there. You need additional
SAF
authority in the FACILITY class to give you the option of
renaming/deleting
a data set that *appears* to be in use by virtue of DSN. It's caveat
emptor, so be very careful how you do it. That's the near-term
workaround.
For a long-term solution, I highly recommend doing business in a
different
way. You should not install maintenance directly to *either* of your
'working' sysres volumes. You should maintain a separate install-only set
of sysres and HFS data sets. These should be named with high-level
qualifier(s) unique to your SMPE environment, different from production
and
different from any other z/OS release you need to maintain. For example,
ZOSR21 or ZOSR13. These will never be in use outside of your SMPE
environment. When you're ready to IPL a new maintenance level, copy your
install environment over the alternate sysres environment using
production
HLQs like SYS1.
This is not a trivial change, but you'll be happier once you reach the
goal.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of venkat kulkarni
Sent: Wednesday, July 22, 2015 7:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Library out of space issue while APPLY RSU
I am working as UID 0 with all required authority. I don't see any issue
with it. Still can you please suggest the authority required,So that I
can
cross verify.
Regards
Venkat
On Wed, Jul 22, 2015 at 7:59 PM, Blake, Daniel J [CTR] dbl...@fdic.gov
wrote:
I get a screen that will allow me to override the in-use message.
Perhaps you don't have the authority you need.
Dan Blake
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of venkat kulkarni
Sent: Wednesday, July 22, 2015 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Library out of space issue while APPLY RSU
Hello Dan,
This solution wont work because we are running system
from primary RES volume and applying Maintenence on Alt RES volume and
DDDEF also pointing to Alt RES volume dataset.
Now, When I tried renaming Alt volume dataset with .old extension, I
am getting below error.
ÄÄ
DSLIST - Data Sets on volume RESALT Data set in use
Command - Enter / to select action Message
Volume
---
RSYS1.SASMMOD1
RESALT
* End of Data Set list
ÚÄ
Ä¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try
later or enter HELP for ³ ³ a list of jobs and users allocated to
'SYS1.SASMMOD1'.
³
Regards
Venkat
On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR]
dbl...@fdic.gov
wrote:
Been there, done that. Yes the system has a reserve on the dataset
names. However if you have the proper authority you can:
1. Rename the files using IDCAMS or ISPF 3.4. Make sure you
rename,
not delete them.
2. Then allocate new, larger ones using *.NEW or something that
fits
your naming conventions as the LLQ.
3. Uncatalog the *.NEW data sets.
4. Rename the uncataloged data sets dropping the .NEW LLQ.
5. Rerun your SMP/E jobs.
6. Some point in time delete the old data sets from step 1.
Note: I am assuming that SMP/E is pointing to your maintenance
volume, not your IPL volume.
Dan
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Re: Library out of space issue while APPLY RSU
In caafjfphe+t9tq-kkgoc+a5-acaqqacyv+yznrh+pb7wsefu...@mail.gmail.com, on 07/23/2015 at 07:27 AM, venkat kulkarni venkatkulkarn...@gmail.com said: Can you please provide me full command for increasing size for SASMMOD1 What makes you think you need to. Did you rerun with compesss after expanding the directory? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
I don't know of any IBM doc, but I'm sure that it's been presented in one or more SHARE user sessions over the years. Like cat-skinning, there's more than one way do it. (BTW does the cat care that much on *how* it gets skinned?) Our method may be outre, but we've used it since the advent of ServerPac, which provides a 'temporary' user catalog to manage install data sets. We keep that user catalog for the life of a release. All sysres data sets live on the install pack with their actual 'production' names, e.g. SYS1.LINKLIB. These data sets are referenced externally--including DDDEFs--with an HLQ unique to that release, say ZOSV2R1. This 'artificial' HLQ is an alias that points to the release-specific user catalog, which contains the entry for the actual SYS1.LINKLIB on install sysres V21RES. MCAT alias ZOSV2R1 -- user cat MVSV21.ICF.INSTALL -- NONVSAM--SYS1.LINKLIB on volume V21RES This method, while appearing complex, has some advantages: 1. Install data sets are referenced only by name (including the artificial HLQ), so volser references are never used. This reduces the chance of accidentally hitting the wrong SYS1.LINKLIB to nearly nil. 2. Since the install volume contains DSN SYS1.LINKLIB, the volume can be copied to the alternate sysres without renames. 3. Because install data sets have unique names, phantom ENQs with production names pretty much disappear. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Pace Sent: Thursday, July 23, 2015 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU I've was taught the method to copy one RES to another and apply maintenance to the alternate RES volume(s). And I have had many of the same space issues being discussed here. The method you describe of having an install set of RES and HFS volumes sounds like a better method and I would like to try to setup one of my test environments to work this way. Is this method documented somewhere? On Wed, Jul 22, 2015 at 11:01 AM, J O Skip Robinson jo.skip.robin...@sce.com wrote: This is the same issue discussed in the recent thread Deleting data sets in use. Please (re)read the last few posts there. You need additional SAF authority in the FACILITY class to give you the option of renaming/deleting a data set that *appears* to be in use by virtue of DSN. It's caveat emptor, so be very careful how you do it. That's the near-term workaround. For a long-term solution, I highly recommend doing business in a different way. You should not install maintenance directly to *either* of your 'working' sysres volumes. You should maintain a separate install-only set of sysres and HFS data sets. These should be named with high-level qualifier(s) unique to your SMPE environment, different from production and different from any other z/OS release you need to maintain. For example, ZOSR21 or ZOSR13. These will never be in use outside of your SMPE environment. When you're ready to IPL a new maintenance level, copy your install environment over the alternate sysres environment using production HLQs like SYS1. This is not a trivial change, but you'll be happier once you reach the goal. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU I am working as UID 0 with all required authority. I don't see any issue with it. Still can you please suggest the authority required,So that I can cross verify. Regards Venkat On Wed, Jul 22, 2015 at 7:59 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: I get a screen that will allow me to override the in-use message. Perhaps you don't have the authority you need. Dan Blake -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello Dan, This solution wont work because we are running system from primary RES volume and applying Maintenence on Alt RES volume and DDDEF also pointing to Alt RES volume dataset. Now, When I tried renaming Alt volume dataset with .old extension, I am getting below error. ÄÄ DSLIST
Re: Library out of space issue while APPLY RSU
I've was taught the method to copy one RES to another and apply maintenance
to the alternate RES volume(s). And I have had many of the same space
issues being discussed here.
The method you describe of having an install set of RES and HFS volumes
sounds like a better method and I would like to try to setup one of my test
environments to work this way. Is this method documented somewhere?
On Wed, Jul 22, 2015 at 11:01 AM, J O Skip Robinson
jo.skip.robin...@sce.com wrote:
This is the same issue discussed in the recent thread Deleting data sets
in use. Please (re)read the last few posts there. You need additional SAF
authority in the FACILITY class to give you the option of renaming/deleting
a data set that *appears* to be in use by virtue of DSN. It's caveat
emptor, so be very careful how you do it. That's the near-term workaround.
For a long-term solution, I highly recommend doing business in a different
way. You should not install maintenance directly to *either* of your
'working' sysres volumes. You should maintain a separate install-only set
of sysres and HFS data sets. These should be named with high-level
qualifier(s) unique to your SMPE environment, different from production and
different from any other z/OS release you need to maintain. For example,
ZOSR21 or ZOSR13. These will never be in use outside of your SMPE
environment. When you're ready to IPL a new maintenance level, copy your
install environment over the alternate sysres environment using production
HLQs like SYS1.
This is not a trivial change, but you'll be happier once you reach the
goal.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of venkat kulkarni
Sent: Wednesday, July 22, 2015 7:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Library out of space issue while APPLY RSU
I am working as UID 0 with all required authority. I don't see any issue
with it. Still can you please suggest the authority required,So that I can
cross verify.
Regards
Venkat
On Wed, Jul 22, 2015 at 7:59 PM, Blake, Daniel J [CTR] dbl...@fdic.gov
wrote:
I get a screen that will allow me to override the in-use message.
Perhaps you don't have the authority you need.
Dan Blake
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of venkat kulkarni
Sent: Wednesday, July 22, 2015 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Library out of space issue while APPLY RSU
Hello Dan,
This solution wont work because we are running system
from primary RES volume and applying Maintenence on Alt RES volume and
DDDEF also pointing to Alt RES volume dataset.
Now, When I tried renaming Alt volume dataset with .old extension, I
am getting below error.
ÄÄ
DSLIST - Data Sets on volume RESALT Data set in use
Command - Enter / to select action Message
Volume
---
RSYS1.SASMMOD1
RESALT
* End of Data Set list
ÚÄ
Ä¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try
later or enter HELP for ³ ³ a list of jobs and users allocated to
'SYS1.SASMMOD1'.
³
Regards
Venkat
On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR]
dbl...@fdic.gov
wrote:
Been there, done that. Yes the system has a reserve on the dataset
names. However if you have the proper authority you can:
1. Rename the files using IDCAMS or ISPF 3.4. Make sure you
rename,
not delete them.
2. Then allocate new, larger ones using *.NEW or something that
fits
your naming conventions as the LLQ.
3. Uncatalog the *.NEW data sets.
4. Rename the uncataloged data sets dropping the .NEW LLQ.
5. Rerun your SMP/E jobs.
6. Some point in time delete the old data sets from step 1.
Note: I am assuming that SMP/E is pointing to your maintenance
volume, not your IPL volume.
Dan
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni
Sent: Wednesday, July 22, 2015 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Library out of space issue while APPLY RSU
Hello,
Thanks for reply. Yes, I am applying Maintenance not on
production system. Can you please suggest on the issue I discussed
before.
Regards
Venkat.
On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil
Re: Library out of space issue while APPLY RSU
The STGADMIN profile affects only the ability to rename a dataset whose name matches one in use. You still need the same access you would need to rename the dataset if it were not in use. While not popular, I prefer to create the profile with a wild card in the DSN (or at least part of it) to avoid having to create a profile for each target library that may have this problem -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Thursday, July 23, 2015 2:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Thanks. So you mean to have access on CLASS === FACILITY PROFILE === 'STGADMIN.DPDSRN.SYS1.SASMMOD1' So, while providing access, what should I mention, UACC = NONE and access to my user id is = ALTER Or, something else can be solution on this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Thanks. So you mean to have access on CLASS === FACILITY PROFILE === 'STGADMIN.DPDSRN.SYS1.SASMMOD1' So, while providing access, what should I mention, UACC = NONE and access to my user id is = ALTER Or, something else can be solution on this. On Thu, Jul 23, 2015 at 8:35 AM, Thomas Conley pinnc...@rochester.rr.com wrote: On 7/22/2015 9:57 PM, venkat kulkarni wrote: Hello Tom, Thanks for reply. Can you please provide me full command for increasing size for SASMMOD1 , as I have never used this utility before. My current size is Data Set Name . . . : SYS1.SASMMOD1 General Data Current Allocation Volume serial . . . : RESALTAllocated blocks . : 29 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 10 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent blocks . : 29 Used blocks . . . . : 29 Secondary blocks . : 0 Used extents . . . : 1 Used dir. blocks . : 3 Number of members . : 18 On Thu, Jul 23, 2015 at 7:21 AM, Thomas Conley pinnc...@rochester.rr.com wrote: On 7/22/2015 9:41 PM, venkat kulkarni wrote: Thanks to all. I checked JOB report more carefully and found that COMPRESS and RETRY was specified on the APPLY, so SMP/E was able to recover in most of these cases. If we check the CAUSER SYSMOD SUMMARY REPORT, only SASMMOD1 failed after debatching. An easy option is to enlarge SASMMOD1 using FIXPDS command, but I am not sure how to use this to increase size of this dataset. Can anybody suggest, how can we perform this. Regards Venkat FIXPDS ADDCYL(x) FIXPDS ADDCYL(x) is the command within PDS. If you go to cbttape.org, download file182 and follow the install instructions, you should be able to run the command. If you're a member of SHARE, you can grab my PDS - The Swiss Army Knife of Utilities presentation at share.org, which shows how to exploit PDS. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
On 7/22/2015 11:10 AM, Lizette Koehler wrote: I would suggest you download PDSCLEAN (file 693) from the CBTTAPE.ORG and assm/lked it and use that for emptying the LIBRARIES. Works for PDS and PDS/E datasets. You can empty the library and it looks like it was just allocated. Then you should be able to copy your members to new home. Next, always over allocate your libraries to handle future maintenance. If you use IBM's allocation from Server pac - they are always too small (in my opinion) Lizette I would recommend FIXPDS RESET, from the PDS package, file 182 on your cbttape dial, www.cbttape.org. It zeroes out the directory and makes it look like an empty PDS. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
There's no such thing as forever-good values. No one knows what new-function enhancements will flow down the pipeline during a z/OS release. Here's the best you can do: 1. Configure your environment to ease the task of dataset enlargement, e.g. unique HLQ for SMPE target datasets. 2. Move datasets off the sysres to xxxCAT or xxxDLB if they are not needed at execution time. 3. Acquire/master tools like the PDS command that facilitate non-disruptive expansion. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Wednesday, July 22, 2015 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU pinnc...@rochester.rr.com (Thomas Conley) wrote: On 7/22/2015 11:10 AM, Lizette Koehler wrote: snip Next, always over allocate your libraries to handle future maintenance. If you use IBM's allocation from Server pac - they are always too small (in my opinion) Yeah, we can't win there. Make them big enough for installing lots service and people complain about the space they need. Make them as small as practical so people don't need as much disk space, and people complain that they run out of space installing service. We try to manage the algebraic sum to minimize the noise (grin). I would recommend FIXPDS RESET, from the PDS package, file 182 on your cbttape dial, www.cbttape.org. It zeroes out the directory and makes it look like an empty PDS. So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
pinnc...@rochester.rr.com (Thomas Conley) wrote: On 7/22/2015 11:10 AM, Lizette Koehler wrote: snip Next, always over allocate your libraries to handle future maintenance. If you use IBM's allocation from Server pac - they are always too small (in my opinion) Yeah, we can't win there. Make them big enough for installing lots service and people complain about the space they need. Make them as small as practical so people don't need as much disk space, and people complain that they run out of space installing service. We try to manage the algebraic sum to minimize the noise (grin). I would recommend FIXPDS RESET, from the PDS package, file 182 on your cbttape dial, www.cbttape.org. It zeroes out the directory and makes it look like an empty PDS. So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
The PDS command (or StarTool) can also be used add directory blocks dynamically. Also to compress a PDS with 'SHR'. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas Conley Sent: Wednesday, July 22, 2015 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU On 7/22/2015 11:10 AM, Lizette Koehler wrote: I would suggest you download PDSCLEAN (file 693) from the CBTTAPE.ORG and assm/lked it and use that for emptying the LIBRARIES. Works for PDS and PDS/E datasets. You can empty the library and it looks like it was just allocated. Then you should be able to copy your members to new home. Next, always over allocate your libraries to handle future maintenance. If you use IBM's allocation from Server pac - they are always too small (in my opinion) Lizette I would recommend FIXPDS RESET, from the PDS package, file 182 on your cbttape dial, www.cbttape.org. It zeroes out the directory and makes it look like an empty PDS. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
You need a access to the Facility class resource : STGADMIN.DPDSRN.olddsname Controls the ability to rename a non-SMS-managed data set whose name is in use in another address space. You can regard them as having duplicate data set names. olddsname is up to 23 characters of the existing data set name. You can use a generic class name such as STGADMIN.DPDSRN.SYS2.*. Recommendation: Do not give anyone authority to STGADMIN.DPDSRN.* because it is too broad. This option should be used with extreme caution. Very few people should have RACF authority to STGADMIN.DPDSRN.olddsname. Use this option only if you know the data set is not open on any system. For details of how to use this, see z/OS DFSMSdfp Advanced Services. Doug On Wed, 22 Jul 2015 20:05:39 +0530, venkat kulkarni venkatkulkarn...@gmail.com wrote: I am working as UID 0 with all required authority. I don't see any issue with it. Still can you please suggest the authority required,So that I can cross verify. Regards Venkat On Wed, Jul 22, 2015 at 7:59 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: I get a screen that will allow me to override the in-use message. Perhaps you don't have the authority you need. Dan Blake -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello Dan, This solution wont work because we are running system from primary RES volume and applying Maintenence on Alt RES volume and DDDEF also pointing to Alt RES volume dataset. Now, When I tried renaming Alt volume dataset with .old extension, I am getting below error. ÄÄ DSLIST - Data Sets on volume RESALT Data set in use Command - Enter / to select action Message Volume --- RSYS1.SASMMOD1 RESALT * End of Data Set list ÚÄÄ¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try later or enter HELP for ³ ³ a list of jobs and users allocated to 'SYS1.SASMMOD1'. ³ Regards Venkat On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: Been there, done that. Yes the system has a reserve on the dataset names. However if you have the proper authority you can: 1. Rename the files using IDCAMS or ISPF 3.4. Make sure you rename, not delete them. 2. Then allocate new, larger ones using *.NEW or something that fits your naming conventions as the LLQ. 3. Uncatalog the *.NEW data sets. 4. Rename the uncataloged data sets dropping the .NEW LLQ. 5. Rerun your SMP/E jobs. 6. Some point in time delete the old data sets from step 1. Note: I am assuming that SMP/E is pointing to your maintenance volume, not your IPL volume. Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG
Re: Library out of space issue while APPLY RSU
I would suggest you download PDSCLEAN (file 693) from the CBTTAPE.ORG and assm/lked it and use that for emptying the LIBRARIES. Works for PDS and PDS/E datasets. You can empty the library and it looks like it was just allocated. Then you should be able to copy your members to new home. Next, always over allocate your libraries to handle future maintenance. If you use IBM's allocation from Server pac - they are always too small (in my opinion) Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 2:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
J O Skip Robinson wrote: ...When you're ready to IPL a new maintenance level, copy your install environment over the alternate sysres environment using production HLQs like SYS1. Exactly. And I'd like to add that one big benefit of the copy step on a test system is that you get some implementation experience prior to that first prod system, where you want no surprises and no mistakes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Based on the E37, CNMLINK already has multiple extents. When you reallocate it on your target volume, give it a larger secondary quantity. You may also need to adjust the primary quantity. NUCLEUS cannot tolerate extents. It needs to be large enough to accept any possible single SYSMOD. There is an SMPE option to automatically compress a PDS that experiences a D37 and retry the action. Using this option, when a subsequent SYSMOD runs out of space, the PDS is compressed and hopefully the recovered space (gas created by previous SYSMODs) is sufficient to accommodate the new SYSMOD. It is not a popular approach but LNKLST PDSes work perfectly well if they occupy multiple extents ***at the time you IPL***. There is no problem unless a PDS grows into another extent while it is use. But this should not even be necessary. When it is time to copy your target PDSes to production, you can see how much space each occupies and reallocate any production PDS that is too small before you perform the copy. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 2:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Speaking of NUCLEUS, there shouldn't be any ENQs or other difficulties with this one. It is not used after IPL. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Based on the E37, CNMLINK already has multiple extents. When you reallocate it on your target volume, give it a larger secondary quantity. You may also need to adjust the primary quantity. NUCLEUS cannot tolerate extents. It needs to be large enough to accept any possible single SYSMOD. There is an SMPE option to automatically compress a PDS that experiences a D37 and retry the action. Using this option, when a subsequent SYSMOD runs out of space, the PDS is compressed and hopefully the recovered space (gas created by previous SYSMODs) is sufficient to accommodate the new SYSMOD. It is not a popular approach but LNKLST PDSes work perfectly well if they occupy multiple extents ***at the time you IPL***. There is no problem unless a PDS grows into another extent while it is use. But this should not even be necessary. When it is time to copy your target PDSes to production, you can see how much space each occupies and reallocate any production PDS that is too small before you perform the copy. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 2:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
The below discussions show the value of having your SMP/E target datasets under names that are not used for your running system. You then are able to apply maintenance as needed to the Target datasets and manipulate them as needed during the maintenance cycle. You can then copy those Target datasets to the Alt Resvol using the Running Names without impact. Examples would be SMPE points to SYS1X for your Tgt libraries, Then DFDSS with RenameU SYS1X to SYS1 can build the pack. ( We also maintain a different HLQ for the Dlibs so as to make Tgt and Dlibs easy to separate) Jerry Whitteridge Lead Systems Engineer Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Based on the E37, CNMLINK already has multiple extents. When you reallocate it on your target volume, give it a larger secondary quantity. You may also need to adjust the primary quantity. NUCLEUS cannot tolerate extents. It needs to be large enough to accept any possible single SYSMOD. There is an SMPE option to automatically compress a PDS that experiences a D37 and retry the action. Using this option, when a subsequent SYSMOD runs out of space, the PDS is compressed and hopefully the recovered space (gas created by previous SYSMODs) is sufficient to accommodate the new SYSMOD. It is not a popular approach but LNKLST PDSes work perfectly well if they occupy multiple extents ***at the time you IPL***. There is no problem unless a PDS grows into another extent while it is use. But this should not even be necessary. When it is time to copy your target PDSes to production, you can see how much space each occupies and reallocate any production PDS that is too small before you perform the copy. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 2:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
John Eells wrote: Yeah, we can't win there. You can and you have already won. The fact is, with each system there is a list of space requirements in the program directory and/or installation manual. Use these lists and add about 10-50% or more extra depending on your own requirements and past installations. PDS and PDSE directories are somewhat trickier to do estimates of course. Make them big enough for installing lots service and people complain about the space they need. Back to that list of datasets and their spaces. About those RACF profiles discussion, being a RACF guy (and ex-SMP/E + Storage guy), I will *not* give access to delete/rename *in-use* datasets. And *no* ALTER between Sysplexes. Only ALTER on one Sysplex and at most UPDATE on others. My storage guys loves me... ;-) Groete / Greetings Elardus Engelbrecht Friday ( really, I wish it is Friday today...) joke: WARNING - DO NOT LAUGH... ;-D To catch a thief Japan invented a machine to catch thieves. America tried it out and it could catch 5 thieves in 35 minutes. England also tried it out. 7 thieves in 30 minutes. Brazil, 400 thieves in 20 minutes. Uganda, h, 6000 thieves in 17 minutes. Not that bad. South Africa - that machine was stolen in 2 minutes. I told you *not* to laugh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
ee...@us.ibm.com (John Eells) wrote: pinnc...@rochester.rr.com (Thomas Conley) wrote: snip I would recommend FIXPDS RESET, from the PDS package, file 182 on your cbttape dial, www.cbttape.org. It zeroes out the directory and makes it look like an empty PDS. So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. The guy who wrote the code (thanks, Steve!) tells me we did this in z/OS V1.12, so all releases that are still in service include this function, and there is no need to get FIXPDS or write your own code. (STOW INIT [actually, STOW ... ,I] leaves behind an empty partitioned data set that need not be compressed.) -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
elardus.engelbre...@sita.co.za (Elardus Engelbrecht) wrote: John Eells wrote: Yeah, we can't win there. You can and you have already won. The fact is, with each system there is a list of space requirements in the program directory and/or installation manual. Use these lists and add about 10-50% or more extra depending on your own requirements and past installations. PDS and PDSE directories are somewhat trickier to do estimates of course. I hope to be able to get rid of program directories some day. But in the meantime: Anything released in the past 15-20 years has listed the space required for each data set using a standard block size (SDB for most, 32,760 for load libraries, and a specific block size for fonts, if memory serves). Anything older that that uses (for the most part) arbitrary block sizes, and for a variety of historical reasons, such a product might have a program directory that significantly mis-states space requirements in either direction. Further, products tend to grow as PTFs get applied, and older products can have had significant growth since new. I'd guess that there are plenty of older products still around and in use. Theoretically, ignoring the problem above, to find the space for, say, LINKLIB, you to find the space required for all of the products that have one or more members in it and add them all together. Once you're done, if all the space tables in all those program directories are perfect, you will have a total that is larger than necessary because we don't list fractions of tracks (or cylinders) in program directories. You will have a directory allocation that's larger than necessary for the same reason. Repeat for all the rest of the shared data sets, with similar results. Now, I'll certainly admit that larger than necessary certainly beats smaller than necessary, but this isn't ideal for a broadly shared data set. Then, there are special cases, like NUCLEUS (another shared data set), where the size of the largest member plus some fudge factor to allow for growth of that member has to be available as minimum free space to be able to have a reasonable chance of updating it without a space abend. That number plus the normal free space buffer have to be added to arrive at an appropriate free space value. This is why ServerPac production detects the space actually used by each data set after they are populated, adds a percentage of free space (and directory space), and handles the special cases to create the space values in the configuration table that is used to allocate the data sets on your end. This is also the primary reason ServerPac no longer lets you change the block size in the installation dialog. Choosing other values just let people run out of space faster, and in some cases even fail to load the data sets in the first place. The free space I was referring to when I said we couldn't win is the default space we ship for each data set in those tables used to allocate the data sets. The free space in those tables is an imperfect compromise between minimizing disk space requirements for installation and limiting your exposure to x37 abends when installing service. For making reasonably sure you can put on a few years' worth of RSU service, the combination of ServerPac's View and Change option of Modify System Layout and the CH(ange) SP(ace) command is your friend. It will let you increase the space for whatever subsets of the data sets in the configuration you want by whatever percentage you deem appropriate to allow for future service. At some point we should reopen the discussion about how much free space is enough without it being too much. The last time we had it, people were leaning toward more than we provide as a default today, but we knew z/OS V2.1 was going to have a significant bump in required space because of the new font element, and 2.2 a somewhat smaller one because it includes z/OSMF, so I thought letting the dust settle first might be good. If we're looking at this the wrong way, don't be shy about telling us so! snip -- John Eells (Product packaging and ServerPac Design alumnus) z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
On 7/22/2015 3:59 PM, Paul Gilmartin wrote: On 2015-07-22 13:45, John Eells wrote: So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. Syntax? delete pds.name(*) That would appear to DELETE the entire library. But DELETE followed by reallocate is certainly a valid approach. Why not? See above. It's easier. The guy who wrote the code (thanks, Steve!) tells me we did this in z/OS V1.12, so all releases that are still in service include this function, and there is no need to get FIXPDS or write your own code. Clearly a different Steve: https://xkcd.com/1532/ I haven't had the pleasure of meeting either of them. (STOW INIT [actually, STOW ... ,I] leaves behind an empty partitioned data set that need not be compressed.) Is there a non-assembler interface for this? Seems a good candidate for ISPF DSLIST. Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
On 2015-07-22 13:45, John Eells wrote: So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. Syntax? That would appear to DELETE the entire library. But DELETE followed by reallocate is certainly a valid approach. Why not? The guy who wrote the code (thanks, Steve!) tells me we did this in z/OS V1.12, so all releases that are still in service include this function, and there is no need to get FIXPDS or write your own code. Clearly a different Steve: https://xkcd.com/1532/ (STOW INIT [actually, STOW ... ,I] leaves behind an empty partitioned data set that need not be compressed.) Is there a non-assembler interface for this? Seems a good candidate for ISPF DSLIST. Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Library out of space issue while APPLY RSU
Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
On 2015-07-22 14:45, Chris Hoelscher wrote: An approach I have taken the past several years ... /* REXX */ /* DELETE ALL MEMBERS OF A GIVEN LIBRARY DSN */ /* TRACE 'R' */ /* TRACE 'O' */ Ouch! Are there errors you choose to have unreported? DSNAME = 'dataset name' DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE = ' QDSN = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */ But what if your user expects TSO prefixing conventions? I'd just leave the quotes or not, whatever was supplied. ADDRESS ISPEXEC LMINIT DATAID( MYDATAID) DATASET( QDSN ) ENQ(SHRW) LMOPEN DATAID(MYDATAID) OPTION(OUTPUT) LMMDEL DATAID(MYDATAID) MEMBER(*) Does ISPF optize this to STOW I? I sometimes sort a member list descending before deleting everything, assuming this results in less thrashing of the directory. LMCLOSE DATAID(MYDATAID) LMFREE DATAID(MYDATAID) SAY DSN IS NOW EMPTY And you needn't even compress it. If it's a PDSE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
On 7/22/2015 9:41 PM, venkat kulkarni wrote: Thanks to all. I checked JOB report more carefully and found that COMPRESS and RETRY was specified on the APPLY, so SMP/E was able to recover in most of these cases. If we check the CAUSER SYSMOD SUMMARY REPORT, only SASMMOD1 failed after debatching. An easy option is to enlarge SASMMOD1 using FIXPDS command, but I am not sure how to use this to increase size of this dataset. Can anybody suggest, how can we perform this. Regards Venkat FIXPDS ADDCYL(x) Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Hello Tom, Thanks for reply. Can you please provide me full command for increasing size for SASMMOD1 , as I have never used this utility before. My current size is Data Set Name . . . : SYS1.SASMMOD1 General Data Current Allocation Volume serial . . . : RESALTAllocated blocks . : 29 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 10 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent blocks . : 29 Used blocks . . . . : 29 Secondary blocks . : 0 Used extents . . . : 1 Used dir. blocks . : 3 Number of members . : 18 On Thu, Jul 23, 2015 at 7:21 AM, Thomas Conley pinnc...@rochester.rr.com wrote: On 7/22/2015 9:41 PM, venkat kulkarni wrote: Thanks to all. I checked JOB report more carefully and found that COMPRESS and RETRY was specified on the APPLY, so SMP/E was able to recover in most of these cases. If we check the CAUSER SYSMOD SUMMARY REPORT, only SASMMOD1 failed after debatching. An easy option is to enlarge SASMMOD1 using FIXPDS command, but I am not sure how to use this to increase size of this dataset. Can anybody suggest, how can we perform this. Regards Venkat FIXPDS ADDCYL(x) Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Thanks to all. I checked JOB report more carefully and found that COMPRESS and RETRY was specified on the APPLY, so SMP/E was able to recover in most of these cases. If we check the CAUSER SYSMOD SUMMARY REPORT, only SASMMOD1 failed after debatching. An easy option is to enlarge SASMMOD1 using FIXPDS command, but I am not sure how to use this to increase size of this dataset. Can anybody suggest, how can we perform this. Regards Venkat On Thu, Jul 23, 2015 at 12:16 AM, John Eells ee...@us.ibm.com wrote: elardus.engelbre...@sita.co.za (Elardus Engelbrecht) wrote: John Eells wrote: Yeah, we can't win there. You can and you have already won. The fact is, with each system there is a list of space requirements in the program directory and/or installation manual. Use these lists and add about 10-50% or more extra depending on your own requirements and past installations. PDS and PDSE directories are somewhat trickier to do estimates of course. I hope to be able to get rid of program directories some day. But in the meantime: Anything released in the past 15-20 years has listed the space required for each data set using a standard block size (SDB for most, 32,760 for load libraries, and a specific block size for fonts, if memory serves). Anything older that that uses (for the most part) arbitrary block sizes, and for a variety of historical reasons, such a product might have a program directory that significantly mis-states space requirements in either direction. Further, products tend to grow as PTFs get applied, and older products can have had significant growth since new. I'd guess that there are plenty of older products still around and in use. Theoretically, ignoring the problem above, to find the space for, say, LINKLIB, you to find the space required for all of the products that have one or more members in it and add them all together. Once you're done, if all the space tables in all those program directories are perfect, you will have a total that is larger than necessary because we don't list fractions of tracks (or cylinders) in program directories. You will have a directory allocation that's larger than necessary for the same reason. Repeat for all the rest of the shared data sets, with similar results. Now, I'll certainly admit that larger than necessary certainly beats smaller than necessary, but this isn't ideal for a broadly shared data set. Then, there are special cases, like NUCLEUS (another shared data set), where the size of the largest member plus some fudge factor to allow for growth of that member has to be available as minimum free space to be able to have a reasonable chance of updating it without a space abend. That number plus the normal free space buffer have to be added to arrive at an appropriate free space value. This is why ServerPac production detects the space actually used by each data set after they are populated, adds a percentage of free space (and directory space), and handles the special cases to create the space values in the configuration table that is used to allocate the data sets on your end. This is also the primary reason ServerPac no longer lets you change the block size in the installation dialog. Choosing other values just let people run out of space faster, and in some cases even fail to load the data sets in the first place. The free space I was referring to when I said we couldn't win is the default space we ship for each data set in those tables used to allocate the data sets. The free space in those tables is an imperfect compromise between minimizing disk space requirements for installation and limiting your exposure to x37 abends when installing service. For making reasonably sure you can put on a few years' worth of RSU service, the combination of ServerPac's View and Change option of Modify System Layout and the CH(ange) SP(ace) command is your friend. It will let you increase the space for whatever subsets of the data sets in the configuration you want by whatever percentage you deem appropriate to allow for future service. At some point we should reopen the discussion about how much free space is enough without it being too much. The last time we had it, people were leaning toward more than we provide as a default today, but we knew z/OS V2.1 was going to have a significant bump in required space because of the new font element, and 2.2 a somewhat smaller one because it includes z/OSMF, so I thought letting the dust settle first might be good. If we're looking at this the wrong way, don't be shy about telling us so! snip -- John Eells (Product packaging and ServerPac Design alumnus) z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
On 7/22/2015 9:57 PM, venkat kulkarni wrote: Hello Tom, Thanks for reply. Can you please provide me full command for increasing size for SASMMOD1 , as I have never used this utility before. My current size is Data Set Name . . . : SYS1.SASMMOD1 General Data Current Allocation Volume serial . . . : RESALTAllocated blocks . : 29 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 10 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent blocks . : 29 Used blocks . . . . : 29 Secondary blocks . : 0 Used extents . . . : 1 Used dir. blocks . : 3 Number of members . : 18 On Thu, Jul 23, 2015 at 7:21 AM, Thomas Conley pinnc...@rochester.rr.com wrote: On 7/22/2015 9:41 PM, venkat kulkarni wrote: Thanks to all. I checked JOB report more carefully and found that COMPRESS and RETRY was specified on the APPLY, so SMP/E was able to recover in most of these cases. If we check the CAUSER SYSMOD SUMMARY REPORT, only SASMMOD1 failed after debatching. An easy option is to enlarge SASMMOD1 using FIXPDS command, but I am not sure how to use this to increase size of this dataset. Can anybody suggest, how can we perform this. Regards Venkat FIXPDS ADDCYL(x) FIXPDS ADDCYL(x) is the command within PDS. If you go to cbttape.org, download file182 and follow the install instructions, you should be able to run the command. If you're a member of SHARE, you can grab my PDS - The Swiss Army Knife of Utilities presentation at share.org, which shows how to exploit PDS. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
DEL (*) gives invalid dataset name However: DEL /(*) gives me an empty PDS and IDC0553I ALL MEMBERS IN DATA SET RRP4912.TEMP.JCL DELETED In addition, it works on an empty PDS to free space (as I expected it to). Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Wednesday, July 22, 2015 3:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU) 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: On 2015-07-22 13:45, John Eells wrote: So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. Syntax? That would appear to DELETE the entire library. But DELETE followed by reallocate is certainly a valid approach. Why not? The syntax is pretty clearly documented in Access Method Services...though the book does not say a compress is unecessary afterward. Feel free to submit a comment if you believe it should, or if you think the syntax's description needs to be better: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i2a1/20.1.1?SHELF=all13be9DT=20120126090739CASE= Says: If you are deleting a member of a non-VSAM partitioned data set, the entryname must be specified in the format: pdsname(membername). If you specify the entryname in the format of a partition data set, pdsname(*), the command deletes all the members in the partition data set. Why not just delete and reallocate the data set? A number of reasons. You might not have ALTER access to the data set. There is no assurance it will wind up in the same place (or even fit on the same volume) in the general case. Other possible reasons why not are left as an Exercise to the Alert Reader. snip Is there a non-assembler interface for this? Seems a good candidate for ISPF DSLIST. IDCAMS DELETE *is* a non-assembler interface (grin). OK, more seriously, I have not played with this in ISPF OPT3.4 to see whether using DEL (*) would work as a line command. You could try it and let us know...maybe what you want is already there. ;-) Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. I must confess that I see no connection between that xkcd cartoon and DB2. But maybe this will help? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u2b1/2.3.5.1?SHELF=all13be9DT=20120113165441CASE= -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
An approach I have taken the past several years ... /* REXX */ /* DELETE ALL MEMBERS OF A GIVEN LIBRARY DSN */ /* TRACE 'R' */ /* TRACE 'O' */ DSNAME = 'dataset name' DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE = ' QDSN = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */ ADDRESS ISPEXEC LMINIT DATAID( MYDATAID) DATASET( QDSN ) ENQ(SHRW) LMOPEN DATAID(MYDATAID) OPTION(OUTPUT) LMMDEL DATAID(MYDATAID) MEMBER(*) LMCLOSE DATAID(MYDATAID) LMFREE DATAID(MYDATAID) SAY DSN IS NOW EMPTY Chris hoelscher Technology Architect Database Infrastructure Services Technology Solution Services 123 East Main Street Louisville, KY 40202 choelsc...@humana.com Humana.com (502) 714-8615 (502) 476-2538 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Wednesday, July 22, 2015 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU) ee...@us.ibm.commailto:ee...@us.ibm.com (John Eells) wrote: pinnc...@rochester.rr.commailto:pinnc...@rochester.rr.com (Thomas Conley) wrote: snip I would recommend FIXPDS RESET, from the PDS package, file 182 on your cbttape dial, www.cbttape.orghttp://www.cbttape.org. It zeroes out the directory and makes it look like an empty PDS. So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. The guy who wrote the code (thanks, Steve!) tells me we did this in z/OS V1.12, so all releases that are still in service include this function, and there is no need to get FIXPDS or write your own code. (STOW INIT [actually, STOW ... ,I] leaves behind an empty partitioned data set that need not be compressed.) -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.commailto:ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
On 2015-07-22 14:38, Bob Rutledge wrote: delete pds.name(*) Is there a non-assembler interface for this? Seems a good candidate for ISPF DSLIST. OK. TSO line command; nothing in ISPF DSLIST? Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. Oops. Forgot to copy before I pasted: coalesce site:ibm.com -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
On 2015-07-22 14:46, John Eells wrote: The syntax is pretty clearly documented in Access Method Services... It is. I was mostly commenting on your brevity. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i2a1/20.1.1?SHELF=all13be9DT=20120126090739CASE= Says: If you are deleting a member of a non-VSAM partitioned data set, the entryname must be specified in the format: pdsname(membername). If you specify the entryname in the format of a partition data set, pdsname(*), the command deletes all the members in the partition data set. Ooooh! But what if you have a member named *? Easy enough to do with standard IBM utilities and documented options nowadays: z/OS V2 R1 BINDER 15:12:43 WEDNESDAY JULY 22, 2015 BATCH EMULATOR JOB(MIXPROG ) STEP(STEP2 ) PGM= IEWL IEW2278I B352 INVOCATION PARAMETERS - CASE=MIXED IEW2322I 1220 1 INCLUDE -ATTR,SYSLIB(IEBGENER) IEW2322I 1220 2 NAME *(R) ... SAVE OPERATION SUMMARY: MEMBER NAME * LOAD LIBRARYSYSUID..TEMP.MIXLIB PROGRAM TYPELOAD MODULE VOLUME SERIAL TSO007 MAX BLOCK 32760 DISPOSITION ADDED NEW TIME OF SAVE15.12.44 JUL 22, 2015 (I know: Don't do that! I'm just wearing my Black Team cape today. Hmmm... Entering D as a line command in a member list deletes only member *; entering DEL /(*) on the DS list deletes * and all other members. Is there any way to specify I want literal member *, not the wildcard? Is there any way to specify that I want exactly those members that begin with a (yes, lower case)?) https://xkcd.com/1532/ ... tells me only (mostly) about DB2. Oops! I meant (I hope): https://www.google.com/search?q=coalesce+site%3Aibm.com I must confess that I see no connection between that xkcd cartoon and DB2. You're right. This comes closer: https://xkcd.com/327/ But maybe this will help? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u2b1/2.3.5.1?SHELF=all13be9DT=20120113165441CASE= Wow! Other contributors here have told me that since I'm not a storage administrator, I should *never* use ADRDSSU. I think I see why. But I believe also that I see some elitism. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: On 2015-07-22 13:45, John Eells wrote: So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. Syntax? That would appear to DELETE the entire library. But DELETE followed by reallocate is certainly a valid approach. Why not? The syntax is pretty clearly documented in Access Method Services...though the book does not say a compress is unecessary afterward. Feel free to submit a comment if you believe it should, or if you think the syntax's description needs to be better: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i2a1/20.1.1?SHELF=all13be9DT=20120126090739CASE= Says: If you are deleting a member of a non-VSAM partitioned data set, the entryname must be specified in the format: pdsname(membername). If you specify the entryname in the format of a partition data set, pdsname(*), the command deletes all the members in the partition data set. Why not just delete and reallocate the data set? A number of reasons. You might not have ALTER access to the data set. There is no assurance it will wind up in the same place (or even fit on the same volume) in the general case. Other possible reasons why not are left as an Exercise to the Alert Reader. snip Is there a non-assembler interface for this? Seems a good candidate for ISPF DSLIST. IDCAMS DELETE *is* a non-assembler interface (grin). OK, more seriously, I have not played with this in ISPF OPT3.4 to see whether using DEL (*) would work as a line command. You could try it and let us know...maybe what you want is already there. ;-) Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. I must confess that I see no connection between that xkcd cartoon and DB2. But maybe this will help? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u2b1/2.3.5.1?SHELF=all13be9DT=20120113165441CASE= -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
OK, poor choice of words, it doesn't free the space, it compresses it. Either way, I didn't know IDCAMS had been enhanced like this, so Thanks Steve! Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Wednesday, July 22, 2015 3:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU) DEL (*) gives invalid dataset name However: DEL /(*) gives me an empty PDS and IDC0553I ALL MEMBERS IN DATA SET RRP4912.TEMP.JCL DELETED In addition, it works on an empty PDS to free space (as I expected it to). Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Wednesday, July 22, 2015 3:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU) 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: On 2015-07-22 13:45, John Eells wrote: So does IDCAMS DELETE these days (I forget when we added this). Both likely use STOW INIT. Syntax? That would appear to DELETE the entire library. But DELETE followed by reallocate is certainly a valid approach. Why not? The syntax is pretty clearly documented in Access Method Services...though the book does not say a compress is unecessary afterward. Feel free to submit a comment if you believe it should, or if you think the syntax's description needs to be better: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i2a1/20.1.1?SHELF=all13be9DT=20120126090739CASE= Says: If you are deleting a member of a non-VSAM partitioned data set, the entryname must be specified in the format: pdsname(membername). If you specify the entryname in the format of a partition data set, pdsname(*), the command deletes all the members in the partition data set. Why not just delete and reallocate the data set? A number of reasons. You might not have ALTER access to the data set. There is no assurance it will wind up in the same place (or even fit on the same volume) in the general case. Other possible reasons why not are left as an Exercise to the Alert Reader. snip Is there a non-assembler interface for this? Seems a good candidate for ISPF DSLIST. IDCAMS DELETE *is* a non-assembler interface (grin). OK, more seriously, I have not played with this in ISPF OPT3.4 to see whether using DEL (*) would work as a line command. You could try it and let us know...maybe what you want is already there. ;-) Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. I must confess that I see no connection between that xkcd cartoon and DB2. But maybe this will help? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u2b1/2.3.5.1?SHELF=all13be9DT=20120113165441CASE= -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email
Re: Cleaning Out a PDS (Was Re: Library out of space issue while APPLY RSU)
On Wed, Jul 22, 2015 at 3:38 PM, Bob Rutledge deerh...@ix.netcom.com wrote: On 7/22/2015 3:59 PM, Paul Gilmartin wrote: deleted Lately I asked here how I might coalesce data set extents (I've been using HMIGRATE/HRECALL.) Someone said IBM supplies such a utility now. Google is not my friend here: https://xkcd.com/1532/ ... tells me only (mostly) about DB2. Bob ADRDSSU has the command Consolidate which can be used with a list of datasets or wildcard qualifier. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
I would not use ISPF for copying. Use IEBCOPY in batch. ISPF copying used to drop the aliases although I don't know if it still does. Batch will also be a lot faster and won't tie up your TSO session while doing it. You will also have a record of what was done with the batch jobs being on the output queue. My opinion and not that of my employer, IBM. Thank You, Paul Strauss IBM Global Services z/OS MVS and Program Products Department F2VE 150 Kettletown Rd. Southbury, CT 06488 (203) 272-2758 strau...@us.ibm.com NOTICE: This e-mail message and all attachments may contain confidential information intended solely for the use of the addressee. If you are not the intended recipient, you are hereby notified that you may not read, copy, distribute or otherwise use this message or its attachments. If you have received this message in error, please notify the sender by email and delete all copies of the message immediately. From: venkat kulkarni venkatkulkarn...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/22/2015 09:41 AM Subject:Re: Library out of space issue while APPLY RSU Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
This is the same issue discussed in the recent thread Deleting data sets in use. Please (re)read the last few posts there. You need additional SAF authority in the FACILITY class to give you the option of renaming/deleting a data set that *appears* to be in use by virtue of DSN. It's caveat emptor, so be very careful how you do it. That's the near-term workaround. For a long-term solution, I highly recommend doing business in a different way. You should not install maintenance directly to *either* of your 'working' sysres volumes. You should maintain a separate install-only set of sysres and HFS data sets. These should be named with high-level qualifier(s) unique to your SMPE environment, different from production and different from any other z/OS release you need to maintain. For example, ZOSR21 or ZOSR13. These will never be in use outside of your SMPE environment. When you're ready to IPL a new maintenance level, copy your install environment over the alternate sysres environment using production HLQs like SYS1. This is not a trivial change, but you'll be happier once you reach the goal. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU I am working as UID 0 with all required authority. I don't see any issue with it. Still can you please suggest the authority required,So that I can cross verify. Regards Venkat On Wed, Jul 22, 2015 at 7:59 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: I get a screen that will allow me to override the in-use message. Perhaps you don't have the authority you need. Dan Blake -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello Dan, This solution wont work because we are running system from primary RES volume and applying Maintenence on Alt RES volume and DDDEF also pointing to Alt RES volume dataset. Now, When I tried renaming Alt volume dataset with .old extension, I am getting below error. ÄÄ DSLIST - Data Sets on volume RESALT Data set in use Command - Enter / to select action Message Volume --- RSYS1.SASMMOD1 RESALT * End of Data Set list ÚÄ Ä¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try later or enter HELP for ³ ³ a list of jobs and users allocated to 'SYS1.SASMMOD1'. ³ Regards Venkat On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: Been there, done that. Yes the system has a reserve on the dataset names. However if you have the proper authority you can: 1. Rename the files using IDCAMS or ISPF 3.4. Make sure you rename, not delete them. 2. Then allocate new, larger ones using *.NEW or something that fits your naming conventions as the LLQ. 3. Uncatalog the *.NEW data sets. 4. Rename the uncataloged data sets dropping the .NEW LLQ. 5. Rerun your SMP/E jobs. 6. Some point in time delete the old data sets from step 1. Note: I am assuming that SMP/E is pointing to your maintenance volume, not your IPL volume. Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.au mailto:pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group
Re: Library out of space issue while APPLY RSU
Been there, done that. Yes the system has a reserve on the dataset names. However if you have the proper authority you can: 1. Rename the files using IDCAMS or ISPF 3.4. Make sure you rename, not delete them. 2. Then allocate new, larger ones using *.NEW or something that fits your naming conventions as the LLQ. 3. Uncatalog the *.NEW data sets. 4. Rename the uncataloged data sets dropping the .NEW LLQ. 5. Rerun your SMP/E jobs. 6. Some point in time delete the old data sets from step 1. Note: I am assuming that SMP/E is pointing to your maintenance volume, not your IPL volume. Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.aumailto:pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
Hello Dan, This solution wont work because we are running system from primary RES volume and applying Maintenence on Alt RES volume and DDDEF also pointing to Alt RES volume dataset. Now, When I tried renaming Alt volume dataset with .old extension, I am getting below error. ÄÄ DSLIST - Data Sets on volume RESALT Data set in use Command - Enter / to select action Message Volume --- RSYS1.SASMMOD1 RESALT * End of Data Set list ÚÄÄ¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try later or enter HELP for ³ ³ a list of jobs and users allocated to 'SYS1.SASMMOD1'. ³ Regards Venkat On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: Been there, done that. Yes the system has a reserve on the dataset names. However if you have the proper authority you can: 1. Rename the files using IDCAMS or ISPF 3.4. Make sure you rename, not delete them. 2. Then allocate new, larger ones using *.NEW or something that fits your naming conventions as the LLQ. 3. Uncatalog the *.NEW data sets. 4. Rename the uncataloged data sets dropping the .NEW LLQ. 5. Rerun your SMP/E jobs. 6. Some point in time delete the old data sets from step 1. Note: I am assuming that SMP/E is pointing to your maintenance volume, not your IPL volume. Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.au mailto:pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
I get a screen that will allow me to override the in-use message. Perhaps you don't have the authority you need. Dan Blake -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello Dan, This solution wont work because we are running system from primary RES volume and applying Maintenence on Alt RES volume and DDDEF also pointing to Alt RES volume dataset. Now, When I tried renaming Alt volume dataset with .old extension, I am getting below error. ÄÄ DSLIST - Data Sets on volume RESALT Data set in use Command - Enter / to select action Message Volume --- RSYS1.SASMMOD1 RESALT * End of Data Set list ÚÄÄ¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try later or enter HELP for ³ ³ a list of jobs and users allocated to 'SYS1.SASMMOD1'. ³ Regards Venkat On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: Been there, done that. Yes the system has a reserve on the dataset names. However if you have the proper authority you can: 1. Rename the files using IDCAMS or ISPF 3.4. Make sure you rename, not delete them. 2. Then allocate new, larger ones using *.NEW or something that fits your naming conventions as the LLQ. 3. Uncatalog the *.NEW data sets. 4. Rename the uncataloged data sets dropping the .NEW LLQ. 5. Rerun your SMP/E jobs. 6. Some point in time delete the old data sets from step 1. Note: I am assuming that SMP/E is pointing to your maintenance volume, not your IPL volume. Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.au mailto:pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Library out of space issue while APPLY RSU
I am working as UID 0 with all required authority. I don't see any issue with it. Still can you please suggest the authority required,So that I can cross verify. Regards Venkat On Wed, Jul 22, 2015 at 7:59 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: I get a screen that will allow me to override the in-use message. Perhaps you don't have the authority you need. Dan Blake -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello Dan, This solution wont work because we are running system from primary RES volume and applying Maintenence on Alt RES volume and DDDEF also pointing to Alt RES volume dataset. Now, When I tried renaming Alt volume dataset with .old extension, I am getting below error. ÄÄ DSLIST - Data Sets on volume RESALT Data set in use Command - Enter / to select action Message Volume --- RSYS1.SASMMOD1 RESALT * End of Data Set list ÚÄÄ¿ ³ Data set 'SYS1.SASMMOD1' in use by another user, try later or enter HELP for ³ ³ a list of jobs and users allocated to 'SYS1.SASMMOD1'. ³ Regards Venkat On Wed, Jul 22, 2015 at 7:31 PM, Blake, Daniel J [CTR] dbl...@fdic.gov wrote: Been there, done that. Yes the system has a reserve on the dataset names. However if you have the proper authority you can: 1. Rename the files using IDCAMS or ISPF 3.4. Make sure you rename, not delete them. 2. Then allocate new, larger ones using *.NEW or something that fits your naming conventions as the LLQ. 3. Uncatalog the *.NEW data sets. 4. Rename the uncataloged data sets dropping the .NEW LLQ. 5. Rerun your SMP/E jobs. 6. Some point in time delete the old data sets from step 1. Note: I am assuming that SMP/E is pointing to your maintenance volume, not your IPL volume. Dan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, July 22, 2015 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Library out of space issue while APPLY RSU Hello, Thanks for reply. Yes, I am applying Maintenance not on production system. Can you please suggest on the issue I discussed before. Regards Venkat. On Wed, Jul 22, 2015 at 4:29 PM, Paul Gillis pgil...@pc-link.com.au mailto:pgil...@pc-link.com.au wrote: Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edumailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email
