How to avoid redirection error using START (nowait)?

[Hennie Jalink]

We use a construction with redirect stdout to logfiles for
batchjobs. When doing this in two stages, using START
(nowait) the first logfile is (probably?) blocked by the
(asynchronous) process just STARTed.
It's a bit complicated, so I've created a testsituation.
Place the following files in one dir, CD to that dir, and
CALL T1.cmd.

T1.cmd
======
@echo OFF
echo =T1 PRE 1> T1.log
call T2.cmd 1>>T1.log
echo =T1 POST 1>>T1.log

T2.cmd
======
@echo OFF
echo =T2 PRE
START /wait T3.cmd
echo =T2 POST

T3.cmd
======
@echo OFF
echo =T3 PRE 1> T3.log
call T4.cmd 1>>T3.log
echo =T3 POST 1>>T3.log
exit

T4.cmd
======
@echo OFF
echo =T4 PRE: hit any key to go on!
PAUSE
echo =T4 POST

There is NO problem when START /wait is used in T2.cmd:
when you <enter> in CMD-box for T4 to lift the PAUSE, both
logfiles T1.log and T3.log reflect exactly what's
happening.

When using START without /wait, you see the following error
in the first CMD-box:

E:\Batch\TestProbleem>call t1.cmd
The process cannot access the file because it is being
used by another process.

In T1.log we miss the line "T1 POST", though "T2 POST" has
been written!

Can anyone help?

 

[Ritchie]

Can anyone help?

Run the output through a stream splitter, like this:-

T1.cmd becomes:-
@echo OFF
echo =T1 PRE |mtee T1.log
call T2.cmd |mtee T1.log /a
echo =T1 POST |mtee T1.log /a

T2.cmd no longer needs to wait:-
@echo OFF
echo =T2 PRE
START T3.cmd
echo =T2 POST

T3.cmd becomes:-
@echo OFF
echo =T3 PRE |mtee T3.log
call T4.cmd |mtee T3.log /a
echo =T3 POST |mtee T3.log /a
exit

T4.cmd is unchanged

There's plenty of stream splitters 'out there', I prefer mtee
http://www.jsiinc.com/SUBL/tip5900/rh5921.htm
www.commandline.co.uk/mtee

 

[Hennie Jalink]

Thanx for the help Ritchie! But when I tried this, T1.log
looks like this in the first cms:
=T1 PRE
=T2 PRE
=T2 POST
and this cmd hangs on this point! That's not what one
expects using a START...
Only when I de-PAUSE the second cmd, the first one goes
on! So it seems that stdout of cmd1 is still blocked by
cmd2! Any suggestions?

Hennie

 

[Ritchie]

Thanx for the help Ritchie! But when I tried this, T1.log
looks like this in the first cms:
=T1 PRE
=T2 PRE
=T2 POST
and this cmd hangs on this point! That's not what one
expects using a START...
Only when I de-PAUSE the second cmd, the first one goes
on! So it seems that stdout of cmd1 is still blocked by
cmd2! Any suggestions?

Hmm.. I was able to replicate your issue using your scripts. When I reomved
the /wait switch and piped the output through mtee, the logfiles were identical
to how they were with the /wait switch and redirecting the output directly
into the logs. I just double-checked my results.

I'm using Win2000 Pro (SP4...

 

[Ritchie]

WEIRD! I have Windows2000 PRO (SP1).I tested the behaviour
of this all under Windows NT4. It was identical, so
despite the START without the /wait, I still had to wait
for the second CMD to end. I will upgrade my PC to SP3
(current version for us) and see what's happening...
To my regret we have Windows NT4 SP6a for most of our
servers, so probably we are stuck with this problem on
NT4...

Windows 2000 cmd.exe appears to run quite happily on NT4.6a. I've never
had any problems in doing so, and I've never heard anyone else complain.

So if you're feeling brave give it a try (only on one server to begin
with of course).

 

[Hennie Jalink]

Perhaps I was unclear: even WITH the use of MTEE I still
have the same problem. The only difference is that the
error "The process cannot access the file because it is
being used by another process." doen't appear anymore.
Instead my first cmd waits until I dePAUSE the second cmd,
although a START without /wait was used!

