Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Forum Index
 
Register
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
CICS VSAM file max volumes

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
socker_dad

Active User


Joined: 05 Dec 2006
Posts: 171
Location: Seattle, WA

PostPosted: Tue Aug 20, 2019 1:28 am    Post subject: CICS VSAM file max volumes
Reply with quote

This is a basic question, but one we're struggling with, so I beg patience up front!

We are experiencing slow performance in one of our CICS regions and one of the messages the log file keeps getting is this:
Code:

AL$0001I CICP6235, CICP6, LC4070IB, , MIPS235.P.C4070IB.DATA.VSAM
AL$ESD1E DATA SET IS ON MAXIMUM VOLUMES TERMINATING RECOVERY


I can see that this is a KSDS Ext-Addr file in File-Aid, but I'm not sure what else I should be looking for. The Current space allocated/used ratio is 69% (38,985 tracks/26,821 tracks), which doesn't seem like a bad ratio. The KSDS Index is 125 tracks. The total Data Records is 423,867, but the Retrieved Data Records is 14,226,052.

One thing I noted is that this VSAM file gets copied to a flat file daily, but is never deleted/redefined/reloaded like other VSAM files that I've seen. Could that be the source of the performance issue?
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8499
Location: Dubuque, Iowa, USA

PostPosted: Tue Aug 20, 2019 2:39 am    Post subject: Reply to: CICS VSAM file max volumes
Reply with quote

I'd want to see a LISTCAT for the data set, and I'd be looking particularly at things like CI splits, CA splits, number of volumes in use, number of candidate volumes, number of extents per volume, HI-A-RBA and HI-U-RBA. The error message number you quoted is NOT a standard IBM error message number, so one place to start would be to find out what is generating the message and what that software says about that particular error message.
Quote:
The Current space allocated/used ratio is 69% (38,985 tracks/26,821 tracks)
This may be a completely misleading number -- if the data set needs to add records (either at the end of the data set or through a split), the LISTCAT values may indicate that such an extension is not possible for one reason or another.

One quick-and-easy possible solution would be to unload the VSAM, delete / define it, and reload it. Comparing the LISTCAT from before this is done to the LISTCAT after this is done should shed some light on the situation.
Back to top
View user's profile Send private message
socker_dad

Active User


Joined: 05 Dec 2006
Posts: 171
Location: Seattle, WA

PostPosted: Tue Aug 20, 2019 3:02 am    Post subject:
Reply with quote

The delete/define/reload sounds like the best to me as well. I'll work on getting permission for it. In the meantime:

Code:

Data Component Information:                       Current Allocation Options:
 Device type:             3390                     Load option:          SPEED
 Organization:            KSDS  EXT-ADDR           Write check:             NO
 KSDS key length:           14                     Buffer space:         18432
 KSDS key location:          0                     Erase on delete:         NO
 Average record size:      600                     Imbedded index:          NO
 Maximum record size:    16309                     Replicated index:        NO
Allocated Space:    Unit    Primary  Secondary     Reuse option:            NO
 Data:         CYLINDERS        599         50     Share option:           2-3
 Index:           TRACKS         29          3     Spanned records:        YES
Dataset Date Information:                          Key ranges present:      NO
 Creation date:         28/07/2019                 AIX-unique keys:
 Expiration date:                                  AIX-upgrade:
 Modification date:     18/08/2019
 Modification time:     01:00 AM  GMT              Owner ID:


CLUSTER   - MIPS235.P.C3800IA.DATA.VSAM                  Storage:     CICSPROD
                                                         Data:        VSAM
                                                         Management:  NOMIG
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - -
Current Space:      ALLOCATED    USED             Data Records
       Tracks:          38985   26821 (  69 %)      Total:            423,867
      Extents:             15       5 (  33 %)      Deleted:                0
   KSDS Index:            125       -               Inserted:          129174
                                                    Updated:                0
Allocation Type:               UNIQUE               Retrieved:       14226052
RRDS: Max record number:            0      KSDS: Index Records:          2522
- - - - - - - - - Current Reorganization Information - - - - - - - - - - - - -
                        INDEX       DATA   Index Statistics:
