Operating System Command Job step Default Directory
-
Does anyone know how to change the default directory for an Operating System Command step in a job? When I run a command, the default directory is the System32 directory, and I need to be able to change that due to the default nature of a commercial program that is being kicked off.
Any help would be greatly appreciated.
Scott
-
Call me simplistic, but I always believe in KISS.
Anyway, a simplistic assumption would be that you are calling master..xp_cmdshell
A simplistic solution is to create a .cmd
c:\mycmd\kickoff.cmd
with the following commands
cd /d c:\path\to\directory
theprogram.exe
Then xp_cmdshell 'c:\mycmd\kickoff.cmd'
-
The problem we have is not that simple, unfortunately. Perhaps a bit more background is in order...
We use PKZip to move files into a zipfile before they get sent out. We do this by having a job automatically create a List file that contains the filnames that should go into the different zip archives. The problem occurs when one of the list files is empty (no filenames). PKZip treats it like no filenames were passed and simply runs the action on the directory that it starts in, and since it is in a job, that is System32. When you add the Move option and the System32 directory, the result is a crashed server and a restore from the Emergency Repare Disks.
Since we have hundreds of different Zip Commands that get kicked off, we can't really set up a different file for each of them to add in the CD command, it would get quite unwieldy...
Scott
-
cant you just check for the existance of the file, or that the filesize is > 8 bytes or something before PKZIP is called?
if the file doesn't exist or meet the minimum file size, nothing happens? else it performs normally?
I'm assuming that PKZIP is being called from a vbs script , but there is a fileexists stored proc onSSC if it is all done in stored procs.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
Nope, PKZip is what is being called from inside the "Operating System Command" type Job Step. That is the problem.
-
i'd like to see the code of the job step, but i bet this will get you going in the right direction:
Perform an action when a file exisits
That's the link and how it's spelled, it probably should be when a file exists, but it would give you a pointer on how to change your SQL job step.
Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible! -
The code is a simple call to PKZip... I have it at work, but basically it is the following:
Job Step Code:
c:\Program Files\PKWare\PKZip.exe -add -move \\Server\Share\Folder\Zipfile.zip @\\Server\Share\Folder\FileList.lst
The file \\Server\Share\Folder\FileList.lst exists, but there is no data in it (because, the source data didn't contain any data for the Vendor that we are sending that file to, this is data driven and automated). If the .lst file has no data, PKZip treats it as if that parameter was not passed, and defaults to performing the actions as if I passed *.*
As I mentioned before, the problem that I have is that *.* is working in the default directory, which for a Operating System Command Job Step is the c:\windows\System32 directory. This is a bad thing, since performing a -add -move on the system32 directory is a fast track to the server crashing.
The file is there, that is not the problem. The .lst file may, validly, be empty, that is not the problem. What I need to know is how to change the default directory that a Operating System Command type Job Step starts in, so that if the .lst file is empty, that it is not going to crash my server.
I can't use any fancy scripts or complex workarounds because there are dozens of developers working in many different areas, and not everyone is going to remember that this special case has to be programmed around, and I'd like to prevent the removal of the system32 directory on my server.
I do appreciate the help that you are trying to provide, and any help that you might come up with in the future...
Scott
-
The Operating System Command step starts in c:\windows\System32 directory because that's where the cmd.exe resides. I don't think you're going to change the startup location without some serious OS hacking, and I'm sure you really want to do that
How about calling a VBScript in the Operating System Command step?
EG: CScript MySuperPkZip.vbs //B //nologo
Then you'd be able to incorporate any file checking, and path setting as required and it wouldn't be too unwieldly.
--------------------
Colt 45 - the original point and click interface
-
As phillcart says, you get a default directory of \system32 because cmd.exe lives there.
You could try copying cmd.exe to your preferred location, and ensure that location is in the PATH environment variable before the system files. If necessary, look at using an application path variable for SQL Server if you cannot change the machine's PATH setting.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
Well, I gave these approaches a try, including moving cmd.exe to a new folder and setting that folder up in the path. No luck there, as, interestingly enough, Windows appears to recreate the cmd.exe in the System32 folder (even when System Restore was turned off). This idea lead me to another, the autoexec.nt file. That file is *SUPPOSED* to be the uinitialization file for any dos environments, but adding a cd c:\testdir tot he end of that file still didn't change the fact that the Jobstep started up in the System32 folder.
This is starting to get frustrating...
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply