GV905 VSAM STRUCTURE ERROR - INDEX PREMATURE EOF

book

Article ID: 221764

calendar_today

Updated On:

Products

CA FAVER VSAM Data Protection for Z/OS

Issue/Introduction

Many application team jobs are failing with the below error most of the days, but when we do a restart of the job it completes sometimes and sometimes not. Programmers checked for contention. Still the same issue. The job runs fine sometimes and sometimes doesn't run at all. Keeps failing.

As per last time recommendation. Many tried removing ESTOP from EXPORT. But still JCL fails RC=12 with successful EXPORT.

Everyone is looking for a permanent solution. Its NAM,EMEA,LATAM and ASPAC all are affected.

 

GV120 DEFAULTS: CACHE=SEQ,BUFSPMAX=368640,NORECALL(HSM),AIX,NOEXO,DISP=SHR,RECLEVEL,NOSHR,NOVSAMAID,NOSAVECOMP

 EXPORT ESTOP EXO       
   CL=SPXR.LAR.+       -
   CL=SPXR.LSS.+        
 EXCLUDE                
   CL=SPXR.LAR.AMSS.+  -
   CL=SPXR.LAR.AMSL+   -
   CL=SPXR.LAR.AMOS.+  -
   CL=SPXR.LAR.AMBS.+  -
   CL=SPXR.LAR.AMPS.+  -

Actual JCL step fails like this:
IEF472I PXRARA0B STEP0010 GBASDSSU - COMPLETION CODE - SYSTEM=000 USER=0009 REASON=00000000
IEF285I   OPCAUSER.PXRARA0B.J0259032.D0000101.SYSPRINT SYSOUT                  
IEF287I   SPXR.BSY.AR.BKUPAFO.G2874V00                 NOT UNCTLGD 13          

Error:
GV104 OPEN FOR OUTPUT                                                         
GV905 VSAM STRUCTURE ERROR - INDEX PREMATURE EOF                              
DIRECT LAST INDEX CI RBA = 00011D71 SEQUENTIAL LAST INDEX CI RBA = 00011D72   
GV108 RECORD COUNTS DISAGREE CATALOG= 14792297                                
                      ----------------------      05-AUG-21 11:00:41  15489344
GV303 ERROR READING CLUSTER                                                   
GV111 CONDITION CODE SET TO 012   

 

After ESTOP removed :

GV120 DEFAULTS: CACHE=SEQ,BUFSPMAX=368640,
  EXPORT  EXO                             
    CL=SPXR.LAR.+       -                 
    CL=SPXR.LSS.+                         
  EXCLUDE                                 
    CL=SPXR.LAR.AMSS.+  -                 
    CL=SPXR.LAR.AMSL+   -                 

IEF142I PXRARA0B STEP0010 GBASDSSU - STEP WAS EXECUTED - COND CODE 0012       
IEF285I   OPCAUSER.PXRARA0B.J0259323.D0000101.SYSPRINT SYSOUT                 
IGD108I SPXR.BSY.AR.BKUPAFO.G2874V00                 CATALOGED, DDNAME=FVROUT0
        VOLUME SERIAL NUMBERS =                                               

 

Environment

Release : 4.5

Component : CA Faver VSAM Data Protection

Resolution

The issues you are experiencing are not something Faver can resolve. These are IDCAMS related issues.

These are the potential resolutions we "usually" run into most often.

Using EXO options says that a user can have a file allocated and make updates while Faver is copying the file "without" and exclusive enqueue. This is not always good and we advise users not do this in the documentation .

However, customers will use this parameter anyway and not run into many issues. Literally, updates can be made during an export. This results in record counts that disagree with the original catalog information stored at the beginning of the export or enqueue issues.

Index updates can be made, altering the index counts during verification.

Enqueues during an update can occur at export time of a particular cylinder/track causing record allocation errors in the EXCP export process. The EXCP process allocates specific space on the volume where the cluster resides. If that space is allocated to CICS or similar allocation at the same time you could run into issue. A matter of timing during the updates.

When you perform a IDCAMS export an exclusive enqueue is placed on the index and data component. That is why users utilize products similar to Faver. It is fast and does not hold the cluster for a long time. However, the same customers will utilize EXO for files that are not usually OPEN but still allocated. For example: CICS regions cannot be shutdown and files still are allocated. BUT, the files are not being updated or changed in any way so EXO allows Faver to perform the export process.

I have a lot of users that run a IDCAMS VERIFY on specific clusters just to be sure the catalog information is accurate at export time. The files are allocated but dormant at that time.

The VERIFY will also update the catalog record counts which could alleviate any record count disagree messages.