Norwegian? Closest I can come is one word in Swedish! ;\)

Glad it's working! It's a perfect opportunity to illustrate RUN vs. SHELL, too.

Let's say that some external process delivers 50 Zip files each day to a network share by 1am. You need to expand and process them by 3am. It takes 40 minutes to unzip the files, one by one, using Shell. It then takes 90 minutes to process the files. Your boss is upset because the report comes out at 03:10 instead of before 03:00. You can't spead up the processing, or can you???

Well, this is where RUN can come in handy, creating a form of multi-threaded scripting. You create a script that runs at 1am and enumerates all of the zip files. For each zip file it finds, it runs an unzip command via RUN. It keeps a running count of the files, and, say, every 10 it processes, it sleeps 30 seconds. Now you have 10 CONCURRENT unzip processes running instead of one at a time. You realize that you can now unzip all of the files in under 10 minutes!! Knowing this, you can run the second script that processes the unzipped files, starting at 01:20, and completing at 02:50.

I use this type of multi-threading to fire off 25 Kix scripts at a time. These process logs from 300+ systems in about 12 minutes instead of the 3 hours it took doing them one at a time. In my environment, I actually keep track of the number of active subprocesses, firing off 25, and 5 more each time the count drops to 20 or less. Shawn used this concept recently with some impressive results.

Also, just something to consider - this was pulled directly from your code..
 Code:
$WorkFile = $RootPath+$Workdir+'WorkFile.tmp'
$OutPutDir = $RootPath + 'OutDir\'

Which line is easier to read? \:\)
Having an open and clear (and consistent) format will go a long way in making your code more supportable. Just something to consider.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D