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. Thanks. -------------------------------------------- On Tue, 9/13/16, retired mainframer <retired-mainfra...@q.com> wrote: Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, September 13, 2016, 1:01 PM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, September 13, 2016 9:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: REASON: 3 - RECORD TYPE NOT RECOGNIZED > > Hi All, > > While running a DIAGNOSE on a USERCAT the following error was picked up: > > IDC21364I ERROR DETECTED BY DIAGNOSE: > ICFCAT ENTRY: 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 (7) > RECORD: 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0 > OFFSET: X'0002' > REASON: 3 - RECORD TYPE NOT RECOGNIZED > IDC21365I ICFCAT RECORD DISPLAY: > RECORD: 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0 > > The programmer response (I hope I read it right) says > Use DELETE NOSCRATCH to remove the sphere or base record, if it exists. > > I have 2 questions: > Since the dsn is not listed in the job output after IDC21364i message I assume that the dsn - > listed on side (cols 85 to 119) - > I assume that is the dsn in question. Please correct me if I am wrong. > > Is this problem serious or it can wait for action to be taken? The problem was detected > about 10 days ago. You have already waited ten days and not yet taken any action. Has there been any noticeable impact? If you run the DIAGNOSE again, do the results change? For better or worse? Were other activities that use the catalog running at the same time as your DIAGNOSE? When I was running EXAMINE jobs to confirm consistency between catalogs and VVDSs, I determined that some reported errors were transient and could be eliminated by executing the VERIFY command just prior to the EXAMINE. I don't know if the same issue could affect DIAGNOSE. If it is a permanent error, I would be more concerned with how it occurred and what to do to prevent it in the future. ---------------------------------------------------------------------- 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
