GV905 VSAM STRUCTURE ERROR - INDEX PREMATURE EOF
Article ID: 221764
Updated On:
Products
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.
Feedback
