Re: Catalog Question
Try here: http://www-01.ibm.com/support/docview.wss?uid=isg1II13354 snip I just started receiving the following message on a catalog IEC361I CATALOG CATLOG.MVS.VGEM913 (DATA) HAS REACHED 82% OF THE MAXIMUM EXTENTS The messages are coming out about twice a month. I am running z/OS 1.9 Can anyone tell me, what is the proper way to go about expanding the catalog. I started looking on the internet but unable to find out exactly how to go about it. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Catalog Question
Since that APAR is from 2002, the OP should also check the SMS Managing Catalogs document for his 1.9 system just in case anything has changed. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :: Behalf Of Staller, Allan :: Sent: Monday, April 30, 2012 6:05 AM :: To: IBM-MAIN@bama.ua.edu :: Subject: Re: Catalog Question :: :: Try here: :: :: http://www-01.ibm.com/support/docview.wss?uid=isg1II13354 :: :: :: snip :: I just started receiving the following message on a catalog :: IEC361I CATALOG CATLOG.MVS.VGEM913 (DATA) HAS REACHED 82% OF THE MAXIMUM :: EXTENTS :: :: The messages are coming out about twice a month. :: :: I am running z/OS 1.9 :: :: Can anyone tell me, what is the proper way to go about expanding the :: catalog. :: I started looking on the internet but unable to find out exactly how to :: go about it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Catalog Question
I had to do exactly the same thing last night to two of my catalogs, for the exact same reason. Here is a copy of the jcl I used. You will have to come up w/ your correct space values. In my case, each catalog had 200,000+ entries. //TUCO JOB (10679),'S6 CAT BIGGER ', // LINES=(99,WARNING), // CLASS=H,MSGCLASS=X,NOTIFY=TUCO,USER=TUCO,MSGLEVEL=(1,1) /*ROUTE PRINT RMT0 //*= DSSSYS.TUCO.JCL( W$SYS006 //* //* //* //* //EXPORT EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //OUT DD DSN=TUCO.BACKUP.UCAT.VSYS006, // DISP=(NEW,CATLG,DELETE),UNIT=3390,VOL=SER=BCBUT1, // SPACE=(CYL,(50,50),RLSE) //SYSIN DD * ALTER UCAT.VSYS006 LOCK EXPORT UCAT.VSYS006 TEMPORARY OUTFILE(OUT) //* //* //* //* //DELET EXEC PGM=IDCAMS,COND=(0,NE) //SYSPRINT DD SYSOUT=* //DD1 DD VOL=SER=SYS006,UNIT=3390,DISP=SHR //SYSIN DD * DELETE 'UCAT.VSYS006' UCAT FILE(DD1) RECOVERY //* //* //* //* //DEFINE EXEC PGM=IDCAMS,REGION=1024K,COND=(0,NE) //SYSPRINT DD SYSOUT=* //UCATVOL DD UNIT=3390,VOL=SER=SYS006,DISP=SHR //SYSINDD * DEFINE USERCATALOG (NAME(UCAT.VSYS006) CYL(210 10) - VOL(SYS006) ICFCAT - RECSZ(100 32400) SHR(3 4) - STRNO(3) - BUFND(4) BUFNI(4)) - DATA (CYLINDER(200 20) CISZ(4096)) - INDEX (CYLINDER(10 10) CISZ(10240)) - CATALOG(CATALOG.BCB.MAST.VBCBCAT) //* //* //* //IMPORT EXEC PGM=IDCAMS,COND=(0,NE) //INDD DSN=TUCO.BACKUP.UCAT.VSYS006,DISP=(OLD,KEEP,KEEP) //SYSPRINT DD SYSOUT=* //OTDD1 DD DSN=UCAT.VSYS006, // DISP=OLD,VOL=SER=SYS006,AMP=AMORG,UNIT=3390 //SYSIN DD * IMPORT INFILE(IN)OUTFILE(OTDD1) ALIAS INTOEMPTY LOCK - CAT(UCAT.VSYS006) //* //* //* //DIAG EXEC PGM=IDCAMS,REGION=512K,COND=(0,NE) //SYSPRINT DD SYSOUT=* //CATALOG DD DSN=UCAT.VSYS006,DISP=SHR //SYS006 DD DSN=SYS1.VVDS.VSYS006,DISP=SHR,UNIT=3390, // VOL=SER=SYS006, //AMP='AMORG' //SYSIN DD * DIAGNOSE ICFCATALOG INFILE(CATALOG) - COMPAREDD(SYS006)LIST //* //* //* //* //UNLOCK EXEC PGM=IDCAMS,COND=(0,NE) //SYSPRINT DD SYSOUT=* //SYSIN DD * ALTER UCAT.VSYS006 UNLOCK //* //* //* //* //EXAMIEXEC PGM=IDCAMS,COND=(0,NE) //SYSPRINT DD SYSOUT=* //PRINTDD SYSOUT=* //SYSINDD * ALTER UCAT.VSYS006 LOCK VERIFY DATASET(UCAT.VSYS006) EXAMINE NAME(UCAT.VSYS006)DATATEST ALTER UCAT.VSYS006 UNLOCK // // // /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sabo, Frank Sent: Monday, 30 April, 2012 08:56 AM To: IBM-MAIN@bama.ua.edu Subject: Catalog Question Hello everyone, I just started receiving the following message on a catalog IEC361I CATALOG CATLOG.MVS.VGEM913 (DATA) HAS REACHED 82% OF THE MAXIMUM EXTENTS The messages are coming out about twice a month. I am running z/OS 1.9 Can anyone tell me, what is the proper way to go about expanding the catalog. I started looking on the internet but unable to find out exactly how to go about it. Thanks for any help that I can get. Frank W Sabo Jr 101 Kappa Drive Pittsburgh Pa 15238 412 967-3764 frank.s...@gianteagle.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Catalog Question
Depending on-may be easier to do REPRO MERGECAT. In a message dated 4/30/2012 3:46:27 P.M. Central Daylight Time, t...@cio.sc.gov writes: I had to do exactly the same thing last night to two of my catalogs, for the exact same reason. Here is a copy of the jcl I used. You will have to come up w/ your correct space values. In my case, each catalog had 200,000+ entries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Catalog question
W dniu 2010-02-19 17:34, Darth Keller pisze: [...] Yes, I need all my applications to be available too and by separating them into more than one catalog I decrease the likelyhood that 1 broken catalog impacts all applications. My point is that if I have my applications separated into different catalogs and 1 catalog is broken only that application suffers as opposed to the original configuration where all the applications are in 1 catalog. In my configuration, only the applications in that catalog are unavailable during the recovery, all the other applications are still available and un-affected. Well, you *think* you decrease likelyhood by increasing number of ucats or separating UCAT applications. To decrease the likelyhood you should take care about the UCAT, how hey are used, no matter how much of them do you have. Note: I mean *applications*. You mentioned TSO - I also keep those aliases separate (for several reasons). I also dedicate UCATs which are shared across sysplexes. However I see no *RAS* reason to keep the applications in separate UCATs. There can be other reasons, i.e. grouping datasets with UCATs to make physical copies easier - I mean clones like PPRC, SRDF, FLASHCOPY, TIMEFINDER, etc. If you need to clone only one of the applications then it's easier to have separate UCAT for it. If you worry about UCAT integrity/availability - then you should check your application. Application (I mean business application) should use catalogs in other way than regular dataset operations like allocation, deletion, open, close, etc. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
-- You also want to consider recoverability issues - if all your production -- aliases are in one catalog and there's a catalog error (and they do still -- happen), this could result in ALL of your production applications being -- down. One might argue increasing the # of catalogs increases the risk of -- catalog errors, but it also limits your exposure and can shorten the -- amount of time being spent in recovery. I deeply disagree! I need ALL of my applications to be available, so I need all my dataset ergo all my UCATs. So I should take care to have all the UCATs available and error-free, regardless of the number of UCATs. Is it easier to look after one or many UCATs, is it easier to recover few smaller or one bigger UCAT - that's slightly different story. IMHO there is no big difference. Yes, I need all my applications to be available too and by separating them into more than one catalog I decrease the likelyhood that 1 broken catalog impacts all applications. My point is that if I have my applications separated into different catalogs and 1 catalog is broken only that application suffers as opposed to the original configuration where all the applications are in 1 catalog. In my configuration, only the applications in that catalog are unavailable during the recovery, all the other applications are still available and un-affected. Of course, this is changing too as more and more of our applications become inter-related and feed each other. But where it makes sense to separate things, I will continue to do so - test from production, TSO from everything else, the tape backup catalog I described yesterday, etc. ddk This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
R.S. r.skoru...@bremultibank.com.pl wrote in message news:4b7c5d62.2040...@bremultibank.com.pl... W dniu 2010-02-17 21:26, gsg pisze: Can having all production application aliases defined in a single UCAT cause performance problems? If so, does anyone have any stories to tell regarding this. It depends - did you expect any other answer for such general question? 1. It depends on number of datasets cataloged. Since UCAT is second and last level of catalog structure (there are no sub-UCATs), all datasets are cataloged in this single BCS (Base Catalog Structure). Huge number of datasets may cause the UCAT busy, as well as big in size, which can cause another issues. 2. It depends on datasets activity. In fact catalog is usually used at file open and close. If your application simply opens few huge datasets, then processes data and finally closes them - there is no performance issue. If you have a lot of datasets being created, updated, deleted - that can be a problem. 3. It rather does not depend on number of aliases. BTW: The number is limited (by the filed in MCAT), but the limit is quite big (several hundreds AFAIR). Several thousands in fact. The sum of the lengths of all aliases cannot exceed 32300. Kees. HTH -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
Good practice would be to verify that the IO, and that the time spent doing it, to the catalog is actually low, rather than thinking that it is low because someone a few thousand km away told you it is :-) I did say do some analysis first, before you start doing the work. The last time I did a similar one, catalogue I/O was the least of our problems. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
3. It rather does not depend on number of aliases. BTW: The number is limited (by the filed in MCAT), but the limit is quite big (several hundreds AFAIR). -- Several thousands in fact. -- The sum of the lengths of all aliases cannot exceed 32300. Haven't seen where anyone's mentioned that catalogs are standard KSDS's are there for limited to 4GB's. Is that not still true? You also want to consider recoverability issues - if all your production aliases are in one catalog and there's a catalog error (and they do still happen), this could result in ALL of your production applications being down. One might argue increasing the # of catalogs increases the risk of catalog errors, but it also limits your exposure and can shorten the amount of time being spent in recovery. I once worked in a major shop where every production ds started P.** - I honestly believe that shop was one of the reasons multi-level aliases were designed. dd keller This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
On Thu, 18 Feb 2010 09:20:00 -0600, Darth Keller darth.kel...@assurant.com wrote: 3. It rather does not depend on number of aliases. BTW: The number is limited (by the filed in MCAT), but the limit is quite big (several hundreds AFAIR). -- Several thousands in fact. -- The sum of the lengths of all aliases cannot exceed 32300. Haven't seen where anyone's mentioned that catalogs are standard KSDS's are there for limited to 4GB's. Is that not still true? A SHARE requirement was submitted to relieve the 4GB limit for catalogs. (Yes ... the process does work!) This appears to be addressed in z/OS 1.12. Check the announcement preview. You also want to consider recoverability issues - if all your production aliases are in one catalog and there's a catalog error (and they do still happen), this could result in ALL of your production applications being down. One might argue increasing the # of catalogs increases the risk of catalog errors, but it also limits your exposure and can shorten the amount of time being spent in recovery. Recovery is the major reason NOT to place all of your entries in a single catalog. When that one catalog breaks (it's not if, but when), think about how you will manage to perform recovery. Can you do this without relying on some cataloged dataset somewhere? (There are ways; but, you need to plan for this event.) Another consideration may be what happens when that catalog fills, for whatever reason. (Lots of dead CAs, say.) You may not be able to catalog anything new, until you re-organize the catalog. Can you afford that outage to your entire shop? I once worked in a major shop where every production ds started P.** - I honestly believe that shop was one of the reasons multi-level aliases were designed. dd keller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
John - Thanks for the update on the 4GB limit for catalogs. I had not seen this yet it's definitely good to hear that it's finally going to be resolved. As for your other points, it appears to me that we are in complete agreement. -- Haven't seen where anyone's mentioned that catalogs are standard KSDS's -- are there for limited to 4GB's. Is that not still true? A SHARE requirement was submitted to relieve the 4GB limit for catalogs. (Yes ... the process does work!) This appears to be addressed in z/OS 1.12. Check the announcement preview. -- You also want to consider recoverability issues - if all your production -- aliases are in one catalog and there's a catalog error (and they do still -- happen), this could result in ALL of your production applications being -- down. One might argue increasing the # of catalogs increases the risk of -- catalog errors, but it also limits your exposure and can shorten the -- amount of time being spent in recovery. Recovery is the major reason NOT to place all of your entries in a single catalog. When that one catalog breaks (it's not if, but when), think about how you will manage to perform recovery. Can you do this without relying on some cataloged dataset somewhere? (There are ways; but, you need to plan for this event.) Another consideration may be what happens when that catalog fills, for whatever reason. (Lots of dead CAs, say.) You may not be able to catalog anything new, until you re-organize the catalog. Can you afford that outage to your entire shop? The above was also a very good point to mention. As it happens, I had this happen just recently. We use OpenTec's TapeCopy/VDR product to create copies of virtual tapes to be vaulted offsite. The naming standard we implemented on the copies puts them all into the same catalog and results in a 'creep' in the resulting dataset names - meaning the space at the beginning of this catalog generally does not get re-used. After 4 or 5 years, it finally filled up on me. Because this catalog contains only the alias for these tapes, I could easily rebuild it during the day outside the batch window when our DR copies are made without affecting any applications. Needless to say, I've also added a yearly tickler to take a look at this catalog to see what shape it's in. ddk This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
W dniu 2010-02-18 16:20, Darth Keller pisze: 3. It rather does not depend on number of aliases. BTW: The number is limited (by the filed in MCAT), but the limit is quite big (several hundreds AFAIR). -- Several thousands in fact. -- The sum of the lengths of all aliases cannot exceed 32300. Haven't seen where anyone's mentioned that catalogs are standard KSDS's are there for limited to 4GB's. Is that not still true? It is true - the limit of 4GB. Is it standard KSDS? Well, I wouldn't say so, but this is discussion about opinions - what daviation can be accepted to stay in standard vbg You also want to consider recoverability issues - if all your production aliases are in one catalog and there's a catalog error (and they do still happen), this could result in ALL of your production applications being down. One might argue increasing the # of catalogs increases the risk of catalog errors, but it also limits your exposure and can shorten the amount of time being spent in recovery. I deeply disagree! I need ALL of my applications to be available, so I need all my dataset ergo all my UCATs. So I should take care to have all the UCATs available and error-free, regardless of the number of UCATs. Is it easier to look after one or many UCATs, is it easier to recover few smaller or one bigger UCAT - that's slightly different story. IMHO there is no big difference. I once worked in a major shop where every production ds started P.** - I honestly believe that shop was one of the reasons multi-level aliases were designed. Naming convetion. I always repeat it's very important, they always don't get it... g -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
Radoslaw, I agree with you totally on this. While I have been making the point that you should check that a single UCAT is not a bottleneck, I believe that spreading applications across many UCAT works against high availability. The more moving parts you have, the greater the number of things that can go wrong. It is far better to put all your eggs in one basket, and watch that basket very, very carefully. Storage hardware has become faster and far more reliable, and provides improved capabilities for backup and restore compared to the Frisbees we were using when ICF catalogs were born. I think that splitting catalogs should be driven by back-up and restore procedures first, and performance second. That's it. If you choose to run with a minimal number of UCAT, such as the case with the OP (one), then there are some things you can improve resilience and recovery: 1) Make sure the Catalog is on the fastest possible Storage. This means: a) Loaded into Cache Residency Manager preferred (better than SSD performance) b) or protected in a Cache Partition c) HyperPAV or PAV 2) Take Hourly snapshots of the UCAT a) At-Time split with Shadowimage preferred (known P-i-T) b) Hourly FlashCopy or Shadowimage of the volume c) Hourly FlashCopy of the dataset The rolling backup method will not forgo the need for tools or a methodology for rebuilding the catalog, but it can minimize the lost entries that must be recovered if there is a logical error. I use HDS POV here, but some of these features are available on other vendor kit. Ron I deeply disagree! I need ALL of my applications to be available, so I need all my dataset ergo all my UCATs. So I should take care to have all the UCATs available and error-free, regardless of the number of UCATs. Is it easier to look after one or many UCATs, is it easier to recover few smaller or one bigger UCAT - that's slightly different story. IMHO there is no big difference. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
2. It depends on datasets activity. In fact catalog is usually used at file open and close. I may well display my ignorace, anyway: It is my understanding that the catalog is only accessed at allocation time to find the volume that data set resides on. VSAM data sets being an exeption since statistics are stored in the catalog. Has this changed? -- Peter Hunkeler Credit Suisse -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
John Laubenheimer jlaubenhei...@doitt.nyc.gov wrote in message news:listserv%201002181110336825.0...@bama.ua.edu... On Thu, 18 Feb 2010 09:20:00 -0600, Darth Keller darth.kel...@assurant.com wrote: 3. It rather does not depend on number of aliases. BTW: The number is limited (by the filed in MCAT), but the limit is quite big (several hundreds AFAIR). -- Several thousands in fact. -- The sum of the lengths of all aliases cannot exceed 32300. Haven't seen where anyone's mentioned that catalogs are standard KSDS's are there for limited to 4GB's. Is that not still true? A SHARE requirement was submitted to relieve the 4GB limit for catalogs. (Yes ... the process does work!) This appears to be addressed in z/OS 1.12. Check the announcement preview. You also want to consider recoverability issues - if all your production aliases are in one catalog and there's a catalog error (and they do still happen), this could result in ALL of your production applications being down. One might argue increasing the # of catalogs increases the risk of catalog errors, but it also limits your exposure and can shorten the amount of time being spent in recovery. Recovery is the major reason NOT to place all of your entries in a single catalog. When that one catalog breaks (it's not if, but when), think about how you will manage to perform recovery. Can you do this without relying on some cataloged dataset somewhere? (There are ways; but, you need to plan for this event.) Another consideration may be what happens when that catalog fills, for whatever reason. (Lots of dead CAs, say.) You may not be able to catalog anything new, until you re-organize the catalog. Can you afford that outage to your entire shop? Dead CA reclamation is implemented in z/OS 1.12. That's one problem solved. Kees. I once worked in a major shop where every production ds started P.** - I honestly believe that shop was one of the reasons multi-level aliases were designed. dd keller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
Can having all production application aliases defined in a single UCAT cause performance problems? If so, does anyone have any stories to tell regarding this. 1. Define all. 2. It depends on the answer to 1. 3. With VLF, modern DASD, cache, FICON, most likely not. 4. Very general question -- hard to answer without specifics: a. How many applications? b. How active are they? c. Online? Batch? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
When I say all, I mean all. There are probably 50 plus applications, but not sure how many are running at the same time. We are CPU constraint as it is. I don't know how to go about measuring this to determine if it is a problem or not. Just trying to see if it is a possibility before raising the red flag. Thanks for your input though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
snip I don't know how to go about measuring this to determine if it is a problem /snip A good place to start is the 'f catalog,.' commands. they will tell you lots of good things about how busy your catalogues are and their performance. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
W dniu 2010-02-17 21:26, gsg pisze: Can having all production application aliases defined in a single UCAT cause performance problems? If so, does anyone have any stories to tell regarding this. It depends - did you expect any other answer for such general question? 1. It depends on number of datasets cataloged. Since UCAT is second and last level of catalog structure (there are no sub-UCATs), all datasets are cataloged in this single BCS (Base Catalog Structure). Huge number of datasets may cause the UCAT busy, as well as big in size, which can cause another issues. 2. It depends on datasets activity. In fact catalog is usually used at file open and close. If your application simply opens few huge datasets, then processes data and finally closes them - there is no performance issue. If you have a lot of datasets being created, updated, deleted - that can be a problem. 3. It rather does not depend on number of aliases. BTW: The number is limited (by the filed in MCAT), but the limit is quite big (several hundreds AFAIR). HTH -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
Would that be the F CATALOG,REPORT... commands? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
Gsg, Looking at Catalog and VLF statistics will tell you how well your catalog is caching, but it will not tell you about the performance of your catalog IO. Caching is IO avoidance, while the catalog uncached catalog activity is what may be encountering problems. I'd start by looking at your Type 42 subtype 6 SMF records and check the IO rates to your catalog, and how that IO is performing. It will also help you identify any utilities or users that are generating exceptional IO to the catalog. If you suspect a problem then have a look at how long your jobs are spending in allocation. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of gsg Sent: Wednesday, February 17, 2010 1:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Catalog question Would that be the F CATALOG,REPORT... commands? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
When I say all, I mean all. I was being facetious. What I meant was what I said in my fourth point - how many. I would recommend is that you do some sort of degradation analysis before you do (what might be) wasted work. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
If you have a sysplex, significant performance would be gained by implemention Enhanced Catalog Sharing. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of gsg Sent: Wednesday, February 17, 2010 2:05 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Catalog question When I say all, I mean all. There are probably 50 plus applications, but not sure how many are running at the same time. We are CPU constraint as it is. I don't know how to go about measuring this to determine if it is a problem or not. Just trying to see if it is a possibility before raising the red flag. Thanks for your input though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
If you have a sysplex, significant performance would be gained by implemention Enhanced Catalog Sharing. As long as ECS is working! I've had too many bad experiences. The I/O to the catalogue is so small, vs the files, that it's not worthwhile! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog question
Ted, I'm seeing examples of catalogs being in the top 1% of datasets for read-only disconnect time. While catalog IO may represent a small percentage of the IO for a file, the aggregate catalog IO may represent a single point of contention and delay for the end to end application. Also of note is that IO to catalogs that are getting very good hits in a host buffer instrumentations will usually have low cache hits in the arrays because locality of reference is satisfied in a higher tier. The activity that actually generates IO to these catalogs is usually very random. Good practice would be to verify that the IO, and that the time spent doing it, to the catalog is actually low, rather than thinking that it is low because someone a few thousand km away told you it is :-) Ron The I/O to the catalogue is so small, vs the files, that it's not worthwhile! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
I would simply change the ENTRIES line to say LEVEL, and then run this. Once you copy the entries, then you need to quickly define the alias. Here's a sample job I've run to move aliases that mistakenly made it into the master catalog: //MERGC1 EXEC PGM=IDCAMS,REGION=0M //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO INDATASET(CATALOG.MASTER.VCDCCP8) - OUTDATASET(CATALOG.USERCAT1) - LEVEL(CN00) - MERGECAT //*** //IDCAMS EXEC PGM=IDCAMS,REGION=4M //SYSPRINT DD SYSOUT=* //SYSIN DD * DEF ALIAS(NAME(CN00) REL(CATALOG.USERCAT1)) C. Todd Burrell Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Kington Sent: Wednesday, February 27, 2008 8:43 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM Ernie, Good Morning Gentle Readers, I am working on a problem regarding a TSO alias which was not created but for some unexplicable reason I find about 15 dsns have been cataloged in the MCAT. My question is how can I fix this problem - have the dsns created in the proper UCAT. I looked at the option of using REPRO MERGECAT in the IDCAMS doc. Is that the correct decision? My plan is to define the alias in the proper UCAT and then execute the following jcl. //STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(SYS1.SHR.MCAT) - OUTDATASET(MBC.CSTMCAT) - ENTRIES(CTPRX23) - MERGECAT /* Will this do the job? Am I missing something? I would appreciate any suggestions or comments. Thanks in advance. I would remove the alias, rename the 15 datasets to a different hlq, redefine the alias and then rename the 15 datasets back to the original name. Mergecat would be overkill for what you need to do. If you can not remove the alias, I would recatalog them if you know where they are and try a delete noscratch using the master catalog in the catalog() parameter. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
The best way to resolve this issue is to do the following: 1) Make sure the type of data set (VSAM vs. NON VSAM). If you have VSAM cataloged in the MCAT you will need to work a little harder. 2) Uncatalog all of the NON Vsam data sets in the Master Cat 3) Build the Alias for the HLQ 4) Recatalog all of the data sets. If you have vsam in the mcat, I would probably use a DFDSS DUMP with Delete for all of the files in the mcat, build the alias, then restore the files with catalog. I ususally have my MCAT with READ only access to prevent this type of issue. Lizette I am working on a problem regarding a TSO alias which was not created but for some unexplicable reason I find about 15 dsns have been cataloged in the MCAT. My question is how can I fix this problem - have the dsns created in the proper UCAT. I looked at the option of using REPRO MERGECAT in the IDCAMS doc. Is that the correct decision? My plan is to define the alias in the proper UCAT and then execute the following jcl. //STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(SYS1.SHR.MCAT) - OUTDATASET(MBC.CSTMCAT) - ENTRIES(CTPRX23) - MERGECAT /* Will this do the job? Am I missing something? I would appreciate any suggestions or comments. Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
Ernie, Good Morning Gentle Readers, I am working on a problem regarding a TSO alias which was not created but for some unexplicable reason I find about 15 dsns have been cataloged in the MCAT. My question is how can I fix this problem - have the dsns created in the proper UCAT. I looked at the option of using REPRO MERGECAT in the IDCAMS doc. Is that the correct decision? My plan is to define the alias in the proper UCAT and then execute the following jcl. //STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(SYS1.SHR.MCAT) - OUTDATASET(MBC.CSTMCAT) - ENTRIES(CTPRX23) - MERGECAT /* Will this do the job? Am I missing something? I would appreciate any suggestions or comments. Thanks in advance. I would remove the alias, rename the 15 datasets to a different hlq, redefine the alias and then rename the 15 datasets back to the original name. Mergecat would be overkill for what you need to do. If you can not remove the alias, I would recatalog them if you know where they are and try a delete noscratch using the master catalog in the catalog() parameter. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
You would need to define the alias after moving the entries out of the master catalog. You will probably get an IDC3009I 8-8 duplicate entry (on the alias define) if you already have data sets residing in the master catalog that begin with the alias. Blair Svihra Dino-Software Corp. * *T-REX/ - Superior ICF catalog mgmt with full Tape support and HSM Auditing/*** * *REORGadon/ - First ever online REORG for HSM/* * *TERADON/ - First ever online REPRO MERGECAT utility/* * *XTINCT/ - Secure DASD/TAPE data eradication/* * *RTD /- First ever real-time defrag/* * *DAL /- DINO healthcheck Analysis for Legato/* * *SENTINEL -/ FTP Management/* *//* esmie moo wrote: Good Morning Gentle Readers, I am working on a problem regarding a TSO alias which was not created but for some unexplicable reason I find about 15 dsns have been cataloged in the MCAT. My question is how can I fix this problem - have the dsns created in the proper UCAT. I looked at the option of using REPRO MERGECAT in the IDCAMS doc. Is that the correct decision? My plan is to define the alias in the proper UCAT and then execute the following jcl. //STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(SYS1.SHR.MCAT) - OUTDATASET(MBC.CSTMCAT) - ENTRIES(CTPRX23) - MERGECAT /* Will this do the job? Am I missing something? I would appreciate any suggestions or comments. Thanks in advance. - Looking for the perfect gift? Give the gift of Flickr! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
From: esmie moo [EMAIL PROTECTED] My plan is to define the alias in the proper UCAT and then execute the following jcl. //STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(SYS1.SHR.MCAT) - OUTDATASET(MBC.CSTMCAT) - ENTRIES(CTPRX23) - MERGECAT Esmie, I would first run the above job. However, code LVL(CTPRX23) instead of ENTRIES(CTPRX23). Once the above job runs fine, then define alias CTPRX23 related to MBC.CSTMCAT, which I assume is your user catalog. HTH Walter Marguccio z/OS Systems Programmer Munich - Germany ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
This is what I use when cleaning up Catalogs. This job will move the entries to the correct catalog without having to do any extra work. After you have them moved to the correct catalog define your alias and you will see the data sets. With this if you are just moving a few data sets it has no impact but if say you are moving 1,000 data sets you would want to scheduled that when there is very low usage. //REPROCAT EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(CATALOG.ABCZ14.MASTER ) - OUTDATASET(CATALOG.TSO.USER) LEVEL(TSOU01) MERGECAT /* Michael Saraco Systems Consultant From: esmie moo [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Date: 02/27/2008 07:34 AM Subject: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM Good Morning Gentle Readers, I am working on a problem regarding a TSO alias which was not created but for some unexplicable reason I find about 15 dsns have been cataloged in the MCAT. My question is how can I fix this problem - have the dsns created in the proper UCAT. I looked at the option of using REPRO MERGECAT in the IDCAMS doc. Is that the correct decision? My plan is to define the alias in the proper UCAT and then execute the following jcl. //STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440 //SYSPRINT DD SYSOUT=* //SYSINDD * REPRO - INDATASET(SYS1.SHR.MCAT) - OUTDATASET(MBC.CSTMCAT) - ENTRIES(CTPRX23) - MERGECAT /* Will this do the job? Am I missing something? I would appreciate any suggestions or comments. Thanks in advance. - Looking for the perfect gift? Give the gift of Flickr! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
I have to reorg some USER CATS because they contain the IMBED parm. You shouldn't have to for z/OS 1.8, nor should you put it on your critical path for implemementation. Yes, support for IMBED is going away, but existing datasets don't fail, under any release of z/OS, yet (unless I've missed an announcement). The removal of IMBED (and other parameters) should be a separate project. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
On Wed, 2007-12-05 at 06:45 -0800, willie bunter wrote: We will be implementing Z/OS 1.8 soon. I have to reorg some USER CATS Oh, and lest I forget: you may want to disable autotuning, which has had problems in z/OS 1.8. (Has IBM fixed this yet? I haven't been paying attention.) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
On Wed, 2007-12-05 at 06:45 -0800, willie bunter wrote: My question is should I need to code the CISIZE parm (CISIZE 28672 which is being used in the current USER CAT) or is the system default of 4096 sufficient? At the Tampa SHARE, Eileen McClintock gave a Tuning Techniques for Catalogs presentation. She recommends that you do not exceed a data CISZ of 8K. She also said you should not let index CISZ default; small index CI size can result in dead data CIs. Also: allocate in cylinders, not tracks. This affects CA calculations. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
Thanks John. McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Wednesday, December 05, 2007 10:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CATALOG QUESTION - CISIZE Thanks to all who responded. Last question, I compared the PRODUCTION USER CAT against my TEST USER CAT and I noticed in the LISTCAT of the PRODUCTION verison it had the TEMP-EXP but it did not show in the LISTCAT of my TEST USER CAT. Should there be reason for concern? No. TEMP-EXP just means that somebody, some time, did an EXPORT TEMPORARY on the catalog. We do that all the time for backup purposes. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Wednesday, December 05, 2007 10:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CATALOG QUESTION - CISIZE Thanks to all who responded. Last question, I compared the PRODUCTION USER CAT against my TEST USER CAT and I noticed in the LISTCAT of the PRODUCTION verison it had the TEMP-EXP but it did not show in the LISTCAT of my TEST USER CAT. Should there be reason for concern? No. TEMP-EXP just means that somebody, some time, did an EXPORT TEMPORARY on the catalog. We do that all the time for backup purposes. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
Thanks to all who responded. Last question, I compared the PRODUCTION USER CAT against my TEST USER CAT and I noticed in the LISTCAT of the PRODUCTION verison it had the TEMP-EXP but it did not show in the LISTCAT of my TEST USER CAT. Should there be reason for concern? David Andrews [EMAIL PROTECTED] wrote: On Wed, 2007-12-05 at 06:45 -0800, willie bunter wrote: We will be implementing Z/OS 1.8 soon. I have to reorg some USER CATS Oh, and lest I forget: you may want to disable autotuning, which has had problems in z/OS 1.8. (Has IBM fixed this yet? I haven't been paying attention.) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CATALOG QUESTION - CISIZE
---snip--- Thanks to all who responded. Last question, I compared the PRODUCTION USER CAT against my TEST USER CAT and I noticed in the LISTCAT of the PRODUCTION verison it had the TEMP-EXP but it did not show in the LISTCAT of my TEST USER CAT. Should there be reason for concern? -unsnip No. EXPORT TEMPORARY is an acceptable method of backing up a catalog. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
I looked at the manual and it seems like it says I can do a repro nomergecat. Change the master catalog option in iplparm, ipl and go. Before you proceed with this: -Run a complete set of DIAGNOSEs (catalogue all VVDSes) and cleanup/ address any discrepancies. -Make sure all volumes that have a VVDS with an entry for the master catalogue are online during repro nomergecat (the repro will fail in a middle in such a case, although, I seem to remember that it can be successfully re-run after a delete/redefine of the target/ new mastercat). The volumes need to be online since VVDS entries are being updated. Hth... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
Mark Jacobs wrote: Thanks for the pointer. I looked at the manual and it seems like it says I can do a repro nomergecat. Change the master catalog option in iplparm, ipl and go. We can manage any updates in the master catalog(s) until all systems are reipled. Do you read it the same way I do? Mark Jacobs Be very careful. According to the manual, I see this: After a REPRO of one catalog to another, the VVRs are changed to point to the target catalog, and all subsequent processing must be done under the target catalog. Attention: Performing REPRO on a catalog while data sets are open in the source catalog might result in a loss of information if any of those data sets extend, or other catalog updates are made. The changes might not be copied to the target catalog, resulting in a mismatch between the information contained in the VVDS and the new target BCS. This might cause the data sets to be inaccessible or receive errors. We did a REPRO mergecat for a new MASTER in prep for a z/OS 1.7 upgrade. The client instituted a freeze for several months, so we didn't get to IPL with tbe new MASTER. HSM's CDS data sets were in the master catalog. When a quarterly REORG was ran for HSM, the job failed after the deletion of the CDS indicating wrong catalog in the VVR (or whatever it was). We had to define new CDSs to recover. Not pretty. Any VSAM in the master will have this problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs Sent: Thursday, April 19, 2007 2:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Catalog Question Is the repro mergecat process disruptive to the source catalog? Does the answer change if the source catalog is the system master catalog/ Our master catalog was defined with the imbed/replication options and we are looking at the best way to migrate to a new catalog without the attributes. It is a six member sysplex and we would really not want to have a sysplex outage for the catalog switch. IPLing one at a time over a period of time would be fine however. -- Mark Jacobs Time Customer Service Tampa, FL Yes, REPRO MERGECAT is disruptive in that it REMOVES entries from the old catalog while ADDING them to the new catalog. If this is your current master catalog and it is shared, it might be possible to simply create a new master catalog (with a different name, of course). You can then: 1) IMPORT CONNECT all your current user catalogs 2) DEFINE ALIAS for all the current aliases 3) DEFINE NVSAM for all the non VSAM dataset datasets 4) DEFINE CLUSTER RECATALOG for all VSAM datasets which start with SYS1 (only works with SYS1) 5) DEFINE PAGESPACE RECATALOG for all pagespaces (regardless of the name, this will work) Steps 4 and 5 are allowed by special code in catalog processing. If you have VSAM datasets in your master catalog which do not start with SYS1, you cannot do step 4 to catalog them. 6) Update or create a new LOADxx member to point to the new master catalog. 7) Rolling IPL to use the new master catalog. NOTE - I have not done this. What I have done is use this method when I needed to create a new master catalog. But I've never done it in a sysplex environment. We only have a single z/OS image. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
On Thu, 19 Apr 2007 15:12:46 -0400, Mark Jacobs [EMAIL PROTECTED] wrote: Is the repro mergecat process disruptive to the source catalog? Does the answer change if the source catalog is the system master catalog/ Extremely! It moves catalog entries and also switches VVDS affiliations. The answer to the second question is no!. A mergecat is exactly what it says. It should be used with caution! Good luck! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
On Thu, 19 Apr 2007 15:12:46 -0400, Mark Jacobs [EMAIL PROTECTED] wrote: Is the repro mergecat process disruptive to the source catalog? Does the answer change if the source catalog is the system master catalog/ Yes it is. Mergecat moves the entries from the source catalog to the target. If you mean nomergecat, the answer is still yes. After a repro nomergecat, the VVDS entries are altered to point to the target catalog. You should not use the source catalog except to recover the new master. BTDTGTS -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
On Thu, 19 Apr 2007 15:12:46 -0400, Mark Jacobs wrote: Our master catalog was defined with the imbed/replication options and we are looking at the best way to migrate to a new catalog without the attributes. RTFM Managing Catalogs. There is a section on changing the size of a catalog that should be applicable, even if you don't plan to change the size. The process involves creating a new BCS -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
Mark, I am assuming that all systems in the plex are using the same mastercat. Check out IBM Redbook - ICF Catalog Backup and Recovery - Look at Case Senario #7. This explains two ways to do it. http://www.redbooks.ibm.com/redpapers/pdfs/redp4212.pdf Doing this over a period of time may not be a good idea unless you can be sure there were no updates to the old mastercat. Richard J Habres AVP - Merrill Lynch Mainframe Storage Ops - Dasd Administration -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs Sent: Thursday, April 19, 2007 3:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Catalog Question Is the repro mergecat process disruptive to the source catalog? Does the answer change if the source catalog is the system master catalog/ Our master catalog was defined with the imbed/replication options and we are looking at the best way to migrate to a new catalog without the attributes. It is a six member sysplex and we would really not want to have a sysplex outage for the catalog switch. IPLing one at a time over a period of time would be fine however. -- Mark Jacobs Time Customer Service Tampa, FL - How we behave toward cats here below determines our status in heaven. Robert Heinlein - The Cat Who Walks Through Walls (1985) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
Mark Jacobs wrote: Is the repro mergecat process disruptive to the source catalog? Does the answer change if the source catalog is the system master catalog/ Our master catalog was defined with the imbed/replication options and we are looking at the best way to migrate to a new catalog without the attributes. It is a six member sysplex and we would really not want to have a sysplex outage for the catalog switch. IPLing one at a time over a period of time would be fine however. If you have a copy of ServerPac: Installing Your Order handy, you might want to read the description of the catalog jobs (sorry, I've forgotten the names) for some important REPRO MERGECAT and REPRO NOMERGECAT considerations. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
Thanks for the pointer. I looked at the manual and it seems like it says I can do a repro nomergecat. Change the master catalog option in iplparm, ipl and go. We can manage any updates in the master catalog(s) until all systems are reipled. Do you read it the same way I do? Mark Jacobs -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Habres, Richard (GTI) Sent: Thursday, April 19, 2007 3:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Catalog Question Mark, I am assuming that all systems in the plex are using the same mastercat. Check out IBM Redbook - ICF Catalog Backup and Recovery - Look at Case Senario #7. This explains two ways to do it. http://www.redbooks.ibm.com/redpapers/pdfs/redp4212.pdf Doing this over a period of time may not be a good idea unless you can be sure there were no updates to the old mastercat. Richard J Habres AVP - Merrill Lynch Mainframe Storage Ops - Dasd Administration snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
I actually like building a new catalogue for each release. The only thing in my mastcat is system required VSAM, IBM supplied datasets, OEM datasets which are required in mastcat, and usercats/aliases for everything else. When I build the new cat, I use a homegrown COBOL program that reads a listcat the old mastcat and builds the control statements(DEFINE NONVSAM, IMPORT CONNECT, DEFINE ALIAS, etc) to put everything in the new catalog. Anything that I use from the old mastcat is accessed on a temporary basis using import/connect and aliases. My COBOL program is probably very silimar to the Rexx exec that another poster reffered to. Daniel McLaughlin wrote: I've been digging in the archives, haven't hit this yet. We're starting to test 1.7, have 1.4 in production and on our sandbox. I want to be able to use some HLQs that are in the 1.4 mastercat so I can get to my OEM stuff on 1.7. I'm not ready for the mergecat step just yet, at least I don't think so. Should I just import/connect the 1.4 master to the 1.7 master, do my testing, then unhook the 1.4 master and do the mergecat prior to cutover? It may seem like a rookie question, but in the past I was not the lead on this type of project and my mentors were not apt to divulge this type of process, for whatever reason. Many thanks and Happy New Year!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
And in our case, (just getting ready to install 1.7 into production) we went from mod3 to mod 9 volumes for our opsystem packs. I don't see how you can easily get away with not building a new master catalog. The way I did it: SYSR2 = SYSR1 SYSR3 = SYSR1 (via IEASYMxx setup for a new mod9 sysres) and kept my old master catalogue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
On Tue, 2 Jan 2007 14:58:02 -0500, Jakubek, Jan [EMAIL PROTECTED] wrote: And in our case, (just getting ready to install 1.7 into production) we went from mod3 to mod 9 volumes for our opsystem packs. I don't see how you can easily get away with not building a new master catalog. The way I did it: SYSR2 = SYSR1 SYSR3 = SYSR1 (via IEASYMxx setup for a new mod9 sysres) and kept my old master catalogue. Exactly. Then sometime after all your systems are migrated you can change the SYSR2/SYSR3 catalog entries to SYSR1 or **. I haven't built a new master catalog to facilitate an OS upgrade since MVS/ESA V5 (I have built them for other reasons). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - GITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
I've found that the easiest and safest way is to stick to the alias', just like the servpac creates. Jack Kelly LA Systems @ US Courts x 202-502-2390 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
On Fri, 29 Dec 2006 07:50:10 -0600, Daniel McLaughlin wrote: We're starting to test 1.7, have 1.4 in production and on our sandbox. I want to be able to use some HLQs that are in the 1.4 mastercat so I can get to my OEM stuff on 1.7. I'm not ready for the mergecat step just yet, at least I don't think so. Should I just import/connect the 1.4 master to the 1.7 master, do my testing, then unhook the 1.4 master and do the mergecat prior to cutover? It depends. First of all, I'm not sure why you have different master catalogs. And I'm not sure you want to do a REPRO MERGECAT at all. That will remove the entries from your source catalog. That said, you can certainly IMPORT CONNECT yout other master catalog and define aliases for those HLQs. Of course, this won't help if you need the data sets in the master catalog, e.g. because they are in LNKLST or LPALST. You can also use DEFINE NONVSAM to catalog them in your new catalog. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
First, I don't usually put OEM stuff in the master catalog unless it absolutely positively has to be there. OEM stuff is better of in a usercat. Doing so makes it easier to get to those products from other systems with other mastercats. Second, you can avoid this issue in the future by abandoning the process of building a new master catalog for each new release of the operating system. To handle your situation now you could just DEFINE entries in the 1.7 mastercat for the data sets that you need. This would work only for non-VSAM entries. For VSAM data sets, you can do a DEFINE RECATALOG, but only if the high-level qualifier is SYS1. To help build new entries for the 1.7 mastercat, you could check out Alistair Gray's REXX-based RCNVTCAT (or is it RCATCNVT?) on the CBT 'tape'. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Daniel McLaughlin Sent: Friday, December 29, 2006 8:50 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Catalog Question I've been digging in the archives, haven't hit this yet. We're starting to test 1.7, have 1.4 in production and on our sandbox. I want to be able to use some HLQs that are in the 1.4 mastercat so I can get to my OEM stuff on 1.7. I'm not ready for the mergecat step just yet, at least I don't think so. Should I just import/connect the 1.4 master to the 1.7 master, do my testing, then unhook the 1.4 master and do the mergecat prior to cutover? It may seem like a rookie question, but in the past I was not the lead on this type of project and my mentors were not apt to divulge this type of process, for whatever reason. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
I have to agree with Don. If something needs to be in the linklist or LPA list, I try to find another way. For instance, in the LINKLIST, I'll refer to the dataset with a vol-ser reference. I don't recall ever having something that needed to be in the LPALIST, so I'm unsure how to handle that situation. I try to avoid anything that might require MCAT updates, such as re-installing a OEM product. ANY update to a catalog, no matter how trivial it seems, poses a risk of damage and the MCAT is the Sacred Cow of your system. Damage might mean a disastrous outage. Rick - Imbriale, Donald (Exchange) wrote: First, I don't usually put OEM stuff in the master catalog unless it absolutely positively has to be there. OEM stuff is better of in a usercat. Doing so makes it easier to get to those products from other systems with other mastercats. Second, you can avoid this issue in the future by abandoning the process of building a new master catalog for each new release of the operating system. To handle your situation now you could just DEFINE entries in the 1.7 mastercat for the data sets that you need. This would work only for non-VSAM entries. For VSAM data sets, you can do a DEFINE RECATALOG, but only if the high-level qualifier is SYS1. To help build new entries for the 1.7 mastercat, you could check out Alistair Gray's REXX-based RCNVTCAT (or is it RCATCNVT?) on the CBT 'tape'. Don Imbriale -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Friday, December 29, 2006 10:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Catalog Question I have to agree with Don. If something needs to be in the linklist or LPA list, I try to find another way. For instance, in the LINKLIST, I'll refer to the dataset with a vol-ser reference. I don't recall ever having something that needed to be in the LPALIST, so I'm unsure how to handle that situation. I try to avoid anything that might require MCAT updates, such as re-installing a OEM product. ANY update to a catalog, no matter how trivial it seems, poses a risk of damage and the MCAT is the Sacred Cow of your system. Damage might mean a disastrous outage. Rick In the LPALST, the syntax is: dsn(volser) -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
---snip In the LPALST, the syntax is: dsn(volser) unsnip Thanks, John Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
Uh, could you (or any one else) expound on this?, usually IBM tends to rename the sys1 files, moves them to other volsers, changes sizes of files which tend to force file to different volsers. etc. And in our case, (just getting ready to install 1.7 into production) we went from mod3 to mod 9 volumes for our opsystem packs. I don't see how you can easily get away with not building a new master catalog. - Original Message - From: Imbriale, Donald (Exchange) [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, December 29, 2006 10:50 AM Subject: Re: Catalog Question snip Second, you can avoid this issue in the future by abandoning the process of building a new master catalog for each new release of the operating system. snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog Question
Harold, You say usually IBM tends to rename the sys1 files, moves them to other volsers, changes sizes of files which tend to force file to different volsers. etc.. I may not understand what you mean by this, but I have not really encountered these issues. Many of the data sets are on the sysres (or its extensions) and the catalog entries can use indirect volsers or symbols. If it's on the sysres for 1.4, it will probably be on the sysres for 1.7. So the 1.4 catalog entry with volser ** will still work for 1.7; when you IPL a 1.4 sysres, those will point to that volume; when you IPL a 1.7 sysres, they will point to the 1.7 sysres. Other data sets tend to stay in place also, whether it be a volume for HFS/zFS data sets or operational data sets such as SYS1.PARMLIB; so catalog entries for 1.4 will still work for 1.7. With each new release, you can use ServerPac to identify what data sets are new and where they are located. You can add those entries to your master catalog without impacting the running of your 1.4 system, but still be ready to run 1.7. If IBM 'tends to rename the sys1 files' (which I don't really think they do), add the new name to the catalog. When you've completed conversion to 1.7, then delete the old unneeded entries. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Harold Zbiegien Sent: Friday, December 29, 2006 3:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Catalog Question Uh, could you (or any one else) expound on this?, usually IBM tends to rename the sys1 files, moves them to other volsers, changes sizes of files which tend to force file to different volsers. etc. And in our case, (just getting ready to install 1.7 into production) we went from mod3 to mod 9 volumes for our opsystem packs. I don't see how you can easily get away with not building a new master catalog. - Original Message - From: Imbriale, Donald (Exchange) [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, December 29, 2006 10:50 AM Subject: Re: Catalog Question snip Second, you can avoid this issue in the future by abandoning the process of building a new master catalog for each new release of the operating system. snip *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
