MULTITHREADING

Can VBScript run shell commands in the "background"?

For example:

Set objShell = CreateObject("WScript.Shell")
objShell.run "ping 127.0.0.1"

Can the Shell object execute ping without launching the console? In this example, would it be objShell.somethingelse?

I'm also curious if anyone's had any experience working directly with Icmp.dll; pinging multiple hosts simultaneously on separate threads (which is ultimately what I'm trying to do ).

Thanks...GLM

you could use WMI to ping without the need for the console.

strMachines = "atl-dc-01;atl-win2k-01;atl-nt4-01;atl-dc-02"
aMachines = split(strMachines, ";")

For Each machine in aMachines
Set objPing = GetObject("winmgmts:{impersonationLevel=impersonate}")._
ExecQuery("select * from Win32_PingStatus where address = '"_
& machine & "'")
For Each objStatus in objPing
If IsNull(objStatus.StatusCode) or objStatus.StatusCode<>0 Then
WScript.Echo("Computer " & machine & " is not reachable")
End If
Next
Next

http://www.ostrosoft.com/icmp_component/using_vbscript.asp

Excellent...thank you both. The WMI solution is a breeze to implement, and executes quickly. OSICMP.dll is pretty dang cool in its own right.

Thanks for your help.

How would you have multiple threads running simultaneously within the script though ?

I'm actually tryin to figure out how, conceptually, I can do anything simultaneously in a script. I have an app called MultiPing (not the Nessoft version)...mine is by one Thomasz Stelmach, and doesn't seem to have a home anymore. Anyway, if I remember correctly, on his now defunct webpage Thomas was explaining how Icmp.dll could support up to 50 simultaneous threads. I recently thought "there's gotta be a way to do this in a script!"...send a packet apiece to 50 hosts, then 50 more, etc. That would make pretty short work of speciallized network polling...still tryin to figure it out. :)

Since vbs is interpreted and requires cscript (or wscript) to run, isn't the multithreading capabilities of the script itself controlled or limited by cscript in some way ? Is cscript multithreading capable ?

This is quite interesting.

I came across ThreadForker.vbs at http://cwashington.netreach.net/depo/view.asp?index=614&scripttype=vbscript. I'm curious what you guys make of this.

I downloaded OSICMP.dll and the associated sample script "ping.vbs" from the link tnoonan provided above. Upon running ping.vbs, I was struck by the fact that the command output was being echoed to the "same" messagebox one line at a time. Actually, it appears as though each reply line gets its own box, but the box includes each previous reply, simulating "realtime" feedback. I think this may have some relevance to Juan Avila's post http://www.visualbasicscript.com/topic.asp?TOPIC_ID=2329 where he is trying to get realtime output into one messagebox.

The code of ping.vbs is below...I'm curious if anyone can detect any features in the script itself that would facilitate this method of stdout redirection, or if it's just a feature of the 3rd party dll. I've tried removing all OSICMP referrences, and substituting regular ping functions, but just get the one line per pop-up.

sHost = InputBox("Enter host name or IP address", "Ping", "localhost")

Set WshShell = WScript.CreateObject("WScript.Shell")
Set oPing = WScript.CreateObject("OSICMP.Ping")

For i = 0 To 10
oPing.Send sHost

If i = 0 Then
If sHost <> oPing.IP Then s = sHost & " [" & oPing.IP & "]" Else s = sHost
sOutput = "Pinging " & s & " with " & oPing.PacketSize & " bytes of data:" & vbCrLf & vbCrLf
End If

sOutput = sOutput & "Reply from " & _
oPing.IP & ": bytes=" & oPing.PacketSize & " time=" & _
oPing.RoundTripTime & "ms TTL=" & oPing.TTL & vbCrLf

WshShell.Popup sOutput, 1, "Ping"
'oPing.Sleep 1000
Next

sOutput = sOutput & vbCrLf & "Pinging complete."
WshShell.Popup sOutput, , "Ping (OSICMP Test)"

Set oPing = Nothing
Set WshShell = Nothing

I'm not complaining or anything; I thought that the ThreadForker was something "real". Nonetheless, it is an interesting way of simulating multiple threads, and I've never thought of something like that before.

What exactly do you intend to achieve by ping the computers though ?

My superiors like to call in for up/down status on several so-called critical servers. In between our massive snmp polling cycles, it's nice to be able to get an instant status report. I already use batch and perl scripts for this and other things, but the reported "power" of WMI was quite seductive...the goal being to eventually get more than "up/down" status.

