Re: Catalog resizing approach
Dump and restore. On Wed, Aug 14, 2013 at 1:51 PM, Gibney, Dave 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 > ibmm...@yahoo.com>wrote: > > > > > 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=b&fp=1&q=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
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 ibmm...@yahoo.com>wrote: > > > 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=b&fp=1&q=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
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 wrote: > 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=b&fp=1&q=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
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=b&fp=1&q=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
Re: Catalog resizing approach
At 10:15 -0500 on 08/13/2013, Elardus Engelbrecht wrote about Re: Catalog resizing approach: Robert 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 -- 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
W dniu 2013-08-13 15:19, mf db pisze: 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. Just curious: is your catalog as large as 1500 cylinders? IMHO it's time to split it into several smaller catalogs. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- 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
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
Robert 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. Warning/disclaimer: I'm not doing catalog managent these days, perhaps I'm a catalogued risk... :-D 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
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, 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. -- 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
Check out II13354 "moving ICF CATALOGS." Much faster than repro mergecat... HTH, 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
