| View previous topic :: View next topic |
| Author |
Message |
BigDaddy Beginner
Joined: 05 Nov 2004 Posts: 18 Topics: 5 Location: AMERICA
|
Posted: Thu Jun 09, 2005 8:42 am Post subject: listcat record count not matching actual record count |
|
|
I had a vsam file that hit high rba in our nightly process. I renamed the file and allocated a new file and reloaded it. Just as a safety check I ran a listcat on the old file to verify the total number of records matched what I copied to the new file. To my suprise they did not match. The listcat had 1,640,681 for the record count and I copied 1,666,163 to the new file.
Any ideas would be helpful. I can provide listcat if needed.
thanks |
|
| Back to top |
|
 |
kolusu Site Admin

Joined: 26 Nov 2002 Posts: 12401 Topics: 75 Location: San Jose
|
Posted: Thu Jun 09, 2005 9:21 am Post subject: |
|
|
BigDaddy,
As far as I know LISTCAT listing only shows information from the catalog has for the vsam cluster in question. Note that the record count field is incremented only when the VSAM cluster is properly closed after an update session. . So your counts may not be accurate.
For accurate results, I would like to use one of the examples shown here
http://www.mvsforums.com/helpboards/viewtopic.php?t=7&highlight=count
Btw is the vsam cluster a KSDS?
Hope this helps...
Cheers
kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
| Back to top |
|
 |
BigDaddy Beginner
Joined: 05 Nov 2004 Posts: 18 Topics: 5 Location: AMERICA
|
Posted: Thu Jun 09, 2005 1:05 pm Post subject: |
|
|
Yes it is a ksds file. I was thinking the same thing about it not closing properly after the abend so I did a VERIFY on the file just for kicks but listcat info did not change. I have run a few in house utilities to count the records and thought the open and close of those utilities would have fix the listcat info. I will try sort to see what it gives me for a record count. I will let you know what I find.
thanks for the info |
|
| Back to top |
|
 |
kolusu Site Admin

Joined: 26 Nov 2002 Posts: 12401 Topics: 75 Location: San Jose
|
Posted: Thu Jun 09, 2005 1:22 pm Post subject: |
|
|
Bigdaddy,
You also need to make sure that you are looking at the right field in the listcat listing. Listcat listing for a KSDS will have two REC-TOTALS fields. one from the data component and other from the index component. You need check the the field under Data component which will be the total no: of records in the cluster.
Kolusu _________________ Kolusu
www.linkedin.com/in/kolusu |
|
| Back to top |
|
 |
BigDaddy Beginner
Joined: 05 Nov 2004 Posts: 18 Topics: 5 Location: AMERICA
|
Posted: Fri Jun 10, 2005 7:39 am Post subject: |
|
|
Kolusu, thanks for the info. I ran sort and the counts still do not match. I will have our dasd people take a look at it. Here is the listcat.
| Code: |
DATA ------- BCSVC4.MASTER.WEIRD.DATA
IN-CAT --- CATALOG.HPLEX.PROD.VSAM03
HISTORY
DATASET-OWNER-----(NULL) CREATION--------1995.326
RELEASE----------------2 EXPIRATION------0000.000
ACCOUNT-INFO-----------------------------------(NULL)
PROTECTION-PSWD-----(NULL) RACF----------------(NO)
ASSOCIATIONS
CLUSTER--BCSVC4.MASTER.WEIRD
ATTRIBUTES
KEYLEN-----------------9 AVGLRECL------------1020
RKP--------------------0 MAXLRECL------------1020
SHROPTNS(2,3) SPEED UNIQUE NOERASE
ORDERED REUSE NONSPANNED
STATISTICS
REC-TOTAL--------1640681 SPLITS-CI-------------22
REC-DELETED------------0 SPLITS-CA------------543
REC-INSERTED------197906 FREESPACE-%CI----------0
REC-UPDATED-----77031458 FREESPACE-%CA---------10
REC-RETRIEVED--691570482 FREESPC--------402440192
ALLOCATION
SPACE-TYPE------CYLINDER HI-A-RBA------2093875200
SPACE-PRI------------110 HI-U-RBA------2093875200
SPACE-SEC------------100
VOLUME
|
And here is the sort.
| Code: |
RECORD TYPE=FB
SORT FIELDS=COPY
WER164B 8,876K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 1,237,872 BYTES USED
WER146B 20K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I SORTIN : RECFM=F ; LRECL= 1020; CISIZE = 4096
WER110I SORTOUT : RECFM=FB ; LRECL= 1020; BLKSIZE= 27540
WER410B 7,848K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER410B 0 BYTES RESERVE REQUESTED, 222K BYTES USED
WER209B 15 PRIMARY AND 360 SECONDARY SORTOUT TRACKS ALLOCATED, 240 USED
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
WER416B VSAM WAS USED FOR SORTIN
WER416B SORTOUT: EXCP'S=2257,UNIT=3390,DEV=2514,CHP=(72787A505660666C
WER054I RCD IN 1666163, OUT 1666163
WER169I RELEASE 1.1B BATCH 0385 TPF LEVEL 3A
WER052I END SYNCSORT - RBCSRTQM,SORTQ01,,DIAG=AC01,6ACE,8026,20CC,E4DA,
|
I will let you know what I find out. |
|
| Back to top |
|
 |
bablack Beginner
Joined: 04 Dec 2002 Posts: 71 Topics: 0 Location: Little Falls, NJ
|
Posted: Mon Jul 11, 2005 1:51 pm Post subject: |
|
|
VSAM statistics have never been reliable. There was just a long discussion in the IBM-MAIN forum about this. If VSAM files are opened and closed normally, and a step using them never ABENDs, then they are probably close (but may not be exact). If a step using a VSAM file ABENDs, then all the statistic updates for that step are lost forever. _________________ Bruce A. Black
Senior Software Developer
Innovation Data Processing |
|
| Back to top |
|
 |
BigDaddy Beginner
Joined: 05 Nov 2004 Posts: 18 Topics: 5 Location: AMERICA
|
Posted: Tue Jul 19, 2005 12:57 pm Post subject: |
|
|
Just thought I would update what I found. Someone changed our nightly run jcl to use batch lsr pools with deferred write for the step that abended. Some of the writes were not commited because of the abend which I think explains why the record count got out of wack.
thanks for the info everyone |
|
| Back to top |
|
 |
|
|
|