I was asked to create a rule which would run on the first of the month, every month. The time doesn't matter. Based on what I am reading in the manuals it appears that you can code an Event Specifier which does specify the first of the month but it seems that you MUST specify a year within the todsepc. Thus, each year the rule's event specifier would need to be changed for the next year, an obvious annoyance. In addition, the event specifier is limited to 10 specifications meaning that you could only get 10 months and not 12. So this is a no go. My next thought was to write a rule that would fire at midnight every day and then use logic to check the date. The rule would fire off 365(6) times a year but compared to some of our other rules, this is a drop in the bucket. My question is, is there a way to specify a rule to fire on a particular day of the month (1st, 15th, 30th, etc.) without needing to fire it off every day at midnight and checking the date?
I *think* this would work (split into two rules because you can't specify more than 10 TOD specs in one rule):
)TOD 2015/01/01 00:00, 52 WEEKS 1 DAY
2015/02/01 00:00, 52 WEEKS 1 DAY
2015/03/01 00:00, 52 WEEKS 1 DAY
2015/04/01 00:00, 52 WEEKS 1 DAY
2015/05/01 00:00, 52 WEEKS 1 DAY
2015/06/01 00:00, 52 WEEKS 1 DAY
)TOD 2015/07/01 00:00, 52 WEEKS 1 DAY
2015/08/01 00:00, 52 WEEKS 1 DAY
2015/09/01 00:00, 52 WEEKS 1 DAY
2015/10/01 00:00, 52 WEEKS 1 DAY
2015/11/01 00:00, 52 WEEKS 1 DAY
2015/12/01 00:00, 52 WEEKS 1 DAY
Best I can come up with.
Or just fire a rule EVERY day (at the time needed), and do a test on date being 1st day of month (=1) if not the just return..
That's really easy, with practically no overhead.
)TOD 00:10,1 DAY
if word(date('N'),1)<>'1' then return
....rest of code to execute on 1st day of month ...
Yeah that is one way to do it and it is an option. The only issue is that you would still need to update the year on the todspec come the New Year. Not a big deal until someone forgets and seeing as how these would run only once a month and would theoretically only be updated once a year, forgetting about it would not be hard to do. Worst case scenario would be a CA-OPS "guy" leaving in the middle of the year and no one knowing those rules needed updated. Anyway, this is still a valid solution, albeit not without a caveat. I fear that this may be the only other solution other than running it everyday and checking the date. Any other ideas are appreciated.
That is basically what I have coded for now. I was looking for a way to do it without using the logic to check the day. That is I'd like to embed that logic within the todspec.
I *like* that idea: imbed the logic in the TODSPEC. Code a function TODSPEC like:
and CalcMyDate could be something like:
parse value date('S') with yyyy 5 mm 7 dd
firstofmonth = yyyy+(mm%12),
and it would run each time the rule fires to establish a new TODSPEC for the next fire time.
I don't think you'd need to update the spec each year. In my experience the date there is treated as a base date. We have rules running fine with specs like this one:
)TOD 97/01/29 02:02:00,04:00:00
Obviously you'd want to monitor it closely, at least through a leap year cycle. Leap year is the year I'd be worried about most.
True, but the "forgetting" could easily be rectified by having the last "execution" of the year generate some type of alert / notification / whatever to draw awareness that the TOD needs tweaking.
It could take on the form of generating a page to the automation support group, generating some type of problem resolution system alert, sending a TSO message, prompting Operations to notify
someone who supports automation, or a combination of these. I guess if you really want to get wild, you could try making the timer dynamic and self-replicating. You would obviously need to have
something in place to re-drive the process should you come out of an IPL
I see now. The rules only start in 2015, each event specifier's interval is 52 weeks and 1 day. So no, you shouldn't have to worry about updating the years. Leap year would indeed be the gotcha in that situation though.