I have an I-Way server set up and running (7.6.6 on NT2003) that will show jobs in the schedule, but simply refuses to run them. It's like a petulant child that won't budge. I've restarted a dozen times, I've recreated the log and statistics files, it just says no. No log entries returned.

Any help? I have to set off a job at 11:30pm each night because this thing refuses to do its job.

J

This message has been edited. Last edited by: John_Edwards,

Something simple that you probably already did but since you didn't mention this, first thing I'd do is check the SCHEDULER and make sure it's running. After that, I'd check the size of the log file. After you recreate it, it should be very small. Like under 100K small. If it shows something like 2GB, then it's filled up again. If that's the case, recreate again and again until it stops filling up. Finally, check the DFM_DIR directory. If you don't have anything running, I don't believe there should be anything there. If there is something there and nothing is running, could be a job got hung up. I've had that happen before (once) and I cannot recall what we did to fix it (I had a case open at the time). It may be as simple as deleting it but I'd check with IBI first. Maybe Clif is monitoring this forum and can add more.

John,

Your probably going to have to turn on traces and read through the trace files that are generated along with the scheduler.log and service.log.

What repository are you using? If FOCUS then your BOTLOG or BOTLOG2 FOCUS file may have been corrupted (or full).

I would suggest opening a case on this one.

Cheers

Stu

Does the I-Way scheduler use the same files as Report Caster? Aren't those the files for ReportCaster?

J.

This is what I'm finding in the log --

11/24/2009 13:28:00 accepting FDS connection tcp=127.0.0.1:3571
11/24/2009 13:28:00 (ICM18766) Request does not exist. Please refresh the list of requests.
11/24/2009 13:28:00 accepting cmrpip000545 tcp=127.0.0.1:3572
11/24/2009 13:28:00 request by cmrpip000545 to authenticate user
11/24/2009 13:28:00 validated cmrpip000545 u=caroot
11/24/2009 13:28:00 request by cmrpip000545 to list all deferred requests
11/24/2009 13:28:00 disconnect cmrpip000545
11/24/2009 13:28:00 disconnect FDS

That second line looks suspicious, but I cannot find anything on it in google.

You mentioned the i-Way scheduler. Since I've seen posts from you pertaining to Data Migrator, I assumed that is what you meant. Is this Data Migrator or something else? Services Manager perhaps? If it's Data Migrator, check out case #42762515. This was a case I opened years ago and forgot about it. Basically, we had different ID's we logged in with. We did this because we needed different APP PATHs for different ID's for security reasons. The ID I scheduled the job under was not the "essential" ID - meaning it wasn't the ID Data Migrator was installed with. Until release 7.7, only folders that are part of the APP PATH for the "essential" ID are seen by the scheduler, so it never saw the job I scheduled under the different ID. The work around they gave did not work for us because, for security reasons, we needed separate APP PATHs. So we continued to run the job manually.

Other than this, check out these two cases (31582576, 41842558) and if that doesn't help, I think you'll need to open a case.

Wow, you're right in the pocket on that one. That's the kind of thing we're doing on this install. I've moved a test file around a bit to see if it would run in the core apps any better than the one it's supposed to be in but did not have any additional success.

I opened a case and they said that they're concerned about the ID that it's running under, so they may be having similar thoughts.

Thank you for continuing to working this problem. I may need to mail you a pie when all is said and done.

J.

Holy crap I figured it out. Here's the text I closed out the ticket with --

----------------------------------------


Ok, for the record that upper-case thing didn't fix the problem. But it did remove the warning message.

It did point me right to where I needed to look for the problem however.

THIS IS A PATHING ISSUE. The ID the server chose to run under did not have the routines in its path. They appear in the schedule log, but they will never run and apparently don't throw any sort of error to indicate they are missed (likely they're never examined when the scheduler kicks off.)

That problem with the app name showed me the path that was running for the I-Way server, and I discovered that it matched an ID that the I-Way server presumably doesn't use. When I changed the app path in that ID's profile and restarted, the server picked up the change and immediately starting kicking off the scheduled jobs. Why on Earth it was running under that ID was the next step in the process.

-- The I-Way server here is running under a local system account that does not have a server profile established on I-Way.

-- The scheduler is set to run jobs with the admin account, which has no app path information.

-- On the I-Way console, I proceeded to Workspace/Configuration/Configuration Files/Administration and discovered that there is a set of IDs set to have admin privileges on the service, and that this oddball ID just happened to be the first in line. The scheduler uses the first ID set in that string of IDs. In my case that happened to be an ID that was essentially decommissioned and when we cleaned up some pathing in various profiles my scheduled jobs that had run previously suddenly stopped.

-- Moving the main production admin ID to the top of this file and restarting now has the scheduler running the correct apps in the correct order, and all is functioning properly.

Thank you for taking the time and effort to pursue this issue. This turkey is CLOSED.

J.

Well, good for you John! Hopefully the change they made in version 7.7 will take care of just this sort of thing.