Batch job doesn't run every time it's supposed to in the Windows Scheduler

[Oldtooth]

Hi All,
I've written a DOS batch script that is supposed to run every 10 minutes in the Windows Scheduler (W2K).
But it only runs on about 40% of the scheduled times.
Can you take a look at my script please to see what might be causing the missed runs?

The script, called Run_Downloads.bat, generates another batch file, that in turn, calls a 3rd party http tool (called FT_Connect) to download files from Europe.

The script is included below . .
There are some remarks within the script to describe what the logic is trying to achieve.
TIA.

-------------------------------------------------------------------------------------------------------
@echo off
::
:: Script Name  -  Run_Downloads.bat
::
:: DOS script to generate the RUN commands for the daily downloads.
:: Run every 10 minutes during the day, via the Windows Scheduler.
::
:: We need a start time and an end time for the download jobs.
:: The end time is "now" and the start time is 11 minutes ago.
::
::
:: Get the current hour and minute.
::

SET CURRENTTIME=%TIME%
for /F "tokens=1 delims=:" %%h in ('echo %CURRENTTIME%') do (set /a HR1=%%h)
SET /A HR2=%HR1%
for /F "tokens=2 delims=:" %%m in ('echo %CURRENTTIME%') do (set /a MIN1=%%m)
SET /A MIN2=%MIN1%

::
:: If the minute is <= 09, roll it back by adding 60 to minutes and
:: subtracting 1 from hours.
:: Then subtract 10 minutes for the start time and subtract 1 
:: more minute for the time overlap.
::

:: === CONFIGURE THE -FROM- TIME =====================================================

IF %MIN1% LEQ 10 (
   SET /a MIN1=%MIN1%+49
    SET /a HR1=%HR1%-1
) ELSE (
   SET /a MIN1=%MIN1%-11
)

:: Subtract 7 hours from the time, due to the time zone difference between Singapore and France.

SET /a HR1=%HR1%-7

::
:: Pad single digit minutes with a leading zero
::
IF %MIN1% LEQ 9 (
   SET MIN1=0%MIN1%
)
::
:: Pad single digit hours with a leading zero.
::
IF %HR1% LEQ 9 (
   SET HR1=0%HR1%
)
::
:: Use the new hour and minute (and existing seconds) to create the -FROM- time.
::

SET FROMTIME=%HR1%:%MIN1%:%CURRENTTIME:~6,2%
ECHO From Time is %FROMTIME%

:: === CONFIGURE THE -TO- TIME ========================================================

:: Subtract 7 hours from the HOUR component due to the time zone difference between SGP and Germany.

SET /a HR2=%HR2%-7
:: IF %HR2% LEQ 9 (
::   SET /a HR2=0%HR2~2,1%
:: )

::
:: Pad single digit minutes with a leading zero
::
IF %MIN2% LEQ 9 (
   SET MIN2=0%MIN2%
)
::
:: Pad single digit hours with a leading zero
::
IF %HR2% LEQ 9 (
   SET HR2=0%HR2%
)
::
:: Use the new hour and minute (and existing seconds) to create the -TO- time.
::

SET TOTIME=%HR2%:%MIN2%:%CURRENTTIME:~6,2%
ECHO To Time is %TOTIME%

SET DATE1=%date:~10,4%-%date:~4,2%-%date:~7,2%
@echo FT_CONNECT 4 -ttf %DATE1%T%FROMTIME% -ttt %DATE1%T%TOTIME% -d -n D:\Import\Temp >D:\FileTransfer\versions\V2.08
\File_Import.bat

:END
call D:\FileTransfer\versions\V2.08\File_Import.bat

-------------------------------------------------------------------------------------------------------

[Salmon Trout]

That is not a "DOS" batch script. It is a Windows NT family command script. There is a big difference.

I have only looked at the code, I have not thought about the logic at all. At a first glance, I can see some potential problems

1.
set /a regards numbers starting with a zero as being in Octal, so you are going to hit problems when the hour or minute is 08 or 09 (impossible values in Octal) the script will give wrong values and possibly halt so you need to test for a leading zero in those values.

