I wanted to post this to save others the days of troubleshooting it took me to resolve our issue.
Data Services Server: 14.2.6.1082 (Windows Server 2008 R2)
Data Services Designer: 14.2.6.1082 (Windows 10 x64)
We had a power outage and shortly afterwards we noticed that our job server stopped working on our clients. After many days of reading, I finally found this article (https://bobj-board.org/t/165545/14) that mentioned to look at the AL_MACHINE_NAME table of the repository. I noticed that our job server name was not fully qualified (FQDN) so I added our domain name and the job servers worked again on our clients.
++++++++++++++++++++++++++++++++++
Error messages received:
Executing a job
“The job server you selected is not working.”
Exiting Tools | Options menu
"The Job Server is not responding. Cannot save modifications to the job execution options. Make sure that the Job Server is running and accessible from the Designer, and then make your changes again. (BODI - 1260016)
I solve a good number of problems by being able to directly query and manipulate the data in the repository tables themselves.
FYI, making copies of repositories for upgrades or just a working copy, goes a lot smoother if you clear out AL_MACHINE_INFO before you start using the new repository on a different server.
We’ve had a lot of problem when we tried to use tha same repository in a new server machine for testing purpouses. Especifically, if we restore a working repository of our production enviroment in another server. The main issues , after correcting the DS configs to TEST DBs, were related to executing job in one job server but finding out that the object were read from the original repo in production thus executing queries (or worst, modifying data) in the DB where the Prod DS were configured.
With your answer, do you mean that cleaning (truncating) AL_MACHINE_INFO coud solved this issues?
BTW, what we found in those cases is that the best approach was to create a new repo in the new enviroment and import a full ATL export of the production Repo (via al_engine).
Yes, once you clear out that table then the new job server won’t try to run the job on the old server. I clear out all rows when moving or copying a repository from one job server to another. I just did this a couple weeks ago to set up a new development environment for a client.
If you use the Export Execution Command to create a batch file so your scheduler can run the job then you MUST create a new batch file because the server to run the job at is embedded within the batch file.
(BOB member since 2013-06-17)
(BOB member since 2007-09-12)
(BOB member since 2006-02-02)
(BOB member since 2007-09-12)