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
<0000001409bd2345-dmarc-requ...@listserv.ua.edu> 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 <gib...@wsu.edu> wrote:
>
>  Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  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:IBM-MAIN@LISTSERV.UA.EDU]
>  > On Behalf Of willie bunter
>  > Sent: Thursday, September 15, 2016 10:07
>  AM
>  > To: IBM-MAIN@LISTSERV.UA.EDU
>  > 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 <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-
>  > m...@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
>
>  ----------------------------------------------------------------------
>  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



-- 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to