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 <retired-mainfra...@q.com> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 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:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Wednesday, September 14, 2016 4:33
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > 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 lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to