My interest in multithreading is very general, and, at this point, is fueled more by fantasy than practical application. We've many many thousand nodes, and I've found myself running, by "hand", several instances of the same script againts different chunks of hosts to save time...this is terrible practice, and ruins my day. :)

For the purpose of pinging, the results are important. In order to catch these results sent to the stdout, we will need to use files or EXEC. Simulating multithreading in this manner has its benefits of allowing us to set an arbitrary number of threads dynamically. The trick here is to determine how to track and use these results correctly and efficiently. In the case of using WMI or SICMP.Ping, it is rather difficult to dynamically change the number of threads and it is just might be as difficult to track the results.

I use WMI for determining the online status of a host on roughly 4000 hosts on a daily basis and it seems to be good enough for me under most circumstances.

Yes, getting precise results has always been a bit dicey for me. I used to use batch tokens, but would get erroneous positives, as border routers will return replies (i.e., "destination host unreachable") for down hosts depending on the circumstances (although, using the 9th token works pretty well most of the time: FOR /F "tokens=9" %%A IN ('ping -n 3 -w 3000 %IP%') DO whatever).

I'm fairly committed to sticking with WMI goin forward, as I'm tired of making all of these "niche" scripts. I'm curious as to the properties of Win32_PingStatus in terms of customization. Say a data circuit goes down, but a host is still up on a fail-over system (i.e., satellite)...can we adjust the timeout and extend the packet count to compensate? Or does WMI automatically keep trying for a certain amount of time?

I don't think you can adjust the timeout though. If memory serves me right, it is 1000ms.

Poor you, I can't even begin to imagine using batch FOR LOOP to parse the ping reply. =) I would've died instantly

Lol...I've had the same empathy for myself many a time . I think I have an inherent "when in Rome" mentality that predisposes me to shell scripting (I'm a bash-loyalist in Solaris as well). This drives my Perl-geek co-workers nuts...they've all had too much Cult of Larry Kool-Aid ("Hail Perl"). The only thing I use Perl for really is the Net::Telnet module, which is, admittedly, pretty damn useful (MS screwed us in the telnet dept.). Batch scripting's surely a trial, but it's my entrance into this whole game...and hell, it works right? Our production network is 90% windows, so I'm hoping WMI will become my secret weapon.

BTW token, do you have any thoughts on simulating real-time line echo to a single msgbox?

I don't think you can appened any data using msgbox.

Right, but do you know how the above script is simulating it?

Above script ? ThreadForker ?

No...sorry, I should have specified. It's code I got from the site tnoonan posted earlier in this thread. I posted the vbs code a few posts later.

I didn't see where it simulated multithreading. Mind point that out ?

I made a smaller test version of that script to test adding lines to a message box. I think the "trick" is that the message box just times out after 1 second. As soon as it closes, the loop does its next iteration and the box is shown again almost immediately with data appended to the string. So the message box doesn't really append, it just redisplays quickly.

My test script was a little hard to stop because of this. I had to close the console window while the message box was waiting for input.

Set WshShell = WScript.CreateObject("WScript.Shell")
sOutput = "running" & vbCrLf

do
WshShell.Popup sOutput, 1, "Output Test"
sOutput = sOutput & "still running" & vbCrLf
loop

Set WshShell = Nothing

Yes, this is what I was referring to...the simulation of realtime echo to a single msgbox. Thanks for looking at it toddio...your script demonstrates this nicely (although, as you said, it's a tad hard to kill). :)

Personally, I think it is a waste of time and energy to find a solution with the sole purpose of giving 'something' to the impatient users while the script is working. I think it is better to educate theusers about something like this rather than spending time and spoil them in the long run. =)

After all, I use scripts to automate administrative tasks to make my life easier, not to complicate it. And if a fellow administrators are too stupid to simply wait for the scripts to finish, their ability to use the scripts should be revoked =)

token: I kind of agree, but having some sort of progress information is useful even for the developer of the script. I think there's a balance to be achieved. You have to take some time to provide useful information, but not go overboard in trying to make it too pretty or user-coddling.

If I see a script is taking 10 minutes to do 100 things, and there are 1000 things to do, I'll know to leave it running and go off and do something else, and check back in about an hour and a half (100 minutes = 1:40). It's also important to see that something's happening, so someone doesn't think the script is hung.