Thios behaviour is the same for Windows2000 Pro SP3 and
Windows NT4. My only further option = Win2000Sp4 because
that works as expected so you tell me!

Hennie

 

[Paul R. Sadowski]

When using START without /wait, you see the following error
in the first CMD-box:

E:\Batch\TestProbleem>call t1.cmd
The process cannot access the file because it is being
used by another process.

Use sleep or something else to delay execution:

@echo OFF
echo =T2 PRE
START T3.cmd
sleep 10
echo =T2 POST

 

[Hennie Jalink]

Nice try, Paul, but it doesn't work! By the way,
WindowsXPsp1 has the same problem.

The strange thing is, that in T2 you immediately (or after
10 seconds when using sleep 10) see the "=T2 POST-line",
so the START without /wait worked. But then, after
the "return" to T1, the redir-file seems locked and T1
cannot write to it. The lock is only lifted when T3 is
ended, as you can see when you use MTEE according toi
Ritchie. When you use >> directly, you get the mentioned
error! I am totally out of options now!

 

[Ritchie]

Perhaps I was unclear: even WITH the use of MTEE I still
have the same problem. The only difference is that the
error "The process cannot access the file because it is
being used by another process." doen't appear anymore.
Instead my first cmd waits until I dePAUSE the second cmd,
although a START without /wait was used!

I didn't realise the issue was with t1 waiting for t4 to finish, I thought
it was with "The process cannot access the file..." message.

The solution is quite straightforward. All you need to do is make sure
that the process in which T3 runs, is NOT owned by the process in which
T2 runs, which is also running T1 (as is the case when START is used).
This can be achieved by using CMDOW, but similar utilities that start
new processes should work equally aswell. www.commandline.co.uk/cmdow

So using the four scripts that you originally posted, just replace
'START /wait' with 'cmdow /run' (or with the appropriate command if
you use an alternative utility).

T1 will complete immediately, even though T4 is waiting for a keypress.
Nor will any error messages be displayed. T1.log will look like this:-

=T1 PRE
=T2 PRE
=T2 POST
=T1 POST

And when T4 has finshed, T3.log will look like this:-

=T3 PRE
=T4 PRE: hit any key to go on!
Press any key to continue . . .
=T4 POST
=T3 POST

 

[Hennie Jalink]

Thank you, Ritchie. I think you hit the coreproblem here.
I will modify our cmd's according to your suggestion.

Hennie

 

[Paul R. Sadowski]

Nice try, Paul, but it doesn't work! By the way,
WindowsXPsp1 has the same problem.

Really? It worked on my machines (XP SP1 & 2K Server SP4)

C:\users\sadowski\test [(firecat) 11:28, Thu 08/07/2003] t1.cmd

C:\users\sadowski\test [(firecat) 11:29, Thu 08/07/2003] cat T1.log
=T1 PRE
=T2 PRE
=T2 POST
=T1 POST

C:\users\sadowski\test [(firecat) 11:32, Thu 08/07/2003] cat T3.log
=T3 PRE
=T4 PRE: hit any key to go on
Press any key to continue . . .
=T4 POST
=T3 POST

Am I missing something?

 

[Ritchie]

Paul, this is weird! I don't have an explanation for this.
But Ritchie gave us CMDOW, which starts processes
different than START, and that works as expected, even on
NT4Sp6a, so that's what we will use.
I still do not exactly understand the different ways you
can run new processes in Windows. But there are at least
two methods (used in START en CMDOW!) that give different
relationships between the starting and the started proces!

The START command in NT4/2K/XP/2003 is a cmd.exe internal command. When
used to start another process, the new process's parent is the instance
of cmd.exe that executed the START command.

When you use CMDOW to run another process, cmd.exe starts CMDOW in a new
process. CMDOW then lauches the program of your choice in another new
process. CMDOW then exits leaving the launched process (your program)
without a parent. In otherwords your program is no longer owned by cmd.exe.

HTH