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

Reply via email to