TSSAKS@UWAMVS1.ADP.WASHINGTON.EDU (206 Al Shing 545-3770) (02/02/90)
> Our site has recently converted to MVS/XA 2.2.0 and due to a lack of > physical DASD space I am not sure that the system we built is very > well setup. > > Until I can re-organize the system, we have 5 single density 3380s > on which the system and vendor products are located. I have our > master catalog on a 'CAT' volume. Where should my usercats be and > how does that affect my stand-alone recovery environment if I loose > one or more of the volumes? Using DF/DSS for the SA backups; does this > need to be done in a dry environment? Do all volumes with catalogs on > them need to be restored at the same time/level in order to keep the > system and catalogs in sync? > Usercats should be located on volumes other than the master catalog volume, and preferably on volumes where there are no other VSAM data sets, in order to avoid lockout situations from reserve/release by another CPU. Backups generally should be done using IDCAMS export. I have found that catalogs restored from a volume dump to be unreliable, as well as back-leveled. The export backup can be processed through ICFRU to generate a current backup, which can then be imported. The catalog environment will then be current. The time stamp problem went away with the ICF catalog. No consideration should be given to establishing anything other than an ICF catalog environment. > > Assuming that I wish to move a usercat to another volume, what is the > procedure and the pitfalls? Can I export the UCAT without deleting its > data, move it to another volume and import it with all of it pieces > intact. Can this be done if the UCAT has datasets thru which certain > products have opens or enqueues? > Generally, a UCAT can be imported to another volume, but this always results in the deletion of the original catalog. This is unavoidable using this method. A method that I am fond of is the REPRO MERGECAT, in which a new catalog is defined, and the entries copied via this function. However, the entries are deleted from the first catalog, the VVDS pointers get changed, and the new catalog has a different name under this scheme. Backing out is usually a lot harder if this method is used. As always, the UCAT should be closed and unallocated before any such surgery is to be performed. This is easier under DFP 3.1 and above. Prior to this, an IPL had to be done in some cases in order to get a catalog unallocated. Now, the catalog address space has all the allocations, and a MODIFY CATALOG command will get the catalog closed and unallocated. > > I have a usercat which has an entry to VVDS on a volume which no longer > exists in the environment. When I do a LISTCAT ALL of this UCAT I get a > the following errors: > > IDC3014I CATALOG ERROR > IDC3009I ** VSAM CATALOG RETURN CODE IS 50 - REASON CODE IS IGG0CLE3-92 > > on the data portion of the VVDS entry in the UCAT. From here the LISTCAT > carries on with the next entry in the catalog and proceeds to the end of > the catalog. Is this error simply indicating it can not get to the > desired volume to check the existence/integrity of the VVDS? Is there a > way to remove this reference? A DELETE...NOSCRATCH still tries to check > the integrity of the VVDS obviously wanting to check the volume which > no longer exists. Do I need to temporarily clip a volume back to this > volser in order to statisfy the catalog managements ability to get to > the device? Do I have to create a VVDS on this temporary volume too? > You need to clip a volume to the old name, and mount it in order to delete the VVDS entry. You do not need to define the VVDS, simply issue the DELETE VVDS NOSCRATCH command. The entry will be deleted. Remember that the VVDS will be defined to more than one catalog. Therefore, issue the command to all your catalogs in order to ensure that you have gotten rid of them all. > > My MVS/XA 2.2.0 system includes DFP 2.3 and DF/DSS 2.4. We also have > DMS/OS 8.0 but this is a new acquisition for us and we are still cutting > our teeth on it. Some of the problems we are currently fighting with are > self-inflicted wounds cause by having too many people with fingers in the > pie all wanting to pull the pie in different directions. > > Lastly, is anyone else experiencing IEC161I 064(008)-086 messages on > their catalog accesses? We had one of these problems go solid causing > us a very grief ladden recovery of the affected UCAT. A IBM RETAIN scan > came back with virtually no hits (implying that we are the only ones > experiencing this failure). I say virtually because the only hits which > matched our symptoms (fairly closely, too) was relating to DFP 3.1.1 > under MVS/ESA. In this incident, the problem went away by performing an > unload/reload of the affected UCAT (this was the other customer's > terminology, not mine). Does this terminology imply some sort of > different action than would be involved in a UCAT EXPORT/IMPORT > recovery? > This sounds like something is systematically destroying the catalog. Check to make sure that any appropriate toleration PTFs for your environment are applied. Along with this, if you are having these types of problems, the next step is to get as current as possible in DFP maintenance. If all else fails, check for an application that may be inadvertently writing to the catalog. I once had an application that wrote EOFs to all allocated data sets, including the catalog! This led to numerous catalog recoveries until the culprit was discovered and corrected. > > Thanks for any light you can shed into the rapidly darkening hole I am > trying to dig myself out of!! > > -- > Call me at 5992 if you have questions or comments. > > _ _ "The difficulty of getting anything started increases > / ) / / / ) with the square of the number of people involved" > / /-/ /_/ > (_/ / / / | MVS Technical Support - University of Western Ontario > Chuck Reid. Rm16.SLB.CCS.UWO.London.Canada / CCSCHR@UWOCC1.UWO.CA
LDW@USCMVSA.BITNET (Leonard D Woren) (02/02/90)
> > A DELETE...NOSCRATCH still tries to check > > the integrity of the VVDS obviously wanting to check the volume which > > no longer exists. Do I need to temporarily clip a volume back to this > > volser in order to statisfy the catalog managements ability to get to > > the device? Do I have to create a VVDS on this temporary volume too? > > > You need to clip a volume to the old name, and mount it in order to > delete the VVDS entry. You do not need to define the VVDS, simply > issue the DELETE VVDS NOSCRATCH command. For DFP 3.1, OY19185 is fixed by UY33397 (8903). This allows DELETE SYS1.VVDS.Vxxx NOSCRATCH to work if volume xxx does not exist. I called the support center on this one a while back because we had VVDS catalog entries pointing to 3350s. It's a bit difficult to "temporarily clip a volume back" to that volser just to delete the VVDS catalog entry when we no longer have any 3350s... Leonard D. Woren Senior MVS Systems Programmer <LDW@USCMVSA.BITNET> <LDW@MVSA.USC.EDU> University of Southern California
HABKE@UOFMCC.BITNET (WILLIAM HABKE) (02/02/90)
// JOB 'T=10,I=10,L=1'
// EXEC PGM=IDCAMS,REGION=512K
//A DD DISP=OLD,UNIT=3350,VOL=SER=SYSMVS
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
DEL 'SYS1.VVDS.VTEMPX1' PURGE NSCR FILE(A) CL -
CAT('ICFCTLG.VSYSMVS'/XXXXXXXX)
This procedure should help you get rid of unwanted vvds's
The dd statment should point to any existing ucat volume.
This just fakes out idcams since it only checks for a volume
but does not actually go to the vvds since noscr is specified.
Hope this helps
Bill Habke
System Analyst
University of Manitoba