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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
