Re: Extproc or ?

From: Yechiel Adar <>
Date: Thu, 18 Mar 2010 09:51:49 +0200
Message-id: <>

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 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.

Received on Thu Mar 18 2010 - 02:51:49 CDT

Original text of this message