Monitor execution time 1

[sshafe]

Scenario:

I am writing a script to kick off a defrag against certain folders on a drive. (Which will be scheduled in order to always run in the background.) Within the script, I will issue the command to start the defrag pass.

The problem that I am trying to figure out is this: How can I tell how long the defrag execution has taken place. I would like to put a check inside of the script that says
AFTER 120 MINUTES,
STOP DEFRAG.

Any idea how to check how long the defrag has been running?


Any help is greatly appreciated.

 

[dilettante]

You cxan only defrag volumes, not folders, and only local ones at that.

Which OS? In WinXP and Win2K3 Server there is a command-line defrag that might be very helpful.

Are you using a 3rd-party defrag utility? If so, check the docs.

If using one of the early bundled defrag tools, how were you planning to stop defrag? These are GUI, so how would they do anything in the background? Maybe you mean run them minimized?

 

[sshafe]

We are going to be using PerfectDisk. They do offer a GUI, but we don't want to have to worry about closing windows, etc. They offer a command line interface. My plan is to put the execute command inside of the script to kick it off. This way, we can do emailing of statistics, problems, etc.

We will also be able to stop the defrag via command line from the script, but I am needing a way to tell the script when to issue the stop command. (A timer)

 

[dilettante]

How are you planning to initiate the defrag utility?

How can you say "stop" via the command line? Perhaps the thing will accept input via stdin? In that case I would use WShell.Exec( ) to start it.

You can loop until it completes or a time elapses, with a good long WScript.Sleep (maybe 60,000ms a.k.a 1 minute?) inside the loop. If timing precision isn't needed just count the "minutes" otherwise use a little VBS date-arithmetic.

If it completes, fine. If it times out, write to stdin with your "stop and go away" command(s).

 

[sshafe]

I think the sleep command works best for my needs.

Thanks dilettante for all the help

 

[dilettante]

Be sure to keep the Sleep( ) time down to a minute or so then, counting it in a loop. If you tried to just wait for 120 minutes your script would keep running a long time after the defrag was finished in cases where it gets done early.

Exec( ) will give you back an object to monitor the defrag with, and you can check its Status property to know when the external program completes.

 

[sshafe]

I plan on using a loop to check every 30 minutes. It seems like it would take lots of processing to check every minute. Of course I'm 5 months out of college, so your experience is much more than mine. How would you handle this?

 

[dilettante]

If you wait 60 seconds (60,000ms), then check for done, if not then count it, you'll use very few resources. Over a 120 minute period you'll only check and count a mere 120 times.

But now that I take a look at the documentation, Sleep( ) takes an integer value as the number of ms. to pause. In VBScript an integer only has values from 32,767 to -32,768! This means you'll need to count even more often than every minute. Maybe every 30 seconds?

Or use a double, nested set of loops with the Sleep( ) in the inner loop done several times for each iteration of the outer, counting loop.

I'd just live with 30 seonds and count it until it hits 240 (or the defrag gets done). The cycles spent should be minimal.

 

[jonscott8]

PMFJI. Although the documentation states "integer", what is meant to be implied is that it's a long integer, ie, Vartype() = 3, not Vartype() = 2.

You can see this illustrated by running the following:

WaitTime = 2147483646
WScript.Echo VarType(WaitTime)
Start = Time()
WScript.Sleep WaitTime
Finish = Time()
WScript.Echo Start & ":" & Finish

The script will display the start/finish time if given 25 days to run. Now run the same script above, but replace the Waittime with 2147483647 (which is no longer a long integer) and you'll get an error on calling the Sleep method.

Jon Hawkins

 

[dilettante]

Excellent point. When in doubt, try it out.

Another flaw in the MS scripting docs I guess, but at this late date the .Net focus probably means we'll never see an updated version either.