> SCOPE=COMMON data spaces are like everlasting gobstoppers one should be > enough for anyone.
Not necessarily. Individual CADS can have significantly different attributes and usage patterns. In general you can probably get away with one for each unique set of attributes. I work hard to reduce the number of combinations, but at the end of the day, if you need CADS storage with special properties, (e.g. DREF or different keys) then that's what it takes. One of the issues I bump into is that we document the need for certain CADS and then customers profess surprise when a product can't start because they are up against the MAXCADS limit. It's really no big deal to increase MAXCADS prior to the next IPL but for some reason people are gun shy of it. Go figure. > You might take a list of all the TMON data spaces to ASG and raise an > issue with the use of multiple ones as causing you an outage to get it > increased. It will only get fixed if customers complain loud and long You might also want to ask the CICS guys why there are so many EYUxxxxx CADS and the FFST guys why there are so many of theirs and... oh never mind. My point is that "we" (software developers) are all guilty of abusing CADS resources. Its because its "easy" to use a CADS and "hard" to arrange to set up access for "SCOPE=ALL". Right now (TMON aside) it looks to me like IBM is the biggest abuser. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