Most of my scripts run in a console window (because I'm an old command-line guy at heart) and will do something like this to show progress:

WScript.StdOut.Write(s & chr(13))

chr(13) moves the cursor back to the start of the line, so multiple calls will overwrite the same line - then print out a number in fixed amount of space and you will get a basic uncluttered progress display that's simple to use without wasting a lot of time and energy

'- Progress.vbs - show progress counter overwriting same line in a console
'  window - run with CScript

dim n, nTotal
dim sProgess

n = 0
nTotal = 1000

Say "Processing " & nTotal & " things"
do while n < nTotal

'- do some processing here
WScript.Sleep 10

n = n + 1
if n mod 100 = 0 then
SayCR FmtNum(n, 4) & " things processed so far"
end if

loop
Say chr(10) & "done"

'---

sub Say(s)
WScript.Echo s
end sub

sub SayCR(s)
WScript.StdOut.Write(s & chr(13))
end sub

function FmtNum(i, w)
dim sPad, sNum

sNum = "" & i               ' convert i to string via concatenation
if len(sNum) >= w then
FmtNum = sNum
else
sPad   = String(w, " ")   ' create string of w spaces
sNum   = sPad & sNum      ' prepend spaces to number
FmtNum = right(sNum, w)
end if
end function

'===

I agree, I also use some, usually when there are a lot of things going on in the background, and I use them to tell me exactly at what *step* it is currently running at.

But my whole point for this was based on the requirement of original post which I can't really remmeber now because I think it kind of overlapped with the discussion of another topic in this thread. It's really simple for me though. If I'm the only one or perhaps among the only 2-3 people, I don't usually implement such things unless I MUST to track the progress. If however, more people are invovled, I'll probably looking for alternatives such as using HTML than console only solutions.

I didn't mean to dilute the original topic of this thread. I saw a nifty parlor trick in that Ostrosoft script, and was curious how it worked. I thought it could help another user's thread, but should've posted it there instead. :)

so..umm.. multithreading ?

Yes...many tasks starting in the same INSTANT. Who's got the logic?

instead of appending the data to a msgBox, why not an IE window?

quote:

---

Originally posted by giantlunarmoth

Right, but do you know how the above script is simulating it?

---

quote:

---

Originally posted by token

I didn't see where it simulated multithreading. Mind point that out ?

---

Mind point that out again ? =)

quote:

---

Originally posted by giantlunarmoth

Right, but do you know how the above script is simulating it?

---

was in response to:

quote:

---

Originally posted by token

I don't think you can appened any data using msgbox.

---

Sorry for the confusion...this was regarding the off-topic msgbox echo append simulation.

ahh..heh.. It's alright. We have lots confusion in this particular thread. Getting used to it =)

I guess you already know since it was discussed. Personally, I wouldn't do such things because, 1: it doesn't feel real (it runs minimized for me, so I didn't even see the window popup except very first one), and 2: it is proned to errors.

if i understand correctly this is what you guys are looking for. i have used it a few times to speed up wmi queries, its a pain but it works,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/making_an_asynchronous_call_with_vbscript.asp

Well, I'v considered that in the past and came to the conclusion that it was not any easier to do what I wanted to do (might just for me anyway) since the PING is just one of the process out of approximately 20 for each host that needed to run againsted. The problem with any asynchronized events is that it is darn difficult to track which event belongs to which originator. Of course, if you would only need to check the ping status (like what giantlunarmoth *originally* wanted to do, if I remembered that correctly, this thread is really hurting my head :P), async would work (most of the time).

token: > this thread hurts my head

I'd say that a "thread" about "multi-threading" branching into multiple sub-threads sounds somehow appropriate. It's good conceptual practice. =)


So anyway, I came up with a contrived example of multi threading, which is basically a main script running several sub scripts. The main script then watches a text file to wait until all of the sub scripts have finished.

I then went and looked at that ThreadForker routine and it seems to be a similar kind of thing, but with the capability of killing sub processes that run for too long.

However, my example is smaller and simpler and demonstrates multiple scripts reading and writing the same text file, so I'm posting it for everyone's amusement.

'- MainScript.vbs
'  Todd Fiske
'  2005-03-19 00:11:19

'- start several instances of SubScript each in their own minimized window

'- each subscript will be passed a random number which basically means how
'  many times to execute its main loop

'  the loop will just sleep for a random amount of time then write a line to
'  an output text file

'  when done looping, the subscript will write a "done" line to a tracking
'  text file

'- after starting the instances of SubScript, MainScript will run a loop that
'  reads the tracking text file and continues until all of the subscripts
'  report that they are done

Option Explicit
Randomize

dim fso, shl
set fso = CreateObject("Scripting.FileSystemObject")
set shl = CreateObject("WScript.Shell")

dim nSubScripts, nScript, nArg
dim aSubScripts()
dim sCmd, nRet, bDone, bRunning
dim f, sFile, aFile, sLine, nNum, bFlag, nLoop
dim sTrackingFile, sOutputFile

