I would probably open an SR with IBM on DFSMS VSAM - any actions taken might require their assistance to recover. Better to have them look and help provide the right guidance.
Lizette > -----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. > > 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- > m...@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
