Also, DFHSM doesn't need to be a high priority task. It will always be I/O constrained, not CPU. Well-tuned migration rules should prevent recall seriously impacting producton for. I run EXPIREBV twice, everyday.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Hervey Martinez Sent: Friday, August 23, 2013 12:23 PM To: [email protected] Subject: Re: DFHSM expire processing We run EXPIREBV only on weekends and we let it run all day long along with all HSM functions and have never had an issue. We've been running this way for several years. Regards, Hervey -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Michael Bieganski Sent: Friday, August 23, 2013 1:05 PM To: [email protected] Subject: DFHSM expire processing Hi, We have four lpars, running zOS 1.13 and use dfhsm. On 3 of the lpars, expirebv is always held. Every morning at 7:30,automation issues this command on just one of our four lpars: HSEND EXPIREBV NONSMSVERSIONS(DBU(5) CATALOGEDDATA(50) - UNCATALOGEDDATA(0)) EXECUTE RESUME and at 17:00..this is issued: HSEND HOLD EXPIREBV to stop it. So we only get less than 10 hours of expirebv processing. We've seen the size of hsm steadily growing and looked to see if the 10 hours of expirebv is not keeping up. I issued an "HSEND REPORT DAILY FUNCTION(BACKUP)...." for yesterday, Aug 22nd and see this: HSM FUNCTION BACKUP DAILY BACKUP 0035945 DELETE BACKUPS 0028811 So if that day is typical, it created approx 7,100 more backups than it deleted....thats going to add pound-age over time. However, what I don't understand is that in going into HSM's baklog for yesterday, for the only lpar that has an 'not-held' expirebv. I see doing a find on ARC0734I ACTION=EXBACKV that I only get 4,748 hits. Since we also have ABARS, that seems like a very small percentage of expirebv's. Does expirebv processing have a lower priority in hsm so it creeps along slowly? The previous storage admin set up the 10 hour limit of expirebv processing with those 07:30-17:00 hours. All I can surmise is perhaps he didn't want any expirebv processing while automation was doing cds backups (at 07:00 and at 17:30), and perhaps didn't want them using cycles when the primary and secondary management kicks in around 18:00. Do any of you hsm'ers also restrict the hours of your expirebv'ing so that it doesn't run while cds backups, primary/secondary mgmt is running? If HSM is indeed growing hefty because it is creating more backup dsns than its deleting, other than going through management classes with a machete, all I can think of to stop the expansion is to give expirebv more hours....but if we only get around 4k exbackv commands per day, I don't think we'd ever catch up. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
