Absolutely not. Now comes the soap box.... I believe that IBM calls the catalog volume the SYSTEM or sometimes CATALOG volume, and it needs to only contain the stuff that is needed for IPL time support. Master Catalog, IODF datasets , SYS1.IPLPARM, SYS1.PARMLIB (which I don't use), etc. All the other stuff that z/OSMF wants to put there belong elsewhere (SMF datasets, Spool, DUMP etc.) All of that stuff is completely unnecessary on that volume if you install things right. On my system(s) that volume is a 3390-9 and even that is under 10% used (you could even make it a 3390-3) .
I always have a separate LPAR specific volume as well (1 per LPAR) that has all of the datasets needed for that particular LPAR (the real and main LPAR.PARMLIB, LPAR.PROCLIB LPAR.VTAMLST, LPAR.TCPPARMS, etc.). The idea is that everything that is specific to that particular LPAR is kept on that volume. This volume is normally a under 50% used 3390-3, or a mod-9 if you don't have any mod-3's. This also makes maintenance a LOT easier to do because the ONLY volumes that are affected by most (if not all) IBM maintenance is on the RES, DLB and USS volume, everything else is either LPAR specific (in which case by definition is unlikely to be affected) or the SYSTEM volume which is also very unlikely to be affected. z/OSMF actually ends up building a system configuration (dasd-wise) that makes it much more difficult to perform maintenance. My way can be completely automated (works out nice since we market an automation product), and basically I start the automation task and everything gets performed pretty quickly. I still end up being involved with the SMP/e apply and sometimes the accept, but because of the way it's set up, a trained monkey (or even an operations person or manager) could maintain it. (excluding the Apply which really does need someone that knows what they are doing to check on every time. IBM has a bad habit of not telling you ahead of time when they want to add new datasets and DDDEFs that you end up having to do manually). So to recap, you need 3 mod-27's for the RES, DLIB and USS datasets, and 2 mod-3's for the SYSTEM and LPAR volumes. Everything else needs to be scattered around to it's own volumes (i.e. SPOOL, DUMP, SMF, RMF, RACF, USERCATs and Tape related catalogs, HSM stuff (because I don't like to have multiple on a volume) etc.). I am a firm believer in keeping things separate when possible so that they can be maintained with as little muss and fuss possible. I also take a lot of backups and even more flashcopies which, naturally, are automated. If a site has a second array then PPRC eliminates even more of the work, but I think that EVERYTHING needs at least 3 (unrelated) ways to recover it and none of them count redundant HSM based copies, I count those as just extra gravy. :) When I generate an array, I like to create some 3390-1 and 3390-3 volumes for use by the various component parts (and as flashcopy targets for them) which makes first stage recovery a snap. The same with 3390-9's which I tend to have more of then the 3390 mod-1&3's. Depending on the site, the bulk of rest of the dasd might be mod 27's or 54's or EAVs. I try to stay away any unallocated space and thin provisioned space, I think it's just asking for trouble later on because the people who use and run the system sometimes don't know how to handle it properly, but that's just my preference and sometimes I don't get to make the decision. Using this method, I don't think there has been a recovery issue that took more than a few minutes to completely recover from in the past 20 years at literally hundreds of sites. If you practice recovery properly and document it, than most times, you don't have to be there to fix it. I also am a firm believer not just in ways to recover, but actually testing that recovery and drilling the people on-site how to perform it. Waiting for a Disaster or even a Disaster test is just not acceptable. The important thing is to teach them how to decide what to do, and not to "guess". "Guessing" will kill you every time. So much for my soap box presentation. If you disagree, that's fine. I won't argue any points with you. Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
