Ok, this is the important information for me: there is no standard way to tell me, what I can get. Not the storage group volume, so what I could allocate, but what I actually have told the system I "want" to have (the actual UNIT= and SPACE= parameters). I just have decided, if there is no "automatism", to make a list of the few jobs, which are relevant to watch at (the others are quite "normal") and simply note the actual parameters. The rest (actual used, allocated, ...) I can get from PROC CONTENTS. So thanks for that expert view! Gerhard

(by the way: it's Erkki Korhonen, who has that questions actually!)

On Wed, 18 Apr 2007 11:03:04 +0200, Robert Bardos <bardos2@ANSYS.CH> wrote:

>Gerhard, > >neither of IDCAMS's commands LISTCAT or DCOLLECT respectively >provide a good enough answer. So some basics first: > >A multivolume SAS library can extend to a maximum of 59 volumes. >On each of these volumes it can occupy a maximum of 65535 tracks >(4369 cylinders). >This would mean some 3.8 million tracks. Or given a blocksize of >27648 a total of >213,805,578,240 bytes. > >Practical limits are usually encountered earlier. And there is >quite an amount of dependencies. Questions like: how many volumes >belong to the storage class? With how many candidate volumes has >the library been defined? To what degree are the volumes in that >storage class filled? ... > >Storage use tends to be dynamic, so an answer which was valid a >few minutes ago may be 'cold coffee' (as a German saying goes) by >now. Sadly there doesn't seem to be a standard batch method that >would display exactly the same information as can be obtained >through ISPF 3.4 (aka DSLIST). > >Third party tools like e.g. FDREPORT or CA-DISK [*1] may give a >better answer. So my best suggestion is to contact your local >storage admin group and ask them for a dedicated report. > >Well ... thinking of DCOLLECT again (had begun composing this post >the day before) you might come up with a pretty slick solution. >But this would involve some pretty heavy programming. (Idea here: >determine storage class, determine number of volumes in storage >class, determine free space in storage class, determine actual >dataset size and number of volumes/units used vs. number of >volumes/units definded etc. etc.) > > >Greetings > >Robert Bardos >Ansys AG, Zurich, Switzerland > >[*1] a sample report step using CA-DISK could look like this > >//STEP010 EXEC DMS <-- DMS or whatever your sysprogs named it >//SYSIN DD * > SCAN CATALOGS=<your_catalog> > SELECT DSN=(<hlq>.MICS.*.DAYS, > <hlq>.MICS.*.DETAIL, > <hlq>.MICS.*.MONTHS, > <hlq>.MICS.*.WEEKS, > <hlq>.MICS.*.YEARS) > REPORT MVD >/* >//* Hint based on experience: SCAN CATALOGS is significantly >//* faster than SCAN REALVOLS > > >> -----Urspr�ngliche Nachricht----- >> Von: SAS(r) Discussion >> [mailto:SAS-L@LISTSERV.UGA.EDU]Im Auftrag von >> Gerhard Hellriegel >> Gesendet: Dienstag, 17. April 2007 11:44 >> An: SAS-L@LISTSERV.UGA.EDU >> Betreff: zOS what is the max space available for a SAS library? >> >> >> Hi all your zOS freaks, >> maybe someone has a idea: we have very big SAS >> libraries with multi-volume and many extents. >> The data-volume is growing inside that library. >> We need to know, when we are close to a limit, >> means, how high is the space limit for a specific library. >> PROC CONTENTS returns only the current formatted blocks, >> which is not the space, zOS can allocate for that library. >> Maybe the FCB for the file can give us that information. >> Means: I would know the extents, which can be allocated and >> their max size. I know, that this is only half of the truth, >> because the space might not be available anyway, but better >> that knowing nothing. Does anyone know, how to get this? >> If it is not possible in SAS, maybe someone knows if >> that is provided by DCOLLECT? >> >> Please share your experience! >> >> Thanks for your input! >> Gerhard >>