Batch file hanging

>> Does this point to an  environmental difference between going into a normal cmd window and running a batch file

I don't think so, but there's probably something in your environment that tells cmd to stay open once its job is finished (not the case on my box here). Could you please test again your 'other' batch, but this time changing from "cmd <old batch file name>" to "cmd /c <old batch file name>" ? If it works as expected, I'd suggest trying to use something like system("cmd.exe /c zipit.cmd") in the C code.

HTH.

I have tested it with the following:

c:\winnt\system32\cmd.exe /c c:\<name>.bat

Same problem. doh! winzip self extractor process created and just sits there. its almost as if the self extractor program has launched a gui, even though it hasnt and doesnt need to.

So, it's the winzip executable that is hanging ? ...

For debugging purposes, could you add some lines at the beginning of the batch :

set > batch.log

and additionally if you're running 2K

echo %CD% >>batch.log

The idea is to try to locate the environmental differences.

The results of running the batch file in this remote way are as follows. presumably there is something here which is different from that of a normal cmd window??
ORACLE_SID=extproc
ALLUSERSPROFILE=C:\Documents and Settings\All Users
Classpath=C:\Plan_Dissemination\PD_Task_Generation;C:\Plan_Dissemination\PD_Task_Generation\arapi51.jar
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=CMDEVDB
ComSpec=C:\WINNT\system32\cmd.exe
db_code=D:\CM-R4\Database\Oracle
db_make=D:\CM-R4\Database\Oracle\CMDEVDB
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Os2LibPath=C:\WINNT\system32\os2\dll;
Path=D:\Oracle\Ora81\bin;C:\Program Files\Oracle\jre\1.1.7\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Plan_Dissemination\PD_Task_Generation;C:\Program Files\WINZIP81;C:\Program Files\WinZip Self-Extractor
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 1 Stepping 2, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0102
ProgramFiles=C:\Program Files
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINNT
TEMP=C:\WINNT\TEMP
TMP=C:\WINNT\TEMP
USERPROFILE=C:\Documents and Settings\Default User
windir=C:\WINNT

Hmm, looks like a permissions issue. I see no USERNAME and the USERPROFILE variable points to Default User. Strange...

Wild guess : it looks like the batch is started in some other context. I don't know the details of an Oracle install, but if it's a service which is running under a specific account, you might want to try to give that account enough rights over the files and directories which are to be manipulated...

Another suggestion : if you haven't done it yet, have some explicit cd commands in the batch just to make sure you are in the right directory.

this is a little bizarre as my batch file works up until the winzip self extracting line so by thatpoint it has already created files and run an exe (the winzip command to zip files up) so some permissions presumably exist.
what ones would be missing and how do i add them? its win2k.

in terms of directory, the winzip self extractor is in the path so its obviously finding it, and the batch file is invoked with a full path too so i dont think its that. permissions sounds more likely. what like i said, what rights are missing?

then also theres the fact that the batch file runs perfectly locally so how does this mean that there is a disparity between the rights assigned to an invoked command window and that assigned to a command window opened by conventional means?

I rather think it's something like : the self extracting creation tool somehow requires (although it apparently doesn not use it) to interact with the desktop and is getting prevented to do so when run in that service context.

Just got a stupid idea : that tool creates a .exe file right ? Are you running some AV on that box ? If yes, did you try to deactivate it ?

we were running AV but disabling it has made no difference.

my gut feeling is that it looks like its trying to run a gui, just as if a default user was trying to invoke notepad.exe, it would appear in the processes list but never actually appear on screen as it is essentially being run remotely. of course the annoying thing is that it doesnt flick up a gui when running it locally, thereby giving some proof that it needs to interact with the desktop.

Is Oracle running under a specific account or is it LocalSystem ?
What version of winzip is this ? I can try to download it and reproduce the phenomenon here.

it is winzip self extractor 2.2, but only the licensed version can be run from a batch file silently (unless you crack it of course).
oracle is running under a named account in this instance.

when i did the set command within a command window launched locally, the username environment variable was specified as being the user that was logged onto the win2k server. contrast this with the "Default User" of the remotely launched cmd window and this is the most obvious pointer to permissions etc.

[the batch file will be different each time as well so its a default user setting that needs to be changed rather than an attribute of the batch file]

>> it is winzip self extractor 2.2, but only the licensed version can be run from a batch file silently (unless you crack it of course).

Ah. looks like I won't be able to reproduce very quickly... Since it's registered, I could imagine that the executable is looking for the license key in the registry. Possibly it cannot find it when run from that account... At this point, I'd use regmon :
http://www.sysinternals.com/ntw2k/source/regmon.shtml
to try to find out. Start it, set a filter to the executable name of the self extractor, run it from the logged on user and compare against a run in the Oracle context. Maybe you'll be able to see something interesting.
In case the license key is located in a file, use filemon instead :
http://www.sysinternals.com/ntw2k/source/filemon.shtml


I'm sorry to tap in the dark like this, but that's the best I can do for now. Hopefully, an expert having experiencing a similar issue will be able to help more quickly.

the link
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=lDK7a.15223%24Ja.592399%40news1.west.cox.net&rnum=5&prev=/groups%3Fq%3Dwinzip%2Bcommand%2Bline%2Boptions%2Bself%2Bextracting%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DlDK7a.15223%2524Ja.592399%2540news1

suggests that its a case of ok'ing the license agreement the first time one uses it. i have done this but it still doesnt work.

Interesting discussion. You said, you've "done this", but how ? Logged in interactively under that Oracle account or used the indicated procedure with an AT-scheduled cmd.exe ?

instead of sending getting oracle (via this c dll) to execute a command "<batch filename>.bat" i did the at command. then on the server at the appropriate time the cmd window came up. in this window i then went and made something into a self extracting exe and lo it brought up a license agreement. i ok'd this and now have the following results:

1) i reran the batch file (via C dll etc) from a SQL session on the server and it went belly up again. just sat there.
2) i accidentally reran batch file (via C dll etc) from the SQl session on my client machine and it worked fine!!!!!!!!!

now this raises an important question: the "user" that is invoking this file - is it ME (ie my oracle username) or is it an "oracle" account. due to (1) this suggests the former (as this was the useraccount that did the AT command to get a window up etc and so from this users perspective has accepted the license agreement).
BUT
does this mean that every individual client machine will have to do this AT command method thingy to start with as a one off when i deliver the software? bizarre or what.

(I'll still give you the points when we've finished hypothesizing)