You left out some key information from the first two lines of the IEHLIST
output.

     Your previous (and subsequent) ISPF data states that 12 extents are
allocated.  This IEHLIST output shows only 3 with tracks.  It then shows 9
additional extents with no tracks.  That explains the 12 extents but only
3,222 tracks allocated.

     ISPF is apparently computing the Current utilization from the LAST BLK
field which shows below as 12595-2.  This explains the 12596 tracks value in
ISPF.

     I don't know where ISPF gets the Used extents value.  I expect it steps
through the extents adding up the number of tracks in each until either it
hits a zero extent (as here) or exceeds the LAST BLK value.  That would
explain the 3 extents value in ISPF.

All in all, it looks as if someone stepped on your Format-3 DSCB.  You can
confirm this by dumping the VTOC and comparing the Format-1 and -3 entries
of a known good dataset with more than three extents and the corresponding
ones for this dataset.

If this is fact the case, the next issue to worry about is: Are the missing
extents present in the free space pool?  I used a home-grown DASD mapping
tool to verify that each track on a DASD was covered by exactly one extent
(either F1, F3, or free space/F5).  (There probably is a similar tool on the
CBT tape.  Beware of older versions that don't support the new VTOC
formats.)  If the missing extents are not in the free pool, then the data
may still be valid since no one should try to write on those tracks.  You
can then edit the F3 DSCB to incorporate the missing 9 extents and possibly
recover the data.  If the missing extents are in the free pool, you probably
will need to recover the dataset from a backup that was made prior to the F3
corruption.

:>: -----Original Message-----
:>: From: IBM Mainframe Discussion List [mailto:[email protected]] On
:>: Behalf Of esmie moo
:>: Sent: Thursday, April 26, 2012 10:27 AM
:>: To: [email protected]
:>: Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
:>: ALLOCATION.
:>:
:>: Hi Tom,
:>:
:>: I ran the IEHLIST with FORMAT option and this is what it tells me:
:>:
:>: SMS.NPE   LRECL  KEYLEN  INITIAL ALLOC  2ND ALLOC    EXTEND     LAST
:>: BLK(T-R-L)  DIR.REM  F2 OR F3(C-H-R)  DSCB(C-H-
:>:
:>:
:>:
:>:          R)
:>:                                0                        TRKS
:>:             1074                                     12595   2     2176
:>:                     0           1  20      0   1  18
:>:  EATTR
:>:
:>:  NS
:>:
:>: 0            EXTENTS  NO  LOW(C-H)   HIGH(C-H)    NO  LOW(C-H)   HIGH(C-
:>: H)    NO LOW(C-H)   HIGH(C-H)
:>:                                     0      1137      9       1209  2
:>:       1      1209      3     1280      11      2  1280     12         13
:>: 52  5
:>:                                     0             0      0            0
:>:
:>: 0          0            0      0            0      0        0        0
:>:     0               0  0
:>:                                     0             0      0            0
:>:
:>: 0          0            0      0            0      0        0        0
:>:     0               0  0
:>:                                     0             0      0            0
:>:
:>: 0          0            0      0            0      0        0        0
:>:     0               0  0
:>:                                  ----ON THE ABOVE DATA SET,THERE
:>: ARE       9374 EMPTY TRACK(S)
:>: 0
:>:
:>: I am not sure if this confirms the information of ISFP  .  Could you
:>: take a look please?
:>:
:>:
:>: ________________________________
:>: From: Tom Marchant <[email protected]>
:>: To: [email protected]
:>: Sent: Thursday, April 26, 2012 12:51:11 PM
:>: Subject: Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT
:>: ALLOCATION.
:>:
:>: On Thu, 26 Apr 2012 09:24:10 -0700, esmie moo wrote:
:>:
:>: >Good Morning Gentle Readers,
:>:
:>: >The dsn has the following allcation but I am not sure how to
:>: >correct the problem.   I have never seen before where the
:>: >current utilization is larger than the allocation.
:>:
:>: I've never seen that either.  Before attempting any correction,
:>: I  would use IEHLIST to obtain a LISTVTOC FORMAT and a
:>: LISTVTOC DUMP for the data set.  I wonder if ISPF is reporting
:>: the information correctly.  If the LISTVTOC confirms the
:>: information that ISPF shows, I'd recommend calling the IBM
:>: support center.
:>:
:>: --
:>: Tom Marchant
:>:
:>: ----------------------------------------------------------------------
:>: For IBM-MAIN subscribe / signoff / archive access instructions,
:>: send email to [email protected] with the message: INFO IBM-MAIN
:>:
:>: ----------------------------------------------------------------------
:>: For IBM-MAIN subscribe / signoff / archive access instructions,
:>: send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to