Обычно сценарии, запускаемые по расписанию, создаются по одному из двух или сразу по обоим мотивам: для обработки информации, когда никого вокруг нет, или для того, чтобы обеспечить необходимую обработку без необходимости постоянно помнить о ней. В любом случае эта обработка носит, как правило, важный характер, и вам важно знать о возникновении каких-нибудь проблем, мешающих ее выполнению. При всей привлекательности идеи автоматической обработки можно запросто упустить что-нибудь из виду, проглядеть или забыть, что может иметь довольно опасные последствия. Нет ничего страшнее в компьютерном мире, чем понять после отказа диска, что автоматическое резервирование ценных данных за последний год не велось. Рискуя излишне углубиться в данный вопрос, я все же хочу рассмотреть несколько способов, с помощью которых можно сделать сценарии, работающие по расписанию, ответственными за порученную им работу. Ключевыми понятиями здесь будут регистрация и уведомления. Проблема с программами, работающими по расписанию, состоит в том, что они не взаимодействуют с рабочим столом пользователя, и если они перестают работать, пока кто-нибудь это заметит, может пройти немало времени.
Я понял, что в качестве предохранительного механизма полезно будет, чтобы каждый автоматический процесс производил некую информацию, напоминающую о своем существовании, чтобы несостоявшийся запуск не остался без внимания. Это может быть какой-нибудь регистрационный журнал, печатный отчет или сообщение электронной почты.
В силу определенной политики каждый автоматически запускаемый сценарий должен делать запись в регистрационный журнал о своих действиях, показывающую дату и время завершения всех его ключевых задач, и, конечно же, регистрировать любые ошибки или ненормальные условия, с которыми сталкивается сценарий, например пустые файлы ввода. В следующем учебном сценарии имеется процедура по имени loggit, которая может быть использована для записи текстовых сообщений в регистрационный журнал. Эта процедура открывает и закрывает файл журнала при каждой записи сообщения, чтобы гарантировать запись информации. Если сценарий завершается аварийно, можно определить, что проблема возникла после того, как было записано последнее сообщение. Рассмотрим этот сценарий:
