So - ODM has replaced the previous functions in HSM. However, there are some pools that are small on purpose (like DB2 Offload Log Pool). The only time we have issues with it - someone decides they need to run an analyze on the last month of DB2 logs. That can recall a lot of logs and fill up the pool very quickly.
Otherwise, we try to keep abour 25% free space in most pools. We rarely run into overflow or Spill requirements. Lizette -----Original Message----- >From: Ronald Kristel <[email protected]> >Sent: Apr 24, 2017 12:43 PM >To: [email protected] >Subject: Re: Who Needs Spill/Overflow Pools anymore? > >What about 'in case of emergencies?'. > >(I think) almost all our storagegroups are directed to one substantial big >overflow storagepool, _just_ for occurances where for whatever reason, >something starts to heavily use a specific storage pool. > >I agree, it's not very efficient to have a massive amount of disks spinning >without holding any data most of it's lifetime. However, this has classified >more favorable then facing a time period with space abends. > > >From my experience, I try to over-provision many of the storagepools with a >certain amount, so that overflowing does not happen on a regular basis. And I >monitor/analyse the growth of these storagepools. (And act on adding more >'MOD54's' when needed). > > >I think it really depends on what is being stored aswell. Some data is not >really eligible to be migrated if it's (for example) required for online >processing. However, data that does not need to meet any criteria in terms of >'response time' can easily be migrated to save DASD. > > >I was just wondering, are you using HSM ODM to migrate data? > > >Ronald Kristel >NL > >________________________________ >From: IBM Mainframe Discussion List <[email protected]> on behalf of >Lizette Koehler <[email protected]> >Sent: Monday, April 24, 2017 6:51:38 PM >To: [email protected] >Subject: Who Needs Spill/Overflow Pools anymore? > >This is just a discussion topic (Thank you Skip for making me think about this >;-O) > >In the past we needed to have them as we were tight on storage. > >But today, is that still the case. What is a good reason to either have or >don't have SPILL/OVERFLOW pools when we can just add more storage to the pool. > >I can add a MOD54 to a pool but that mod54 is not full until I use up all of >the >allotted storage to the MOD54 in the storage array. So the storage array can >be >over provisioned until I need to go and get management to buy more physical >storage. > >Do I lose anything by having datasets "spill" over to a different pool that may >not have the same protection as the one it is in? HSM Backup, Dump, Cleanup >processes? Or are there other considerations. > >Just asking a question or two. > >So basically, why use SPILL/OVERFLOW when you can just add dasd, or do lots of >migration? > >We have the automation tool set up to monitor the pools and if they get too >full, then start migration on the datasets in that pool. No manual >intervention >required. > > > >DFHSM and DFSMS do not think like humans when it comes to dataset management. >So there a need to out maneuver them to make datasets go where we want. > > > > >Lizette Koehler >statistics: A precise and logical method for stating a half-truth inaccurately > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
