Hello David I see some problems in bypassing steps in the application.Are you sure that the program in server C does nothing except, maybe parse the output, and write it to server E? Are you sure that other parts in the application does not check the run status in SQL SIS in server B before they run?
Anyway, you can use Control-M to run jobs on server C or server D directly.If you are sure, you can write a shell script to run the package and run this from Control-M. I think you need to run this from Control-M because there are usually other jobs in Control-M that waits for this job to finish.
Adar Yechiel Rechovot, Israel David Barbour wrote:
Happy St. Paddy's Day. This is on 64-bit RHEL 5.3, Oracle 10.2.0.4 and 32-bit Windows 2003.I've got a third party application that performs scheduled jobs against the database in a somewhat convoluted manner. Another third-party application (Control-M) on Windows Server A calls a SQL Server Integration Services Package on Windows Server B that references an executable for the 'real' third party application - always the same executable - and an associated .xml file on Windows Server C to run an Oracle stored procedure on Linux Database Server D and the results (always comma delimited regardless of the job) are output to a fileshare on Windows Server E. The .xml file on Windows Server C has all the parameters required to run the job. There must be a way to run this directly from the database. I cannot modify the actual stored procedures supplied by the vendor. I can maintain the .xml on the Linux box and /or mount samba shares as needed/required. There are too many moving parts and the processes have issues every night. The switch to DST was particularly exciting or discouraging depending on your point of view. How would you simplify this? I've got several ideas, but I'm not sure they're any more elegant than the current lashup. It needs to be simple and straightforward for ease of maintenance.