sTrackingFile = "MultiScripts.txt"
sOutputFile   = "MultiOutput.txt"

'- choose number of subscripts to run
nSubScripts = ( Rnd * 10 ) + 5 '- run between 5 and 14 sub scripts
say "creating " & nSubScripts & " sub scripts"
redim aSubScripts(nSubScripts)

'- delete tracking and output files
on error resume next
fso.DeleteFile(sTrackingFile)
fso.DeleteFile(sOutputFile)
on error goto 0

'- launch subscripts
nScript = 1
do while nScript <= nSubScripts
nArg = (rnd * 20 ) + 10 '- 10 to 29

sCmd = "cscript SubScript.vbs " & nScript & " " & nArg
nRet = shl.Run(sCmd, 2, false) '- run minimized, don't wait
aSubScripts(nScript) = true '- set Running flag

say sCmd & " -> " & nRet

nScript = nScript + 1
loop


'- loop until all subscripts are done
bDone = false
nLoop = 1
say "looping until all sub-scripts are done"
do until bDone
WScript.Sleep 100

'- load file into string
if fso.FileExists(sTrackingFile) then
set f = fso.OpenTextFile(sTrackingFile, 1) '- for reading
sFile = f.ReadAll
f.Close

'- split into array
sFile = Left(sFile, len(sFile) - 2) '- trim final CRLF
aFile = Split(sFile, vbCrLf)

'- turn off any flags for sub scripts that have finished
for each sLine in aFile
nNum = Trim(Mid(sLine,11,2)) '- extract number "SubScript ## done"
if aSubScripts(nNum) then
say sLine
aSubScripts(nNum) = false '- set that item of aSubScripts to false
end if
next

'- see if anyone is still running
bRunning = false
for each bFlag in aSubScripts
bRunning = bRunning or bFlag
next

bDone = not bRunning
end if

nLoop = nLoop + 1
loop

say "done after " & nLoop & " loops"

'---

sub Say(s)
WScript.Echo s
end sub

'===

'- SubScript.vbs

Option Explicit
Randomize

dim nID, nArg, nLoop, nSleep, sLine
dim fso, f
set fso = CreateObject("Scripting.FileSystemObject")

nID  = WScript.Arguments(0)
nArg = Int(WScript.Arguments(1))

'~ could get filenames as parameters too

WScript.Echo "running SubScript " & nID & " " & nArg
WScript.Echo "looping " & nArg & " times"

nLoop = 0
do while nLoop < nArg
nSleep = (rnd * 5) + 3 '- 3 to 7
WScript.Sleep nSleep * 1000

sLine = "SubScript " & nID & " slept for " & nSleep & " seconds on loop " & nLoop & " of " & nArg
WScript.Echo sLine

set f = fso.OpenTextFile("MultiOutput.txt", 8, true) 'i for appending, can create
f.WriteLine sLine
f.Close

nLoop = nLoop + 1
loop

WScript.Echo "done SubScript " & nID & " " & nArg

set f = fso.OpenTextFile("MultiScripts.txt", 8, true) 'i for appending, can create
f.WriteLine "SubScript " & nID & " done"
f.Close

'===

I'm going camping this weekend, so if I don't reply its because I'm trading computers for woods and snow for a little while. Will be back Tuesday.

-toddio

Interesting example =)

That is similar to a script that i wrote just recently ... i will have to go into work tommorow to snag it and post it up, but basicly I have 2000+ workstations that I need to poll for data (usualy through wmi queries) and waiting on a responce from one computer before asking another computer is painful and can take upwards of 6+ hrs to run. What I did, was take a .txt file full of computernames and have a script i dubbed the "batch.vbs" to read this textfile and start up the second script "*.vbs" (named according to what its searching for) with an arguement of the computername

this is allows me to poll upwards of 30 comptuers a second (limited only by a .sleep command) that keeps me from crashing the machine im running the script from

Edit: forgot to mention that this takes the 6+ hrs of runtime and crams it into 30 min + or - a few with less than 3% network utilization (meaning i can run it durring the day with out slowing the network to a grinding hault)

I dont know if this is exactly what you are looking for, but If it is ... i will post my source by noon tommorow

What exactly did you do with the scripts ? Just pulling data from WMI queries and store them in some place or are you doing something immediately upon receiving the returned queries for the individual computers ?

Yeah, could you post the scripts please =)

Darn it .. they decided to do some repair work on the DC over Sat, so I will have to post the scripts on Sun ... i knew i should have kept those scripts localy instead of on the file server oh well.