http://www-01.ibm.com/support/docview.wss?uid=isg1II13354 For reorging / moving a catalog to a new volume.
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idac100/dffvol.htm New location, possibly updated. On Fri, Sep 16, 2016 at 12:23 PM, willie bunter <[email protected]> wrote: > I tried that and it failed because when you use export/import, catalog code > expects you to import using the same name and the same volume so unless you > can use the same volser and the same catalog name this will not work. > > -------------------------------------------- > On Thu, 9/15/16, Gibney, Dave <[email protected]> wrote: > > Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED > To: [email protected] > Received: Thursday, September 15, 2016, 3:25 PM > > Well, try to IMPORT the > back-up on a test system or different name and see what > happens. > > > -----Original > Message----- > > From: IBM Mainframe > Discussion List [mailto:[email protected]] > > On Behalf Of willie bunter > > Sent: Thursday, September 15, 2016 10:07 > AM > > To: [email protected] > > Subject: Re: REASON: 3 - RECORD TYPE NOT > RECOGNIZED > > > > I was > told that EXPORT/IMPORT would not fix the problem because it > would > > export the bad records only REPOR > MERGECAT would work. > > > > I ran a LISTCAT on the dataset (as flagged > by the DIAGNOSE) and it came > > clean. > This leads me to believe that it may not be the offending > dsn. The dsn > > is on the volumes (3) > > > > The catalog is > backed up via IDCAMS EXPORT daily successfully. > > > > I plan to run a > VERIFY/EXAMINE (as recommended) and see what comes out. > > > > > -------------------------------------------- > > On Wed, 9/14/16, retired mainframer <[email protected]> > > wrote: > > > > Subject: Re: REASON: 3 - RECORD TYPE NOT > RECOGNIZED > > To: [email protected] > > Received: Wednesday, September 14, 2016, > 12:37 PM > > > > REPRO > MERGECAT does not > > seem like the best > choice to me. It might work for a user catalog since > the > > DSN is not needed by users to > access their datasets. For every level that is > > moved, you need to change the alias in > the master to relate to the new DSN. > > > (This is what the warning is about.) What will REPRO do > when it encounters > > the bad record? > > > > It's been a > while but I seem to remember using EXPORT followed by > IMPORT > > for issues like this. > Don't forget to lock the catalog for the job's > > duration. (You may need to do this > during scheduled down time without > > > users accessing the catalog.) > > > > What happens if you try to > > access the dataset by way of the > catalog, such as specifying it on a DD > > statement? Have you tried to > manually delete and recreate the offending > > catalog entry? Is the dataset physically > on the volume the catalog thinks it's > > on? > > > > From where > > would > you restore the catalog? How was it backed up? If by > DFDSS, was it a > > physical or logical > backup? > > > > > > -----Original Message----- > > > From: > IBM Mainframe Discussion List > > > [mailto:[email protected]] > > On > > > Behalf Of > willie bunter > > > Sent: Wednesday, > September 14, 2016 4:33 AM > To: IBM- > > [email protected] > > Subject: Re: REASON: 3 - RECORD TYPE NOT > > RECOGNIZED > > The DIAGNOSE > gives the same error and no change. I ran > > examine (using the following > > parms) and " > > NO ERRORS > DETECTED" > > > > > > INDEXTEST DATATEST > > > > > ITEST > NODATATEST ERRORLIMIT(1000) > > > > > NOITEST DATATEST ERRORLIMIT(1000) > > > > > > I ran > LISTCAT against the CATALOG and it flagged the same VSAM > dsn > > posting the > following > error messages: > > > IEC331I > > 028-002,LISTCAT ,STEP1 ,IGG0CLEG > > > According to the problem > explanation > > > Explanation: An I/O > error processing > > the > > > catalog occurred while > processing > > an access > > > method services command that > > requires > > > > modifying the catalog. > > > > Programmer Response: Messages IEC331I, > IEC332I, and > IEC333I have > > been printed to aid > > in determining the cause of the error and > > where > > the error occurred. If a > hardware error > is not causing the problem, > > restore or > rebuild the > catalog. > > > > > > > I have > > read up on the process of > rebuilding the catalog (REPRO > > > MERGECAT) however > > > there could be > a > > problem when using LEVEL or ENTRIES > parm. According to the doc > "may > > cause data sets to no longer be > found". This is not reassuring. > > > > > > I would > prefer to > > restore the CATALOG which > seems safer. I would like guidance on this > > > subject. > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / > archive access instructions, send email > > to [email protected] > with the message: INFO IBM-MAIN > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive > access instructions, send email to > > [email protected] > with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive > access instructions, > send email to [email protected] > with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
