IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Getting space used/allocated for many datasets?


IBM Mainframe Forums -> CLIST & REXX
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 45
Location: Melbourne, Australia

PostPosted: Mon Apr 15, 2019 12:35 pm
Reply with quote

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?
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10886
Location: italy

PostPosted: Mon Apr 15, 2019 1:20 pm
Reply with quote

use something like

Code:
 000005 //DSS     EXEC PGM=ADRDSSU,REGION=0M,
 000006 //             PARM='TYPRUN=NORUN'
 000007 //SYSPRINT  DD SYSOUT=*
 000008 //SYSIN     DD *
 000009   DUMP -
 000010        DATASET( -
 000011                 INCLUDE( -
 000012                          XXXXXX.** -
 000013                        ) -
 000014                 BY( REFDT LT (*,-365) ) -
 000015               ) -
 000016        OUTDDNAME(OUT)
 000017 //OUT       DD DUMMY



change the

Code:
BY( REFDT LT (*,-365) )


to the appropriate construct

DFDSS filtering capabilities are quite sophisticated
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales

PostPosted: Mon Apr 15, 2019 2:49 pm
Reply with quote

I have used DCOLLECT in the past for things like this, the records are pretty easy to understand and work with.
Back to top
View user's profile Send private message
Willy Jensen

Active Member


Joined: 01 Sep 2015
Posts: 734
Location: Denmark

PostPosted: Mon Apr 15, 2019 5:46 pm
Reply with quote

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.
Back to top
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1744
Location: Tirupur, India

PostPosted: Mon Apr 15, 2019 11:02 pm
Reply with quote

DCOLLECT D type records have this information. I can provide a working code if you have SAS-MXG at your shop.
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 45
Location: Melbourne, Australia

PostPosted: Wed Apr 17, 2019 3:40 am
Reply with quote

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.
Back to top
View user's profile Send private message
Pedro

Global Moderator


Joined: 01 Sep 2006
Posts: 2593
Location: Silicon Valley

PostPosted: Wed Apr 17, 2019 9:11 pm
Reply with quote

I would consider also using the 'modified' date. If a data set has not been updated since your last check, then just ignore it.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Wed Apr 17, 2019 10:05 pm
Reply with quote

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

There is no such thing as a "modified date" data set attribute. There is a flag - mainly for storage management products such as HSM - to indicate that a data set has been modified since the last backup by the storage management product.
Back to top
View user's profile Send private message
sergeyken

Senior Member


Joined: 29 Apr 2008
Posts: 2140
Location: USA

PostPosted: Fri Apr 19, 2019 7:36 pm
Reply with quote

There are only 3 date fields stored in DSCB block of VTOC.
    - DS1CREDT - Creation date ('YDD'), discontinuous binary.
    - DS1EXPDT - Expiration date ('YDD'), discontinuous binary.
    - DS1REFD - Date last referenced ('YDD' or zero, if not maintained).

For some reason the last update date is not maintained... icon_cry.gif
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Fri Apr 19, 2019 7:58 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Pedro

Global Moderator


Joined: 01 Sep 2006
Posts: 2593
Location: Silicon Valley

PostPosted: Sat Apr 20, 2019 10:06 am
Reply with quote

Quote:
There is NO last modified date field in the format 1 DSCB


Sorry, I am not sure what I was thinking about.
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 45
Location: Melbourne, Australia

PostPosted: Thu Aug 29, 2024 6:53 am
Reply with quote

steve-myers wrote:
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.

I was just going over this when looking for another answer (or, at least, I think it's an old answer) when I saw this bit about the bit.

Interestingly, we've been having difficult to pin down issues with this bit. It appears that in some IAM files, this bit is not being set after an update. And you can guess what fun ensues when the file gets migrated. I know the best option would be not to migrate any of the files, but there's at least 16 regions of our software, plus unknown numbers of other regions, all on this one little LPAR.
One day someone will take it seriously...
Back to top
View user's profile Send private message
Pete Wilson

Active Member


Joined: 31 Dec 2009
Posts: 590
Location: London

PostPosted: Thu Aug 29, 2024 1:33 pm
Reply with quote

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?
Back to top
View user's profile Send private message
JPVRoff

New User


Joined: 06 Oct 2009
Posts: 45
Location: Melbourne, Australia

PostPosted: Mon Dec 02, 2024 9:19 am
Reply with quote

Pete Wilson wrote:
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?

Hi Pete,

I didn't see this before. In this particular site, we're a third-party provider on the clients' site, run by IBM in Latin America (unsure which actual country). So getting any changes made to our benefit is problematic.
Thanks for the suggestion, though.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CLIST & REXX

 


Similar Topics
Topic Forum Replies
No new posts JES datasets IO Error ABENDS & Debugging 3
No new posts Concatenate 2 input datasets and give... JCL & VSAM 2
No new posts Get RECORD LENGTH, allocated space of... CLIST & REXX 7
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts Allocated cylinders of a dataset DB2 12
Search our Forums:

Back to Top