Number of CA splits:        9       1074    Number of levels:               3
Number of CI splits:     1074      31741    Entries per section:            9
CI Size:                 2048       8192    First sequence-set RBA:         0
Number of CIs/CA:          21         90   Volume Information:
Free CIs/CA:                0         13    Physical record size:        8192
Percent free CIs/CA:        0         15    Records per track:              6
Percent free bytes/CI:      0         25    Tracks per CA:                 15


DATA COMPONENT: 'MIPS235.P.C3800IA.DATA.VSAM.PRIME'
  Volume Allocations:
   1. CP9106  2. *       3. *       4. *       5. *
   6. ______  7. ______  8. ______  9. ______ 10. ______
  11. ______ 12. ______ 13. ______ 14. ______ 15. ______
  16. ______ 17. ______ 18. ______ 19. ______ 20. ______
  21. ______ 22. ______ 23. ______ 24. ______ 25. ______
  26. ______ 27. ______ 28. ______ 29. ______ 30. ______
  31. ______ 32. ______ 33. ______ 34. ______ 35. ______
  36. ______ 37. ______ 38. ______ 39. ______ 40. ______
  41. ______ 42. ______ 43. ______ 44. ______ 45. ______
  46. ______ 47. ______ 48. ______ 49. ______ 50. ______
  51. ______ 52. ______ 53. ______ 54. ______ 55. ______
  56. ______ 57. ______ 58. ______ 59. ______


INDEX COMPONENT: 'MIPS235.P.C3800IA.DATA.VSAM.INDEX'
  Volume Allocations:
  1. CP9106  2. *       3. *       4. *       5. *       6. ______  7. ______


I didn't see any stats on # candidate volumes, extents per volume, HI-A-RBA and HI-U-RBA. I was wondering about that error message: I hadn't seen one like that before.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8499
Location: Dubuque, Iowa, USA

PostPosted: Tue Aug 20, 2019 6:53 am    Post subject:
Reply with quote

What you posted isn't really a LISTCAT, but it has almost all the relevant data anyway.
Code:
DATA COMPONENT: 'MIPS235.P.C3800IA.DATA.VSAM.PRIME'
  Volume Allocations:
   1. CP9106  2. *       3. *       4. *       5. *
The * means that it is a candidate volume. So the data set is on one volume. Splits don't have the performance impact that they did when disks were physically moving read/write heads from track to track, but 31741 CI splits and 1074 CA splits definitely means your data is scattered (especially considering the data set is only 3 weeks old). In a batch application, that usually doesn't matter but it can mean a performance hit to a CICS application, depending upon the read method (sequential or direct). Another factor to consider is the spanned records -- I don't recall ever hearing if spanned record access would be slower than non-spanned records, but I certainly think it is possible (since for the spanned records, 2-3 data CI have to be read not 1).

With a 25% CI freespace, you are getting about 10 records per CI based on the average record length, and 900 per CA. The data requires just over 540 cylinders and the used space is 1789 cylinders. I definitely think an unload, delete / define, reload is recommended. It will probably help the CICS performance as well, although CICS performance depends upon so many factors that it is hard to say for sure.
Back to top
View user's profile Send private message
Rohit Umarjikar

Senior Member


Joined: 21 Sep 2010
Posts: 2299
Location: NY,USA

PostPosted: Tue Aug 20, 2019 8:40 pm    Post subject:
Reply with quote

Quote:
One thing I noted is that this VSAM file gets copied to a flat file daily, but is never deleted/redefined/reloaded like other VSAM files that I've seen.
We have same process today unloading to PS everyday but I shall check if we do deleted/redefined/reloaded.

This might clue you more options to look for.
CICS VSAM and file control: Performance and tuning

Since, LSR/NSR/BLSR consideration changes batch performance, So that might also impact in online and can be investigated accordingly.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts File transfer issue with end of line ... VINAY PALLELA TSO/ISPF 4 Thu Nov 14, 2019 12:01 am
No new posts File compare, where file has header a... VINAY PALLELA SYNCSORT 8 Thu Nov 07, 2019 5:05 pm
No new posts Cics storage violation Venkata Ramayya CICS 10 Thu Nov 07, 2019 12:45 am
No new posts CICS Web Services configuration question SickPup404 CICS 17 Mon Nov 04, 2019 9:56 pm
No new posts OMIT first and last column of a pipe-... karthikb_itpro DFSORT/ICETOOL 1 Fri Nov 01, 2019 8:24 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us