hung process

[staann56]

I'm having a problem with hung processes if the Task Scheduler times out. I run all of our Business Objects reports with Windows Task Scheduler. If the VBScript encounters a problem (like with the printing command - objDoc.PrintOut) the script hangs at this command and will not proceed and the Windows Task will eventually time out without quitting/stopping the busobj.exe process. Then the next BO report will not run via the Task Scheduler because of the already running busobj.exe process. How can I incorporate some type of timeout code to close the application (busobj.exe) if the script hangs before the appint.Quit command is reached? Below is the code I'm using

Thanks,
HW

'***********************
'Runs List for all departments
'***********************
dim appint
dim strFile
dim vars
dim objDoc
dim objRpt

Set appint = CreateObject("BusinessObjects.Application")
Set objMail = CreateObject("Persits.MailSender")
Set vars = appint.Variables
appint.Interactive = False
appint.Visible = True

'******************************
'Connect to Business Objects
'prints List report
'******************************
With appint

.LoginAs "username","password"
strReportName = "List"

Set objDoc = appint.Documents.Open(strReportName)
vars.Item("dept").value = "A"
objDoc.Refresh
objDoc.PrintOut("PRINTER")
objDoc.Close

End With

'**********************
'Close Business Objects
'**********************
appint.Interactive = True
appint.Quit

'*************
'Close Objects
'*************
Set objRpt = Nothing
Set objDoc = Nothing
Set appint = Nothing
Set objMail = Nothing
Set appint = Nothing
Set vars = Nothing

 

[tsuji]

You could host the script with cscript and then set batch mode and timeout (in unit of second) such as this.
[tt] cscript.exe //B //T:120 script.vbs[/tt]
That is a non-application specific appraoch. If you want an application specific measure, which you would have more pinpointed control, you might have to look into the event model of the application see if there are event associated with print operations. If there isn't, you are out of luck.

 

[staann56]

Would using the cscripte.exe close out the spawned process if the *.vbs script times out?

Thanks,
Stan

 

[tsuji]

It can be quite tricky there. If your appint just being instantiated and sitting there, then at time out, it would most probably be destroyed at the time. _But_, as it is not just sitting there, the objects will be orphaned in the memeory. (One can test and establish this quite rigorously positively or negatively. For instance, it is positive for excel.application. Should it have been doing the loading of a file, it would be orphaned when time out.)

But, though clumsy in construction, it can be tackled along this line of timeout construction.
[1] Launch a vbs A.vbs say.
[2] From A.vbs use wshshell.run to launch B.vbs which is thw workhorse, such as your script fragment shown. This time, B.vbs is launched with timeout and batch mode as suggested with adhoc educated guess timeout length.
[3] Now, A.vbs, after launching B, goes into wscript.sleep for a period longer than the timeout set for B.vbs.
[4] After A.vbs waked up from the sleep, it will launch a wmi query for businessobject.application instance. If it still find one, it is a good indicator it being hang for some reason.
[4.1] If it is found, A.vbs will run a force process terminate() method to kill it.
[4.2] Continue what need be done.

In the step of [4], you can do more pinpointed diagnostic. If it is a print process being in trouble, you can use wmi query printqueue for the status of the printjob. That would be a more pinpointed diagnostic for instance.

In any case, this is the general approach along this line of thought. It is a poor-person's approach. More sophisticated method using event call-back seems more elegant intellectually, (wmi or businessobjects.application's alike). However, the main thing here is to get a job done.