II07329: HINTS AND TIPS FOR DEBUGGING VTOC INDEX DISABLED PROBLEMS AND OVERLAPPING EXTENTS ( IEC602I )

APAR status

• INTRAN

Error description

• The VTOC index is disabled when a mismatch is detected between
  the index and the VTOC or if an error is found within the
  index.  Some common return codes from the IEC606I (CVSTAT) are:
    RC141 - The VIER structure error bit is on.  This is
            frequently caused by an index/VTOC mismatch.  Analyze
            the syslogs from all sharing systems.  See "Cross
            System Sharing Considerations" later in this APAR.
            RC8D.
    RC143 - The current system has found that the index has been
            disabled by another system or by some other means.
            Analyze syslogs from all sharing systems.  See "Cross
            System Sharing Considerations" later in this APAR.
            RC8F.
    RC153 - The current system is disabling the index due to a
            mismatch in the index/VTOC.  Analyze syslogs from all
            sharing systems.  See "Cross System Sharing
            Considerations" later in this APAR.  RC99.
    RC159 - The first high-level VIER pointed to by the VIB has an
            incorrect ID in the header.  This is frequently caused
            by improper serializaton.  Review the syslogs from all
            sharing systems.
    RC166 - An invalid FMT4 DSCB has been detected.  Determine
            why the FMT4 is missing or bad on the failing volume.
            This return code can happen during an SMF switch
            because SMF will issue an LSPACE to every online
            volume.  If a volume has been "clipped" or does not
            contain a valid FMT4, an ABEND18B RC166 x'A6' RCA6
            can result.  The problem volume is not necessarily
            the volume that the SYS1.MANx dataset resides on.
            Vary the problem volume offline to allow the SMF
            switch to occur.
  .
  When the index is disabled, an ABEND18B dump will be taken.
  If there is no MSGIEC606I, the way to find the CVSTAT is as
  follows:
  1) Browse the "W/A" address from the dump title.  For example:
     "ICVCMB00 CVAF ERROR TYPE 1  TCB=00DFAB20  W/A=7F766500"
  2) Find the nearest "CVPL" eyecatcher.
  3) The CVSTAT is a one-byte field in the CVPL +x'7'.
  4) The failing volume's UCB address is in the CVPL +x'C'.
  .
  Cross System Sharing Considerations:
  .
  VTOC corruption is frequently caused by improper cross system
  serialization.  Some things to watch out for:
  .
  1) All systems sharing a dasd device must gen the device with
     FEATURE=SHARED.  Double check that this was done correctly
     by checking the UCBRR bit (x'20) in the UCB + x'11'.  If
     this bit is off, IOS will not issue the CCW for the hardware
     reserve.  The FEATURE=SHARED parameter must be coded on the
     IODEVICE statement in the MVSCP.
  .
  2) If BUILDIX is being run, the volume must be offline to all
     other sharing systems.
  .
  3) If DFDSS Defrag was cancelled, the VTOC may be left in an
     unknown state.  The Defrag should be rerun.
  .
  4) If hardware reserves are being changed to enqueues, then the
     enqueue with major name SYSVTOC must be propogated to all
     sharing systems.
  .
  5) Improper dataset serialization can also cause VTOC
     corruption.  Users should verify that SYSDSN enqueues are
     propogated to all sharing systems.  Temporary datasets with
     a high level qualifier of SYS9 are often the cause of VTOC/
     index mismatches if SYS9 datasets are excluded from SYSTEMS
     enqueues.  Also, be aware of any space management products
     running from a sharing system.  Most space management
     products rely on a SYSDSN enqueue.
  .
  6) If MVS is running as a guest under VM, make sure the volumes
     are defined as shared to VM.
  .
  IEC604I VTOC CONVERT ROUTINE ENTERED ON dddd,volser,DIRF
  IEC602I VTOC NOT CONVERTED ON dddd,volser,0,(EXTENT=cchh,
          DSCB=cchhr-cchhr
  .
  Steps for resolving overlapping extent conditions ( IEC602I )
  .
  1> Obtain an IEHLIST of the volume
  2> Review the CCHH extent info from the IEC602I message and
     compare it to the vtoc listing.
   > The DSCB=cchhr-cchhr specifies a range of DSCB addresses and
     one of the DSCBs which contains the same track allocation,
     will reside within this range.
   > The EXTENT=cchh indicates the 1st track which appears to be
     multiply allocated.  This EXTENT value itself could be within
     a low/high CCHH range(s), therefore doing a search on this
     exact EXTENT value in the IEHLIST output may not result in a
     direct hit.
  3> Once the overlapping datasets have been identified, delete or
     move off any dataset which resides on the volume at same CCHH
     location.
  4> Allocate a data set to remap the free space.  If there are
     still overlapping extents, another IEC602I will be issued.
     Follow the above procedure to move the data sets with the
     overlapping extents.
  5> Repeat this process until the IEC602I is no longer received
     when allocating a data set.
     If the allocation is successful, only the IEC604I message
     will be received ( not the IEC602I ).
  6> Rebuild the index via ICKDSF BUILDIX.
  7> If the above process does not work, then do a logical dump of
     the volume by datasets, reinit it, and then do a logical
     restore of the volume to rebuild the index.
  8> Zapping the DIRF bit off is not recommended because this
     would prevent one from allocating any datasets on the volume.
  .
  MSGIEC606I ABEND18B MSGIEC604I MSGIEC602I MSGIEC608I MSGIEC603I
  MSGIEC608I IEC608I Also see II04986 .
  

Local fix

• Run BUILDIX to re-index the volume.
  

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels