So I was checking our DR site’s webMethod instances, and found out that all of the scheduler on all of the instances were on suspended status. Which at the time, was horrifying, since a regular disaster recovery drill schedule was coming up very soon.
The webMethods console logged this error:
“ISS.0137.0034E – Unknown Service: xxx.yyy.zzz. Scheduled task will not run.”
The only thing that Software AG wrote on their very helpful *snigger* documentation is:
| Explanation | The service configured to execute for a scheduler does not exist in the Integration Server. |
| Action | Ensure that the service is available in the Integration Server. |
It also logged this:
ISS.0085.9110 No such service is currently loaded
Which Software AG has managed to provide absolutely zero explanation.
Well obviously, this is simply caused by -as the very helpful documentation has carefully stated above- the package revered on the scheduled task being missing from where it supposed to reside. Which is, to my very humble understanding, is a very trivial matter to solve, right? Well, I straight away open my Software AG Designer, and tried to locate the said package. And.. well I did it on my very first try! So the package is where it’s supposed to be, but the scheduler refused to pick it up. OMG scheduler! What did the “payment.scheduler” do to you or your dog? Tell me!
Anyway, to understand the whole situation, I did some sleuthing and found out a couple of things. First, I could create a new scheduler on the instance, but it will immediately get suspended for the exact same reason, the scheduler failed to find the service. Also, this problem was also happening to every instance on the server, hence I was not able to redeploy the package to another instance in that particular server. I was also unable to create a new service, and assigned it to a new scheduled task. Then I found this at the “create a scheduled task” window:
Strangely, the correct name of each corresponding instances are not listed on the drop down menu. Instead, I was given the choice to pick either “Any server” or “localhost”. The same thing also happened to all of the instances on this server. I then went on comparing these to the production instances, and surely, each instance on my production server are properly named on that particular dropdown menu.
Now, i am fairly new at managing webMethod Integration Server. I don’t even have a proper, formal webMethod IS training yet. But I do have extensive experience in administering services on top RHEL. Thus I approach this matter the way I do it with any other services running on top of linux. Try to find the corresponding config files 😀
The scheduler’s instance name is set through a setting in “instancename/config/server.cnf”. To add or change the scheduler logical name, first shutdown all of the instance currently running on the server. Open the config file with your favorite text editor, and find:
watt.server.scheduler.logical.hostname=
And change it to:
watt.server.scheduler.logical.hostname=InstanceName
Save, then close. Do this to all instance residing on the server. When you’re done adding the scheduler’s name to all of the instance, start them up again. Check if each instances are properly named.
The next thing you need to do delete all of the task, and recreate them all again. The services should be properly scheduled and executed 🙂