Getting space used/allocated for many datasets?

JPVRoff · Posted: Mon Apr 15, 2019 12:35 pm

Hi,

Within Rexx, we normally use IGGCSI00 to obtain catalog info for many datasets (as it's quicker than moth other methods).

But for one particular use (where we want to migrate datasets at the end of a batch run to save on DASD usage) I've had to rely on LISTDSI up to this point. Simply because the requirement was only to migrate those datasets bigger then a certain size. This is twofold, it means that we don't tie up HSM with thousands of requests to migrate small datasets, yet we also manage to save a lot of DASD space after each batch run.
Now LISTDSI is a wonderful Rexx function for one or two or ten files. But when we're looking through 5-10,000, the small amount of time it takes to allocate and deallocate each dataset for each LISTDSI starts to become a very significant piece of time.

Question is, is there any other way to find how much space is allocated or used by PS/PO datasets without having to allocate them?

enrico-sorichetti · Posted: Mon Apr 15, 2019 1:20 pm

use something like

expat · Posted: Mon Apr 15, 2019 2:49 pm

I have used DCOLLECT in the past for things like this, the records are pretty easy to understand and work with.

Willy Jensen · Posted: Mon Apr 15, 2019 5:46 pm

If you know which disk(s) the datasets are on then I will recommend the VTOC command from Use [URL] BBCode for External Links file 112. The command will scan disks based on volser prefix, or all which will be a bit too much at most sites, and filter on datasetname, used space and more. The generated list is easily postprocessed.

vasanthz · Posted: Mon Apr 15, 2019 11:02 pm

DCOLLECT D type records have this information. I can provide a working code if you have SAS-MXG at your shop.

JPVRoff · Posted: Wed Apr 17, 2019 3:40 am

Thanks you for the suggestions.
I'll have a go at DFDSS first, as it doesn't involve downloading anything (financial institutions are so fussy about that...sarcasm) and I've got a few macros that pull info from DFDSS output.
I might have a CBT from an earlier time on my 'home' LPAR, so if I'll try to have a look at both VTOC and DCOLLECT.

Pedro · Posted: Wed Apr 17, 2019 9:11 pm

I would consider also using the 'modified' date. If a data set has not been updated since your last check, then just ignore it.

steve-myers · Posted: Wed Apr 17, 2019 10:05 pm

sergeyken · Posted: Fri Apr 19, 2019 7:36 pm

There are only 3 date fields stored in DSCB block of VTOC.

For some reason the last update date is not maintained...

steve-myers · Posted: Fri Apr 19, 2019 7:58 pm

There is NO last modified date field in the format 1 DSCB. Period. End of story. There never has been.

There is one bit that notes the data set has been modified. Obviously that is not a date. This bit is maintained for storage management products like HSM.

The YDD date data segeyken mentions is 3 bytes of binary data. The first byte is the year, from 1900. 2019, for example, is 77, or 119 in decimal. The next two bytes are the day of the year. April 19 2019 (today, in other words) is 77006D.

Pedro · Posted: Sat Apr 20, 2019 10:06 am

JPVRoff · Posted: Thu Aug 29, 2024 6:53 am

Pete Wilson · Posted: Thu Aug 29, 2024 1:33 pm

Seems to me this could be managed by DFHSM naturally with appropriate MGMTCLAS's set up. If it is the same sets of data you're manually migrating every time then perhaps they need a specific MGMTCLAS's assigned that would do early migration as part of the normal migration cycle.

DFHSM already selects data to Migrate (or Expire) during Primary Space Management based on GDG status, size descending and last ref date/create date etc to minimise the amount of data it has to move to reach the volumes low free-space threshold anyway. So best to leave it to do that once the MGMTCLAS's are set up correctly.

Or if they're being migrated to ML2 anyway why not just write the QSAM ones direct to Tape and avoid the big DFHSM CPU usage overhead altogether?