I have not used module Win32::OLE myself, but from reading the documentation in seems to be a function from the module, that delivers a list of from a given collection object.

From the module documentation:

in(COLLECTION)

If COLLECTION is an OLE collection object then in $COLLECTION returns a list of all members of the collection. This is a shortcut for Win32::OLE::Enum->All($COLLECTION). It is most commonly used in a foreach loop:

            foreach my $value (in $collection) {
                # do something with $value here
            }
[download]

Thanks for the info.

The hang is caused by the reading of the collection

$val = Win32::OLE::Enum->All($col) or $ok = 0;
[download]


Here is where the script locks/hangs.

I have tried to eval and alarm. Nothing is breaking
out if the commands hangs.


    eval 
      {
      local $SIG{ALRM} = sub { warn "ALARM FOR GET EXEC QUERY: \"$quer
+y\" L: \"" . __LINE__ . "\" F: \"" . __FILE__ . "\"\n" }; # NB: \n re
+quired
      alarm 5;
      $val = Win32::OLE::Enum->All($col) or $ok = 0;
      alarm 0;
      };
     if($@) { $ret = $@; print "ERR: \"$ret\"\n";
              $err = 1; $ret = "timeout while QUERY: \"$query\" wmi on
+ machine $host"; return($err, $ret); }
[download]



any suggestions on howto eval/jail this line, then
breakout/throw error in case the time/condition is met?

Only certain machines are causing the hang/lock. Most
of the machines breeze past within 5 seconds.

So iterating 5000 plus machines then hanging on a random
is a PITA.

TIA, Joe

Hello again,

you must try to isolate your problem. I admit that, for me, reading the expose of your question result to be a bit difficult. Also the code you show is not so perlish and lacks of use strict; use warnings; Anyway, wat I found is:

> Only certain machines are causing the hang/lock.

You have not to eval/jail (as you say) the function: you are outside perl domain. Infact you are dealing with something similar to a complex system call: microsoft stuff are well known to return (or not return) weird behaviours. You know if you are used to work with these things.

If a remote call fails or hangs is not useful to wrap in eval and wait 300 seconds to have back a 255 error or something else, equally unuseful. Better try to whatch $^E that is last operating system error or even better check first if the machine is reachable. Programatically or manually check the Event Viewer in the remote machine to spot some (rare) useful entries.

Other sparse hints: the problem maight be at RPC level (i'm in guess mode now..) try some command line version using wmic to confirm both versions hangs; wmi connection can be set to use a timeout, like in $os.options.Timeout=[timespan]::FromSeconds(30) or similar. There are here around WMI Diagnosis Utility and WMIdiag. Build a list of hanging machines and look at them carefully (what if remote service is stopped? ram cpu?)

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

the foreach $obj (in $col syntax is not a perl syntax; it's a WIN32::OLE one.

Due to the weirdness of the matter (win32) and also a bit aged perl syntax used building the interface of the modules in the win32 namespace (I thanks many time their authors for having wrote them..) some misunderstang can occour.

In this case you have a container $col that is not a simple perl datastructure but an abstraction made by the module. Or at least i understand it this way.

See here to have in explained.

L*

alarm is a Unix thing. It requires signals, also a Unix thing. Windows has neither. Perl has an emulation, but it is far from being perfect. When the perl interpreter is blocked, it can not emulate signals and so it can not emulate alarm to interrupt a blocking system call.

See also Re: Handling killing the perl process, Re: Signals in Strawberry Perl: Name or number?, $SIG{ALRM} and windows vista?, and several other threads.

Update: See also "alarm" in perlport:

(Win32) Emulated using timers that must be explicitly polled whenever Perl wants to dispatch "safe signals" and therefore cannot interrupt blocking system calls.

Alexander