Re: Question concerning Master Catalog Compare
Hi Dave, T-REX by Dino Software has the ability to compare and synchronize two separate catalogs (usercatalog or master catalog). Simulate, record type, update type (add, delete, merge and replace), and other selection/update criteria can be specified. A logical comparison is performed between matching records rather than a physical comparison (i.e. multiple aliases relating to the same usercatalog or nonvsam entry can reside at different offsets in the physical record without incurring a mismatch ((as long as all the aliases are there relating to the correct component)). Typically when you are building a new master catalog, you clone the current one. There can be any number of days, weeks, or months before migrating to the new system (new master catalog). You must remember to apply all updates (new aliases, VSAM, nonVSAM, etc) to the new master catalog as well as the old one until the switch is made. LISTCATs are usually run just before the switch and the two catalogs are visually compared. The COMPARE and SYNCH commands allow you to logically compare two catalogs and optionally synchronize the contents of the target BCS. Best regards, Blair Blair Svihra Dino-Software Corporation 800-480-DINO www.dino-software.com Dino-Software Utilities T-REX - Superior catalog management tool inclusive of HSM & Tape audits REORGadon - First REORG While-OPEN tool for HSM Teradon - First ever OnLine REPRO MERGECAT utility Xtinct - DASD Data purge RTD - DASD Real Time Defrag DAL - Analysis for Legato in an easy to view format -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Monday, March 22, 2010 11:30 AM To: IBM-MAIN@bama.ua.edu Subject: Question concerning Master Catalog Compare A colleague has posed the following question: Any idea how to compare an old and new master catalogue to find out what is missing in the new one? I had to have done this last time I put up a system but can't find any doc. Mainstar doesn't seem to have anything. There are SYS1 datasets that are not IBM that I need to add to the new master for z/OS 1.11 Any and all suggestions welcomed. Thank You, Dave O'Brien NIH Contractor -- 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: Resolving an ALIAS
Review figure 38 on page 44 in the manual Bruno Sugliani referenced -
http://www.redbooks.ibm.com/redbooks/pdfs/sg245336.pdf
What is not clear from the example is your user will use
SYS5.MQ.whatever in their JCL (JCL never has to change) but will
reference SYS5.MQ..whatever where is a symbol for the current
version. You can update the symbolic when you change releases without
requiring the user to update JCL.
IEASYMxx
.
.
SYMDEF(&rel='&v3R4')
DEFINE ALIAS(NAME('SYS5.MQ.WHATEVER') SYMRELATE('SYS5.MQ.&REL.WHATEVER'))
In th JCL
//DD1 DD DSN=SYS5.MQ.whatever,DISP=SHR
--
Blair Svihra
Dino-Software Corporation
800-480-DINO
www.dino-software.com
Dino-Software Utilities
T-REX – Superior catalog management tool inclusive of HSM & Tape audits
REORGadon – First REORG While-OPEN tool for HSM
Teradon – First ever OnLine REPRO MERGECAT utility
Xtinct - DASD Data purge
RTD - DASD Real Time Defrag
DAL – Analysis for Legato in an easy to view format
Rob Lister wrote:
Hi,
Wonder if anyone can help with a small issue I'm having, trying to understand
how an ALIAS gets resolved.
We are installing a product on a zOS system that utilises MQ to pass
messages to/from a DB2 Subsystem.
When we asked the client for certain MQ dataset names, they came back with
SYS5.MQ..whatever
saying that the was using an ALIAS to determine which version was
being used. Therefore, we wouldn't need to change the dataset names
when/if we used a new version.
Could anyone explain how that works or, point me to a manual that could
explain it.
Many thanks,
Rob
--
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: user catalog question
Is there a mount message on the console (LISTCAT looking for VVRs in the VVDS's on unavailable volumes)? -- Blair Svihra Dino-Software Corporation 800-480-DINO www.dino-software.com Dino-Software Utilities T-REX – Superior catalog management tool inclusive of HSM & Tape audits REORGadon – First REORG While-OPEN tool for HSM Teradon – First ever OnLine REPRO MERGECAT utility Xtinct - DASD Data purge RTD - DASD Real Time Defrag DAL – Analysis for Legato in an easy to view format Peter Ten Eyck wrote: Thanks for your replies. I am now just getting back to this problem. My previous posts within my user catalog question were me asking how to do something, let me now tell you why I am asking. I ran into this problem at DR. I import a user a catalog (CATALOG.MVSICF1.VUSRCAT) and connect it to a master catalog on a different z/OS system. On this different system the DASD does not align with CATALOG.MVSICF1.VUSRCAT, meaning that many DASD data set are not on the volume that CATALOG.MVSICF1.VUSRCAT thinks it is. If I run the job below, it seems to either loop or run for a very long time, 3 plus hours before I cancel it. What happens when I do a listcat on a catalog that does not match the location of many of the data sets on DASD volumes? //TZLISTC JOB CLASS=S //SCRTCH EXEC PGM=IEFBR14 //D1 DD DSN=TECH.VUSRCAT.LISTC,DISP=(MOD,DELETE), // UNIT=SYSALLDA,VOL=SER=Z17RS1,SPACE=(0,0) //LISTC EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * LISTC ALL OUTFILE(OUTFILE) CAT(CATALOG.MVSICF1.VUSRCAT) /* //OUTFILE DD DSN=TECH.VUSRCAT.LISTC,DISP=(,KEEP), // UNIT=SYSALLDA,VOL=SER=Z17RS1,SPACE=(TRK,(45,45),RLSE), // DCB=(RECFM=VBA,LRECL=125,BLKSIZE=27998) // -- 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
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: Damaged Catalog Alert
APAR OA19870 As the result of IBM's AUTOTUNE feature attempting to re-open a BCS, message IEC331I 026-008(21080018) was issued by the Catalog Address Space. This error indicates that a VSAM record management error has occurred. The RPL Feedback Word (RPLFDBWD) reported by the IEC331I message contains X'08' as the return code (logical error) and X'0018' as the RPL condition or reason code. The RPL Reason Code 24(X'18') suggests that the target record resides on a volume that cannot be mounted. In other words, the current VSAM component extent list does not include the extent where the requested record resides. The catalog has acquired an extent, but the BCS data component VVR does not reflect the new extent. An IDCAMS EXAMINE detects and reports an additional symptom by issuing error message IDC11728I DATA FOUND IN EMPTY CI. This is another indication that the BCS data component VVR does not accurately depict the contents of the BCS data component. Unfortunately, IBM has not identified the cause of the corruption. As a preventive measure, APAR OA19870 introduces new diagnostics that are invoked when the BCS VVRs are updated by the VVDS manager to ensure that specific values contained in the "new" VVR are not less than the values in the existing VVR. If the new values are not logically consistent with the existing VVR values, the update is disallowed and the user will be issued a catalog management Return/Reason Code 050-1xx (where the reason code will be greater than 100, the maximum Reason Code currently documented for IDC3009I Return Code 50). Originally, this was thought to occur only for catalogs using the Enhanced Catalog Sharing protocol, but ECS has since been eliminated as a potential cause for the corruption. The VVR corruption detected by the PTFs for OA19870 can occur whether you are using ECS or VVDS sharing protocols. Basically, the new VVDS error checking tries to disable inplace reorganizations of the BCS. IBM is aware that the error checking will affect vendor products, and that it is not a fix that identifies or corrects the original extent problem. Maintenance is available for Dino Softwares T-REX product that will allow inplace BCS reorganizations to function with OA19870 applied. Typically, new extents are not associated with inplace reorgs. Due to the nature of an inplace reorganization, OA19870 may cause catalog corruption in products that reorganize a BCS (in a shared environment) when the HURBA is decreased i.e. reorganizing the internals of a BCS where no real reorganization takes place (HURBA is not decreased) might not be a problem. I would suggest checking with all vendors that offer catalog reorganization products to see if they are aware of OA19870 and if they have tested a valid reorganization in a shared BCS environment. I hope this information is of some use. Blair Svihra Dino-Software Corporation 800-480-DINO www.dino-software.com Dino-Software Utilities T-REX Superior catalog management tool inclusive of HSM & Tape audits REORGadon First REORG While-OPEN tool for HSM Teradon First ever OnLine REPRO MERGECAT utility Xtinct - DASD Data purge RTD - DASD Real Time Defrag DAL Analysis for Legato in an easy to view format -- 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: Extended Catalog Sharing PROBLEM
Hi Jim, there have been a number of CAS related issues introduced in 1.7 and 1.8. Dino Software initially notified IBM of the CAS CLOSE (F CATALOG,CLOSE) problem back in December of 05. It took IBM quite a while to release UA28625 (1.7) and UA28626 (1.8) to address the problem. We keep our customers apprised of CAS issues/maintenance via emails (also review OA18520). If you are interested, we could include you on our email list to let you know about CAS and catalog issues as we detect and report them to IBM. Let us know, we would be glad to help. Best regards, Blair Svihra Dino Software, Inc. www.dino-software.com Jim Marshall wrote: We are at z/OS V1R7 and learned (the hard way) there is a current BUG in Extended Catalog Sharing which is still outstanding and places catalogs at risk. Had a Development catalog broken by ECS. IBM says there are APARs to apply and also some to come out in two weeks or so. IBM says: "We see in the dump that we are requesting an ENQ on SYSZCATS that we already own. This is a symptom of apar OA18578 whose PTFs should be available in the next 2 weeks. In addition, the F CATALOG,CLOSE being issued is not working properly due to the lack of PTF UA28625. Lastly, we also suggest you apply hyper PTF UA28375 to avoid a fairly ugly deadlock involving ECS. You see the part of about OA18578 which is not available yet! We are turning ECS off for now. The exposure is still lurking in the shadows. My guys are now believers in having some Catalog Recovery (FIXIT) tool when something like this happened. When I bought it, most had never seen a catalog broke; some were really old timers too. Jim -- 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: Reconstructing HSM BCDS
Hi Bob, HSM Auditing is also included in T-REX (original developers of VSAM Mechanic/Catalog Solution). If you like, I can forward you a copy of the product to clean up your environment (just remove it when you are done). Best regards, Blair Svihra www.dino-software.com Bob Henry wrote: After doing several different audits I've discovered that my HSM database is a mess. I have Err 39, Err 41 and ERR 71 all over the place. I don't know what caused it yet, but the task now is to reconstruct the broken BCDS/OCDS. I can't go back to backup copies of the files and/or logs because they've rolled off a GDG. Are there any tools out there that can help with the reconstruction? Anyone have any suggestions where to start? Since I haven't received replys to some earlier HSM posts is there a better forum to direct this question? -- 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: HSM LIST TTOC for backup volumes
Hi Brian, Dino-Software has a product called T-REX that can identify the
entries on the OCDS volumes and translate the HSM internal names back to
the BCDS and MCDS. We can ship it to you to use for a few days (no
cost) so you can resolve your HSM issues. Let me know if we can help.
Best regards, Blair Svihra Dino-Software, Inc. www.dino-software.com
Perryman, Brian wrote:
Not to worry folks, I've kind of cobbled together a solution in the end, by
running ICETOOL over the BCDS:
SORT FROM(HSMBCDS) TO(EXTRACT) USING(HSMD)
DISPLAY -
FROM(EXTRACT) -
LIST(REPORT) -
DATE TITLE('BCDS breakdown
HEADER('Backdsn')ON(65,44,CH) -
HEADER('Backtap')ON(109,6,CH) -
HEADER('Backver')ON(135,2,BI) -
BLANK
//HSMDCNTL DD *
OPTION VLSHRT
SORT FIELDS=(109,6,CH,A)
INCLUDE COND=(47,1,BI,EQ,X'24')
Brian
--
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction NetworkServices.
Any unauthorized review, use, disclosure or distribution isprohibited. If you
are not the intended recipient, please contact thesender by reply e-mail and
destroy all copies of the original message.
--
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
