The following routine checks the current time against an alarm time. If the current time is after the specified alarm time, a trigger is set.

The procedure accepts two command line inputs: the alarm hour and, optionally, minutes and seconds. The hour input must not have a leading zero, while the minutes and seconds (if supplied) must have two digits. For example, '9 05' for an alarm at five minutes after 9 AM or '10 15:05' for one at quarter past 10 and five seconds. The need to add a leading zero for the minutes and seconds could be programmed away, but I don't think it would add much to the benefit of the routine.

ALARM uses a 24 hour clock to avoid the problems encountered with the format of a 12 hour clock. In particular, determining whether the time is AM or PM just complicates things too much. So, I have opted for the easier solution of requiring all times to be referenced to a 24 hour clock using the capabilities of the PROMPT command as described earlier in the Time/Date page.

In addition, ALARM avoids another problem by checking for a 'greater than' condition using SORT, rather than trying to test the clock directly. A direct test of the time using a FIND is not a good approach. For example, to check to see if the time is 3 AM, you could try ...

The desired time will almost assuredly be missed. A batch file process is only able to test the clock a few times a second, at best. It's just not advisable to use this test for a resolution any finer than one minute, or maybe every ten seconds. That is, the input time should be HH:MM or no more than HH:MM:S.

It is intended that ALARM be called in a loop that ends when the errorlevel upon return is set to zero. Something like this ...

I suppose ALARM itself could loop until the proper time. This requires some rewriting along the lines of ...

Wait_Til would be used something like this ...

Used in this way, the routine is no longer dependent on DOS version 6.x. I used an errorlevel in ALARM.BAT to allow some other process to be run in the loop while waiting for the alarm to go off. It adds a tiny bit more versatility.

One final note, ALARM.BAT accesses the drive that contains the directory specified in the RAM environment variable (or the active directory if RAM is undefined) once for each pass through the loop. This is likely to be several times a second, meaning a lot of disk thrashing per hour if the current active directory is on a harddrive. Therefore, it is best to define a RAM drive, since you can't wear out the RAM that is acting like a disk drive. If that's not possible, a delay should be added to the loop to reduce the number of accesses per hour, to say one per minute. See my page on messaging for a description of how to build a timed delay using DOS 6.x's CHOICE.EXE utility.