runtime specs (can it be suppressed ?)


Well Known Member

We are using E1 9.0 TR MSSQL 2008R2 backend.

Occasionally, one of our scheduled job fails. When we delete the runtime specs for it, then relaunch it, its fine. Its a long running job which is why we schedule it in the early part of the day, so, its a big deal for the users having to launch it again after arriving to the office.

Is there any way to suppress the creation of runtime specs for a selective UBE ?
or, is there way to turn it off, altogether ?

I suppose the right question should be, why does the runtime specs corrupt ?

Thank you

While I can't say definitively, that they can't be suppressed, I'm pretty sure they can't. They are what makes deploys while UBE's are running possible.

As far as what causes the specs to corrupt, that is a $64,0000 question.

HI Jay , you could consider writing a batch script to delete the runtime specs for this particular UBE and put it on the windows task scheduler. Not an elegant solution , but if manually deleting the specs works for you now , then so will this and it will prevent the job from failing to launch.
There are a number of reasons why runtime specification files might get corrupted.

1. Are you running your scheduled job version also as an interactively-launched job ? You can check within WSJ - and make sure that only the scheduled job has been submitted by the scheduler user. Its been my experience that if you launch scheduled jobs interactively - that a user might change processing options/data selection, etc - and repeatedly doing this might cause an issue with scheduled jobs. It is a good idea to secure scheduled job versions to ONLY be run through the scheduler.

2. Are you modifying the base object through development frequently or somewhat recently? You might have issues with versions not matching the base specification. I'd recommend to wait until development has been completed as much as possible - then delete the scheduler version and recreate with the correct specifications - promote and deploy and then secure the version as in (1) to ensure its "clean" - that should clear up the issue.

3. Is the scheduled job being submitted multiple times through the scheduler - or interactively while the scheduler is running ? When you say its a "long running job" - is it a subsystem process - does it create lots of subsystem processes based on the base job (like Parallel MRP) ?

4. Is it not possible to upgrade your tools release ? There are undoubtedly a lot of fixes for Metadata Kernels and the specification process (you can look at the latest Tools Release SAR list and see if there are any specification issues that might have been resolved) - I'd recommend at least upgrading to the latest 9.1.4.x release which shouldn't affect your users Interface, and provides a reliable, stable tools release that many customers are live with. You should have a plan in place that ensures you are "up to date" with the latest Tools Release at least once per year.

To answer your final question - the runtime specs are the original "TAM" flat files that are built because they're faster performing than reading from the database/serialized objects. Unfortunately, these TAM files, while they perform really well when multiple processes read from them, are very sensitive to having more than one process "write" to them. If two processes update a TAM file at the same time, the file can become corrupted. Hence my question about whether your job is running in parallel for whatever reason - whether interactively submitted or from the scheduler.

I hope that helps.
Tom - Thank you for your input. I searched through the Oracle's website and didn't find anything pertaining to suppressing that feature, but, after your input, I now understand why its there, in the 1st place.

Ice - Great, workaround tip. I was just talking to our network guy to put a batch job to do the cleanup for that particular job.

Jon - You have certainly provided a wealth of details, so, Thank you. We are in the testing stages of the new tools 9.1.5. I agree, many new features / changes are introduced with each new release.Given that, I'm going to carefully evaluate each of your comments to see if we meet those conditions, and see if I can correct them. I have a strong feeling, we are allowing our users to launch the same versions that is being used for the scheduler.

If you're allowing your users to launch the same version - thats probably why you're seeing issues. I've seen that plenty of times with other customers. Create a scheduler-only version and lock it down ! I'm guessing that will resolve your issue.