In any case you only need to use the /a switch when you are actually doing arithmetic, to assign a value you just use set on its own

example:

set v1=10
set v2=5
set /a v3=%v1%+%v2%


-----------------------------------------------------------------------------------------------------------


2. here...

:: If the minute is <= 09, roll it back by adding 60 to minutes and
:: subtracting 1 from hours.
:: Then subtract 10 minutes for the start time and subtract 1
:: more minute for the time overlap.
::

:: === CONFIGURE THE -FROM- TIME =====================================================

IF %MIN1% LEQ 10 (


...the remark says <=9 but the IF statement says LEQ 10

 you are testing if MIN1 is less than or equal to 10, did you really want to do that?

-----------------------------------------------------------------------------------------------------------


3.
I noticed you seem very fond of using a double colon :: to start a comment line. I can't stop you doing this, but you need to be aware that the official batch script comment starter is REM. The double colon is not supported and completely unofficial, and furthermore it breaks scripts if it is used inside parentheses (long form IF and FOR and && or || structures etc)

For example this will halt the script (it will crash straight out with no error message at the second line)

IF %chickens% geq 10 (
    :: We have at least 10 chickens!
    echo Enough chickens
)

[Oldtooth]

Thank you Salmon - you've given me a few things to change in the script. I did cater for the Octal minutes possibility, but not the hours. I think that would explain the missed Scheduler runs.

[TheShadow]

Years ago, the logic was to use the double colon instead of the REM statement.  The reason was, when DOS would see the REM statement it would actually read the rest of the line and could even execute some command if one was found in the line.
Who would of thunk it?
But, when DOS would see a double colon, it would just jump to the next line, thus speeding up the execution of the batch file.

Of course I'm going back to 8088 CPU days, when we only had 64k of ram and maybe a 20 meg hard drive.
Thus the idea of using the double colon to begin a Remark line.
I still use that technique, just out of force of habit and it still works just fine, even though DOS batch language has changed considerably. (over the past 30 years)
Some things are hard to change, and when there's no good reason, why change?

Happy Holidays Everyone!
 

[Raven19528]

Of course I'm going back to 8088 CPU days, when we only had 64k of ram and maybe a 20 meg hard drive.

So basically, back when you wanted to squeeze every drop of processing efficiency out of the CPU. But IIRC, the 8088 only ran at 8 MHz. If you take the processor in my computer now, which is by no means a super machine, at 3.2 GHz, you are talking about a processor that is about 400 times more powerful and when you are talking batch, the two processors are essentially doing the same thing.

It comes down to two arguments, it's unofficial and unsupported, and old habits die hard. If it isn't currently breaking anything, I suppose that it doesn't matter which side of the fence you subscribe to, or if you even care that the fence is there.

[Salmon Trout]

when there's no good reason, why change?

MS-DOS COMMAND.COM reads a batch file, executes one command line, reads the batch file again, executes the next command line, etcetera. This means each comment line causes one extra reread of the batch file; no problem when read from hard disk, but it may slow down batch file execution from slow floppy or network drives. Hence the workaround of using colons to convert comment lines into labels. COMMAND.COM skips labels it doesn't have to jump to. This method has the disadvantage that your batch file may "accidentally" really use the label to jump to although reasonablly attentive code writing should avoid that. However it can be solved by using a double colon to create a broken label. This may speed up reading large blocks of comment lines from slow (floppy) drives.

The cmd.exe command environment used by NT family operating systems (NT4, Windows 2000, XP, Vista, Windows 7, Server 2003 and 2008) is not "DOS". The syntax is mostly backward compatible in that most MS-DOS batch language commands will still work, and many batch scripts can be made to run sometimes with some editing. However, it is not the same language and it contains structures and features that are broken by double colon comments. To me, who has been using MS-DOS and Windows since 1983, that is a good reason. Plus I don't run programs with huge blocks of commented out lines from floppies.

[Salmon Trout]

To me, who has been using MS-DOS and Windows since 1983, that is a good reason. Plus I don't run programs with huge blocks of commented out lines from floppies.

In situations like these I have always thought that numbers speak louder than opinions, so...

I made this test batch which, although short, has some realistic commands that an everyday batch script might contain:

Code: [Select]

@echo off
setlocal enabledelayedexpansion
set num=0
set drive=F
for /f "delims=" %%A in ('dir %drive%:\*.txt /s /b') do (
set /a num+=1
)
echo %num% txt files in drive %drive%
I also made two more versions: one has this line repeated 50 times inserted before the FOR loop

:: A comment

The other has this line repeated 50 times

REM A comment

I then ran each batch 1000 times, recording the start and finish times. My system is fairly modern (at least by comparison to a 16-bit MS-DOS machine of the 1980s)

64 bit Windows 7 Professional running on a 3.0 GHz Phenom II quad core with 4 GB DDR2-400 RAM, the batch resides on a 7200 rpm SATA drive, the drive being searched is a 5400 RPM E-IDE device.

The results:


No comments at all    59.56 seconds
Double colon comments 60.85 seconds
REM comments          65.23 seconds


So there is a slight overhead with any kind of comment: The bare script takes around 1 minute; 50 broken labels make the script take about 1 millisecond longer (1 part in 60,000); 50 REMs make it take about 5 milliseconds longer. Whether this matters I shall not advance any opinion.

[Salmon Trout]

The bare script takes around 1 minute; 50 broken labels make the script take about 1 millisecond longer (1 part in 60,000); 50 REMs make it take about 5 milliseconds longer.

That looks a bit disjointed (not to mention wrong): what I should perhaps have typed is "The bare script takes around 1 minute to execute 1000 times; to execute once thefore would take around 60 milliseconds; 50 broken labels make it take around 61 milliseconds (1 part in 60 approx, or 1.66%) and 50 REMs make it take around 65 milliseonds (1 part in 12 approx or around 8%)."

[BC_Programmer]

Adding performance as a concern when dealing with Batch scripting is self-defeating in any case.

[TheShadow]

The original article I read on the subject, many long years ago, was not so much concerned with the speed as much as DOS's capacity for executing commands if found in a Rem statement. 

So I started using the double colons, which I found easier to type, and I've been using them ever since.
After doing it for around 30 years, I don't think I'm going to change now and why should I?

After all the ranting and raving and trying to make me look stupid, I still see no reason to change.
For a forum that's suppose to be "Helpful" I don't see it being very helpful here.

I'm sorry I wasted anyone's time.  It won't happen again.

OUtta heah!

 

[Salmon Trout]

DOS's capacity for executing commands if found in a Rem statement. 

The scripting language under discussion, as ha been repeatedly pointed out, is not "DOS", but you seem content to ignore that.

After doing it for around 30 years, I don't think I'm going to change now and why should I?

It has been explained exactly under what circumstances you should not use double colons.

trying to make me look stupid

Nobody (save perhaps you yourself) has tried to do that.

For a forum that's suppose to be "Helpful" I don't see it being very helpful here.

This thread isn't even about you. The OP asked for some hints as to why his script might not execute. He was given some. That was helpful, I venture to suggest. You read these and chose to pile in, and you got the responses that you got. Nowhere in the ComputerHope rules or constitution is enshrined the right of a poster not to be disagreed with or contradicted or corrected.

I have noticed elsewhere in CH your tendency to post in a brash, assertive, "listen to me because I know what I'm talking about" fashion. Seems to me that you can give it out, but are somewhat less happy to receive it.

[BC_Programmer]

The original article I read on the subject, many long years ago, was not so much concerned with the speed as much as DOS's capacity for executing commands if found in a Rem statement.

I think that you would need to do something like use a redirection character in the REM comment in order to get it to execute anything within. It's more or less by virtue of REM being a command itself, and thus it is treated like any other- you can redirect it and pipe it and as such the commands you pipe or redirect to will still be executed. Of course the simple solution is to simply not use special characters like redirection or pipe characters in a REM remark. the issues that can arise in NT Batch when using double-colons would require you to use REM comments within code blocks anyway, so may as well be consistent and use them outside as well.