• Aucun résultat trouvé

I know what you’re thinking: “We just got finished looking at For…Next!” Well, sort of, but not really. An important difference between For Each…Next and For…Next is that with For Each…Next, you don’t have to know how many times you want to do some-thing. With the For…Next construct, you must know exactly how many times you want to do something. Using For…Next is not necessarily a bad thing, however, because it gives you a lot of extra control. For example, the next script checks a number of

per-formance indicators on the server (that is, process thread counts, page faults, working set sizes, and the like). The values for these items can change quite often, so you want to check them on a regular basis. However, frequent checking can cause a perfor­

mance hit on either the server or the network (depending on how the script was uti­

lized), so you want to check the status only at certain times. The solution here is to take measurements of all the running processes, then wait an hour and do it again. You do this for an 8-hour cycle and then quit. You could use this type of script to monitor per­

formance on a server that was heavily utilized during working hours.

Just the Steps

To implement For…Next

1. On a new line in the script, type For followed by a variable and a count (such as For i = 1 to 10).

2. On the next line, type the command to be performed.

3. On the next line, type Next.

Header Information

Our Header information section begins with the Option Explicit command that tells VBScript that all our variables will have to be formally announced by using the Dim command. One issue to keep in mind about Option Explicit is that it must be the first non-commented line in the script. For instance, in the electronic version of the next script, notice that several lines have been commented out by using the single quotation mark character (’). These lines are used to tell basic information about the purpose of the script, provide documentation on the use of various variables, and explain some of the syntax peculiarities. Once all that work is done, the first line without a single quo­

tation mark (’) must be Option Explicit if you want Option Explicit to work. The reason for this is that when the line without the single quotation mark is not the first line in the script, some variables can sneak in without being declared. On Error Resume Next uses the second line in our script. As you no doubt have noticed, On Error Resume Next and Option Explicit seem to appear in all scripts. If you were going to create a template for script creation, Option Explicit and On Error Resume Next would be a couple of good lines to include, because more than likely you’ll want them in all your scripts. How-ever, you might want to comment out the On Error Resume Next line by placing a sin­

gle quotation mark in front of it. In this way, while you are writing and testing your script, you will be able to catch all the errors, because On Error Resume Next is turned off. Once testing is completed, you simply remove the single quotation mark from in front of On Error Resume Next, turning it back on.

Next, you define a constant named ONE_HOUR and set it equal to 3600000. You’re going to use this constant in conjunction with the Sleep command, which counts in

millisec-onds. To calculate, you’d multiply 60 minutes by 60 seconds, and then multiply the result by 1000, which yields 3600000. By defining the ONE_HOUR constant, you make the script easier to read. In the complete script (on the companion CD), this constant is com­

mented to explain that it will be used with the Sleep command, which requires a milli­

second value. In addition, you might want to add several other constants in the script, such as HALF_HOUR, QUARTER_HOUR, and FIVE_MINUTES, and then you could easily change the sleep timeout value later in the script. Defining constants but not utilizing them in the script doesn’t adversely affect the running of the script, because you com­

ment them to that effect. This script has only three variables: objWMIService, which is used to hold the connection to WMI, allowing you to query for performance information about the running processes; objProcess, which is used to hold the name of each process that comes back from objWMIService; and lastly i, which is one of the weird little vari­

ables used to increment the For…Next loop. Since i is, however, a variable, and you turned on Option Explicit, you need to declare it by using the Dim command.

Option Explicit

WScript.Echo “Process ID: “ & objProcess.ProcessID WScript.Echo “Thread Count: “ & objProcess.ThreadCount WScript.Echo “Page File Size: “ & objProcess.PageFileUsage WScript.Echo “Page Faults: “ & objProcess.PageFaults

WScript.Echo “Working Set Size: “ & objProcess.WorkingSetSize Next

WScript.Echo “******PASS COMPLETE**********"

WScript.Sleep ONE_HOUR Next

Reference Information

The Reference information section of the script consists of a rather nasty WMI query string and its attendant assignment to the objWMIService variable. One line of code is all that the Reference information section takes up in this script. The nasty code is shown here:

Set objWMIService = GetObject(“winmgmts:”) _

& .ExecQuery _

(“SELECT * FROM Win32_Process”)

This line of code connects to WMI and then executes a query that lists all Win32 pro­

cesses running on the machine. As mentioned earlier, you’ll learn about WMI in later chapters, but it is important to notice now that the query looks exactly like a regular SQL Server query. The code says to select (which means to choose something) from the Win32 process. The “something” that is being chosen is *. As you no doubt recog­

nize, * is the wildcard character and means “everything.” So this query chooses every-thing from the Win32 process.

Note Notice in the preceding code the underscore (_) that appears at the end of the first and second lines in the Reference information section. These are used to break up the code into more than one line to make the code easier to read. The important aspect to pay atten­

tion to is the placement of the open and close parentheses and the quotation marks (" ") as you break up the lines. Notice also that in the beginning of the second line, the ampersand was used, which as you’ll recall from Chapter 1 is the concatenation character. This amper­

sand was used because you’re inside of the parentheses, and you need to stick the two lines together. At times, you’ll need to embed spaces to ensure commands are not messed up when you break the lines. The line continuation following ExecQuery does not include the ampersand because it falls outside of the parentheses.