Re: Catalog resizing approach
Thanks all for your opinions and great suggestions. The environment is like Intended usercat is connected to all the Mastercatalog. So after the CATALOG rebuild, a F CATALOG,RESTART would be a good choice to refresh the entries ? On Wed, Aug 14, 2013 at 3:33 AM, Tom Marchant m42tom-ibmm...@yahoo.comwrote: On Tue, 13 Aug 2013 15:05:27 -0400, Robert A. Rosenberg wrote: I do not have a way of listing the APAR so I do not know what it says to do. Really? GIYF http://www.google.com/#bav=on.2,or.r_qf.cad=bfp=1q=II13354 If I wanted to ALIAS entries to point at a new name, just delete and then define them. I think you;d find that all of the VSAM data sets in that catalog were broken after you did that. The catalog information for a data set is not stored entirely in the BCS. Some of it is in the VVDS. And the VVDS entry (at least for VSAM) contains the name of the catalog that the data set is cataloged in. OTOH, as has been pointed out, just deleting and redefining (using the same name) the usercat (my backup/restore method) would also work. It would almost work, but not quite. As I stated, there does however the method, need to be some way to freeze the contents of the usercat while you either redefine or replace it. Yes, it is important to prevent all accesses to the catalog by other users during the process. The APAR describes how to use LOCK for that. You are not doing anyone a service by providing an overly simplified procedure that omits the critical information of how to do it as an alternative to the procedure to do it correctly. Just my opinion. -- Tom Marchant -- 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: Catalog resizing approach
I wouldn't think that would be required or all that useful. What method did you choose to use for the reorg? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 14, 2013 1:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Catalog resizing approach Thanks all for your opinions and great suggestions. The environment is like Intended usercat is connected to all the Mastercatalog. So after the CATALOG rebuild, a F CATALOG,RESTART would be a good choice to refresh the entries ? On Wed, Aug 14, 2013 at 3:33 AM, Tom Marchant m42tom- ibmm...@yahoo.comwrote: On Tue, 13 Aug 2013 15:05:27 -0400, Robert A. Rosenberg wrote: I do not have a way of listing the APAR so I do not know what it says to do. Really? GIYF http://www.google.com/#bav=on.2,or.r_qf.cad=bfp=1q=II13354 If I wanted to ALIAS entries to point at a new name, just delete and then define them. I think you;d find that all of the VSAM data sets in that catalog were broken after you did that. The catalog information for a data set is not stored entirely in the BCS. Some of it is in the VVDS. And the VVDS entry (at least for VSAM) contains the name of the catalog that the data set is cataloged in. OTOH, as has been pointed out, just deleting and redefining (using the same name) the usercat (my backup/restore method) would also work. It would almost work, but not quite. As I stated, there does however the method, need to be some way to freeze the contents of the usercat while you either redefine or replace it. Yes, it is important to prevent all accesses to the catalog by other users during the process. The APAR describes how to use LOCK for that. You are not doing anyone a service by providing an overly simplified procedure that omits the critical information of how to do it as an alternative to the procedure to do it correctly. Just my opinion. -- Tom Marchant - - 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: Catalog resizing approach
Dump and restore. On Wed, Aug 14, 2013 at 1:51 PM, Gibney, Dave gib...@wsu.edu wrote: I wouldn't think that would be required or all that useful. What method did you choose to use for the reorg? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 14, 2013 1:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Catalog resizing approach Thanks all for your opinions and great suggestions. The environment is like Intended usercat is connected to all the Mastercatalog. So after the CATALOG rebuild, a F CATALOG,RESTART would be a good choice to refresh the entries ? On Wed, Aug 14, 2013 at 3:33 AM, Tom Marchant m42tom- ibmm...@yahoo.comwrote: On Tue, 13 Aug 2013 15:05:27 -0400, Robert A. Rosenberg wrote: I do not have a way of listing the APAR so I do not know what it says to do. Really? GIYF http://www.google.com/#bav=on.2,or.r_qf.cad=bfp=1q=II13354 If I wanted to ALIAS entries to point at a new name, just delete and then define them. I think you;d find that all of the VSAM data sets in that catalog were broken after you did that. The catalog information for a data set is not stored entirely in the BCS. Some of it is in the VVDS. And the VVDS entry (at least for VSAM) contains the name of the catalog that the data set is cataloged in. OTOH, as has been pointed out, just deleting and redefining (using the same name) the usercat (my backup/restore method) would also work. It would almost work, but not quite. As I stated, there does however the method, need to be some way to freeze the contents of the usercat while you either redefine or replace it. Yes, it is important to prevent all accesses to the catalog by other users during the process. The APAR describes how to use LOCK for that. You are not doing anyone a service by providing an overly simplified procedure that omits the critical information of how to do it as an alternative to the procedure to do it correctly. Just my opinion. -- Tom Marchant - - 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: Catalog resizing approach
Check out II13354 moving ICF CATALOGS. Much faster than repro mergecat... HTH, snip One of user catalog has run out of extent for an application. The application owner has accepted for a outage. My approach of resizing the catalog is like 1) Creating a new User catalog like : ICF.PETER.USERCATZ with more allocation like 1500 cylinders. 2 ) Delete the alias from the older catalog : ICF.PETER.USERCATO 3 ) Then perform the repro mergcat with level alias 4 ) Then redefine the alias to new usercat ICF.PETER.USERCATZ. Here while doing REPRO mergcat, Is it possible to perform with two alias together. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog resizing approach
At 13:24 + on 08/13/2013, Staller, Allan wrote about Re: Catalog resizing approach: Check out II13354 moving ICF CATALOGS. Much faster than repro mergecat... HTH, snip One of user catalog has run out of extent for an application. The application owner has accepted for a outage. My approach of resizing the catalog is like 1) Creating a new User catalog like : ICF.PETER.USERCATZ with more allocation like 1500 cylinders. 2 ) Delete the alias from the older catalog : ICF.PETER.USERCATO 3 ) Then perform the repro mergcat with level alias 4 ) Then redefine the alias to new usercat ICF.PETER.USERCATZ. Here while doing REPRO mergcat, Is it possible to perform with two alias together. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN In lieu of the mergecat, why not just do a dump of the old cat and restore to the new one? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog resizing approach
The repro/mergecat functions are very slow because all VTOCS/VVDS will need to be updated with the new catalog name. What you want is to reorg the catalog. In short, backup the catalog, delete the old structure, re-define it; then, restore from backup into its new structure. If you have a utility, like TREX, this process is very simple. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Tuesday, August 13, 2013 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Catalog resizing approach Hello All, One of user catalog has run out of extent for an application. The application owner has accepted for a outage. My approach of resizing the catalog is like 1) Creating a new User catalog like : ICF.PETER.USERCATZ with more allocation like 1500 cylinders. 2 ) Delete the alias from the older catalog : ICF.PETER.USERCATO 3 ) Then perform the repro mergcat with level alias 4 ) Then redefine the alias to new usercat ICF.PETER.USERCATZ. Here while doing REPRO mergcat, Is it possible to perform with two alias together. Could someone please shed light on the above approach. Peter -- 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: Catalog resizing approach
I will do with catalog rebuild. There used to be rexx code to display the allocation parameter of a catalog but I am unable to get it.Is there anyone who still has those REXX code ? On Tue, Aug 13, 2013 at 10:31 PM, Hervey Martinez hervey.marti...@custserv.com wrote: The repro/mergecat functions are very slow because all VTOCS/VVDS will need to be updated with the new catalog name. What you want is to reorg the catalog. In short, backup the catalog, delete the old structure, re-define it; then, restore from backup into its new structure. If you have a utility, like TREX, this process is very simple. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Tuesday, August 13, 2013 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Catalog resizing approach Hello All, One of user catalog has run out of extent for an application. The application owner has accepted for a outage. My approach of resizing the catalog is like 1) Creating a new User catalog like : ICF.PETER.USERCATZ with more allocation like 1500 cylinders. 2 ) Delete the alias from the older catalog : ICF.PETER.USERCATO 3 ) Then perform the repro mergcat with level alias 4 ) Then redefine the alias to new usercat ICF.PETER.USERCATZ. Here while doing REPRO mergcat, Is it possible to perform with two alias together. Could someone please shed light on the above approach. Peter -- 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: Catalog resizing approach
At 10:15 -0500 on 08/13/2013, Elardus Engelbrecht wrote about Re: Catalog resizing approach: x-charset utf-8Robert A. Rosenberg wrote: In lieu of the mergecat, why not just do a dump of the old cat and restore to the new one? The OP wants to use a new catalog with another name. Somehow you need to preserve the alias somehow as described in that info APAR. I do not have a way of listing the APAR so I do not know what it says to do. If I wanted to ALIAS entries to point at a new name, just delete and then define them. OTOH, as has been pointed out, just deleting and redefining (using the same name) the usercat (my backup/restore method) would also work. As I stated, there does however the method, need to be some way to freeze the contents of the usercat while you either redefine or replace it. Warning/disclaimer: I'm not doing catalog managent these days, perhaps I'm a catalogued risk... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN /x-charset -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog resizing approach
On Tue, 13 Aug 2013 15:05:27 -0400, Robert A. Rosenberg wrote: I do not have a way of listing the APAR so I do not know what it says to do. Really? GIYF http://www.google.com/#bav=on.2,or.r_qf.cad=bfp=1q=II13354 If I wanted to ALIAS entries to point at a new name, just delete and then define them. I think you;d find that all of the VSAM data sets in that catalog were broken after you did that. The catalog information for a data set is not stored entirely in the BCS. Some of it is in the VVDS. And the VVDS entry (at least for VSAM) contains the name of the catalog that the data set is cataloged in. OTOH, as has been pointed out, just deleting and redefining (using the same name) the usercat (my backup/restore method) would also work. It would almost work, but not quite. As I stated, there does however the method, need to be some way to freeze the contents of the usercat while you either redefine or replace it. Yes, it is important to prevent all accesses to the catalog by other users during the process. The APAR describes how to use LOCK for that. You are not doing anyone a service by providing an overly simplified procedure that omits the critical information of how to do it as an alternative to the procedure to do it correctly. Just my opinion. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
