It looks like I'm not the first to experience a problem with Control-M being able to execute a script to run MSACCESS as I found this post from a few years ago: ms access - Control-M job not ending after .bat finishes - Stack Overflow
Unfortuntely, they didn't find/post a solution.
Thanks Mark. So should the child process be set to Yes or No? It is currently set to Yes.
I've used the DB module for Oracle but not for MSAccess. I will pass that on to them to see if it would be an option.
I would try that as a test, although this may impact other jobs run through the same Agent. Is the task actually running on the Windows level? The Windows Admin can usually run a detailed process trace to see what is active once the Control-M job starts (you need to give them notice before you test as they need to switch the trace on).
Did you configure the agent for LogOn As User?
By default, the agent (and all jobs submitted to it) will run as Local System account, which may cause trouble when running scripts/apps that need to run with a specific user.
When configuring LogOn As User, make sure you use a local or domain account for the agent services, and make sure you configure the Local Security Policies in the server as well.
The agent runs with a service account that has local admin rights. I've tried submitting the batch job w/Logon As User set to yes and no and both fail. I can execute the script with the Run As User account outside of Control-m and it runs successfully. They put some logging in to their program and I think it's something with oracle that is causing the problem. But I don't understand why it works when ran outside of Control-M.
From a LogOn As User perspective, I'd suggest you check/try the following:
-Expand Local Policies > User Rights Assignment
-Add the service account with which the agent is running to the following policies:
Act as part of the operating system
Adjust memory quotas for a process
Logon as a batch job
Logon as a service
Replace a process level token
-Add the job owner (the account with which the job runs) to the following policy:
Logon as a batch job
-Set LogOn As User to Yes
-Just in case, restart the agent service (not needed, but who knows)
This is only to rule out LOAU being the culprit.
Thank you Mark and Gonzalo for your responses. Unfortunately, since we weren't able to get the job to work via Control-M, the customer ended up using Windows Task Scheduler instead. It wasn't worth the time and effort for something that would only be around for 6 months.