EyeOpener has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks,

For about a year, I've been running a script that uses Win32::OLE and CuteFTP's Transfer Engine. The pertinent part of the script begins like this:

use Win32::OLE qw(in with); use Win32::OLE::Const 'CuteFTPPro'; my $ftp = Win32::OLE->new('CuteFTPPro.TEConnection', 'Close') or die "Error: Can't create FTP object: $!"; print "FTP object created, continuing...\n";

This script runs unattended on a Windows 2000 machine, using Task Scheduler, running in the context of a service account I set up for this purpose. I have a new project that requires something similar, so I borrowed a bunch of this code from the working script.

My new script is complete, and runs fine when I run it manually from a command prompt, logged in as my service account. The problem is, the script hangs at this point when I run it unattended from Task Scheduler. The my $ftp = line never finishes: it doesn't print the die error, nor the following print statement. (I'm piping the output to a logfile, so I can see exactly where it hangs.) It will hang at this point until I kill the task.

I'm at a loss to explain it, and I can't figure out how to troubleshoot this. I don't have much visibility into the process when it's running as a scheduled task, so I don't know where to go with this. Does anyone have guesses as to what might be going on, or how to narrow it down? Any ideas would be appreciated - thanks!

Replies are listed 'Best First'.
Re: Can't create Win32::OLE object
by cool_jr256 (Acolyte) on Jun 10, 2005 at 19:45 UTC
    I'm taking you're trying to run your new code on the same machine and the same way as the other script?
      Doh! I figured it out - there was an abandoned ftp process from an earlier failed runthrough of the script. I killed the process, and my script runs fine now. Apparently it couldn't create another instance of this process with one still hanging out there, or something like that. Sigh...
        Apparently it couldn't create another instance of this process with one still hanging out there

        I don't think it even tries. If the application is already running, it will send the commands to that process. That means it was sending commands to (and waiting for a reply from) the non-responsive process. I'm not too sure about this.

      Yes, same machine, both scripts are scheduled with Task Manager with the same service account. Weird, eh?