The directions are in the DFSMS managing catalogs manual. It's a simple multi-step job to do each catalog. Basically a listcat and a temporary export.
Actually, everyone should know how to do it because if you ever lose a catalog, the only thing you have (assuming you take backups), is that procedure to recreate the catalog to a point that you can recover the rest from SMF. One of the first things I set up at places is sufficient backups to recover the basic system, and that includes the export of the catalogs to both disk and tape. Depending on the site, you can do that multiple times per day, but most sites just once a day is sufficient. Otherwise, how would you possibly recover a lost catalog? Hopefully at the very least you have a volume backup to at least get something to start with. I can't imagine the gyrations you would need to go through without viable backups. Anyway, my way is not necessarily the ONLY way, but my way works and I have had to recover catalogs multiple times for various reasons. Everything from DASD failure, Array failure, to downright stupidity on the part of people who somehow were given the authority to screw up the system. If you don't have a plan (one that you have tested) you are just asking to be bitten. It comes down to that old saying, if you fail to plan, you should plan to fail. Having a good (tested) plan alters the catastrophic catalog failure with a long outage, to something that is little more than a small hiccup. Brian On Fri, 21 Nov 2025 08:05:55 -0600, Mike Schwab <[email protected]> wrote: >This is a USER cat procedure >https://www.ibm.com/docs/en/zos/2.5.0?topic=catalog-reorganizing-changing-size-bcs >. > >I am sure you need more steps like attaching as user catalog on another >system, and ALIAS definitions. > >On Fri, Nov 21, 2025 at 7:50 AM Colin Paice < >[email protected]> wrote: > >> How do you rebuild a catalog - copy it to a different catalog, or extract >> everything , create "define alias.." statement and process those >> statements through IDCAMS? >> >> Colin >> >> On Fri, 21 Nov 2025 at 05:55, Brian Westerman < >> [email protected]> wrote: >> >> > It keeps the Master Catalog clean, and makes sure that any catalog >> > maintenance changes that may have occurred between the versions (not the >> > minor releases) will be used to generate the new Master Catalog. It also >> > forces a re-think on what is and needs to be "in" the Master Catalog. >> > >> > I'm not the only one that can put things into the Master at any of the >> > sites I work with, there are people at the actual site who can update the >> > Master who normally don't really think about whether something needs to >> be >> > there or not. Lots of things change between the time z/OS version 1 came >> > out and then version 2 now version 3. There have been many changes >> between >> > those releases that have benefited the Master Catalog (and catalog in >> > general). Keeping the same Master for 10 to 20 to 30 years, to me seems >> > like asking for trouble. And yet, there are sites that brag about having >> > the same Master Catalog and Usercats from when they started xx years ago. >> > I think they are probably thinking something along the lines of, "they >> > still work, why change anything?". >> > >> > There is a lot of obsolete stuff in there at almost every site I have >> been >> > exposed to. The entire rebuild process takes maybe 15 minutes and I end >> up >> > with a pristine Catalog structure. I generally rebuild the User Catalogs >> > as well, but mostly so I can move them where they "should" be for >> recovery >> > purposes. >> > >> > The question you asked maybe should have been to ask yourself, "what are >> > you losing by not rebuilding the Master Catalog"? I realize that people >> > have probably some very strong feelings on this one way or the other, and >> > that's their privilege. I believe that occasionally rebuilding the >> Master >> > (and the user catalogs) can be beneficial, and when it's been a "log >> time", >> > I know it is. Personally I think that some sites don't do it because >> they >> > aren't really that confident in their skills, but the perfect time to >> > rebuild (and reallocate), is when you generated the new system. There >> > isn't much that can go wrong anyway, but at installation time you have >> the >> > time to think about EVERYTHING in a lot more detail, at least you should. >> > >> > I probably do more installs of the whole system and all of it's >> subsystems >> > than a "normal" (normal is probably not the correct word here) systems >> > programmer, and I have a extremely long "to do" list of the process >> (almost >> > 3,000 steps depending on the subsystems and vendor products involved). I >> > have seen countless Master Catalog issues that people just "live" with >> > because they don't see a benefit in fixing it. In my case, I don't even >> > bother to take the chance that I will prolong a problem. >> > >> > In this case, the choice is up to the person who is doing the install. >> If >> > that's me, then of course "my way" will be the right way no matter what >> > anyone else thinks. I have yet to have even one site complain about me >> > recreating the Catalog(s), and that's a lot of sites. >> > >> > Brian >> > >> > ---------------------------------------------------------------------- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to [email protected] with the message: INFO IBM-MAIN >> > >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > >-- >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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
