Re: Extproc or ?
- From: David Barbour <david.barbour1@xxxxxxxxx>
- To: adar666@xxxxxxxxxxxx
- Date: Thu, 18 Mar 2010 09:53:04 -0400
Actually, the application didn't start out using Control M. It came with
it's own scheduler that ran as a service on Windows Server C. As I said,
the .xml files have all the information about the jobs, including what time
to run them. The scheduler would poll the .xml files daily and pick out the
times and set up a little file that it referenced every so often to see if
it should run the executable and the associated .xml file (providing the
parameters). Problem was (is) that the scheduler locked (locks) up the
Windows Server C every couple of hours at a minimum. We've asked the
third-party application provider to fix it, but they can't figure out why
it's happening. So they gave us a second executable that can be run
manually which is the one we're calling via Control M and the SSIS package.
We've thought about using Control M directly in the manner in which you
suggest, but there's a huge cost involved we'd like to avoid if possible.
There are no dependencies related to the jobs. They're all extracts for a
variety of purposes.
This was all set up prior to my arrival by the development team.
On Thu, Mar 18, 2010 at 3:51 AM, Yechiel Adar <adar666@xxxxxxxxxxxx> wrote:
> 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.
>>
> --
>
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
