Greg,
I just put a copy of our exec up for you. It is at:
ftp://ftp.cit.cornell.edu/pub/special/adsm/server/daily.backup
This is a rexx exec. We use the Uni-Rexx product from The Workstation
Group.
This is basically what it does:
Each night, it is run from cron. It checks to see if a node has
been successfully backed up or not, and if not how many days have
elapsed since the last successful backup.
It checks the Contact field for the node. We use the contact field
to contain lots of information, and we format it in a particular way.
This can be seen from one of the Rexx functions which parses the
contact field. There are two fields that are relevant to this
particular exec. First, there is an indicator for how many days can
elapse without a successful backup before an e-mail notification will
be sent. Second, there is an e-mail address to send the mail to.
Possible values for the first field are:
-1 always send mail, even if the node has been backed up.
0 never send mail,
>0 send mail only if the node hasn't been backed up in N days.
Here is a sample for one of our nodes:
Contact: /CN=Paul
Zarnowski/$=U:R52-4700/N=1:psz1/CP=5-4757/CC=-
315 CCC/CM=psz1
You can see that each field is /var=value
/CN is the contact name
/$ is the account to charge
/N is the notification value and e-mail, separated by a colon (desc above)
/CP is the contact's phone
/CC is the contact's campus mail address
/CM is the contact's e-mail address (@cornell.edu is assumed)
A slash (/) is the escape character, so /CN=CIT//CR is really indicating
a contact name of "CIT/CR".
The logic used to determine whether a backup has occurred or not is
somewhat sophisticated. I believe you will find that many of the other
scripts that you get are not as sophisticated and take a simpler approach.
First, we use QUERY EVENT to determine whether the most recent scheduled
backup completed successfully or not. If it completed successfully, then
we decide that the system was successfully backed up at that time.
However, if the event does NOT show a completed backup (i.e., it was
missed or it failed), then we do a QUERY FILESPACE to determine the
the latest backup completion date/time for each filespace. This is
to catch users who perform manual backups and do not use the scheduler
(or perhaps they do, but didn't this time). We look at each filespace
and compare it against the N value (from the contact field). If any
filespace has not been backed up recently, then we send e-mail.
This is not perfect, but I think it is as close as we can get. We must
use the QUERY EVENT for the following reason: Users may have filespaces
in ADSM which they do not actively back up. We do not want to needlessly
send them e-mail about these filespaces, since it is clear that they did
not want them backed up. They control which filespaces they want to
back up using the DOMAIN option. However, if QUERY EVENT does not tell
us what we need to know, then we must resort to QUERY FILESPACE as the
next best indication. This is not perfect, as it may cause us to notify
someone about a filespace that didn't get backed up, but which they do
not care about. Unfortunately, we have no way of determining which
filespaces they care about and which they don't care about.
The format of the e-mail notification is very customized. Examples are
provided in the README file that is in the same directory as the
daily.backup rexx exec. Customizations include referring to filespaces
as "volumes" or "filesystems" depending on what type of system it is.
You can look at the Rexx exec to see what other customizations are done.
Some other comments:
If you use the contact field for your enhancements, please use it in
such a way that it can continue to be used for other things. Or, you
could add some additional fields for this.
In developing this code, I found that our users were pretty picky about
how the mailfile looked. I would strongly suggest that if you provide
enhancements in this area, that you do it in such a way that customers
can highly customize how the enhancements are used (e.g., the wording
of the mailfile, etc).
Parsing the contact field was pretty tricky, due to the curious way in
which the continuation character (-) is sometimes, but not always, used.
I was able to infer how this worked, but some improved way of getting this
would be nice. One problem is that the output is formatted differently
depending on your screen or window size.
That's all I can think of for now.
..Paul
PS: I decided to copy the list on this, as I thought some might be interested.
Paul Zarnowski Phone: 607/255-4757
Cornell Information Technologies Fax: 607/255-6523
Cornell University US Mail: 315 CCC, Ithaca, NY 14853-2601
|
