Could anybody provide some clarification on the Job Launcher flags as described in the Admin Guide?
The description of the -s flag is not very clear, do you supply a value?
It seems to me that use of the -w flag does not cause the launcher to wait until the job is complete but rather just checks the status of the job after -t millisec, at which point the launcher then returns. Is this an accurate observation and if so is there any way to have the launcher wait until job completion?
The reason for the above questions is that we want to schedule DI jobs using a 3rd party scheduler and have the status code returned by the launcher used to determine if the job was successful or not? Is this the correct approach or has anybody come up with a better approach to interfacing with 3rd party schedulers?
If I use -G"guid" (as generated by the export) in the al_engine parameter file to specify which job to run, then with the -w and -s switches set, the bat file that executes the AL_RWJobLauncher.exe waits until end of job and returns 0 or 1 depending upon job completion.
If I use the more friendly -s"Jobname" in the al_engine parameter file to specify the job name (instead of -G"guid"), still using the -s an -w switches, the bat file seems to time out (after about 5min) with a status of 180007 - GUID not found, status cannot be returned. The actual job continues running through to completion.
Obviously -s is a bit more friendly than having to look up the guid in AL_LANG.
It might be an internal thing. Would need to lookup the code. How do we identify a status of a particular job execution? I guess the GUID is involved in that and therefore it does work with the -G option but not with -s…?
When you export a job for execution via the job launcher, the export process generates 3 files, one of which is of the form di_repo_name.txt that is then in turn referenced via the -R parameter in the generated al_engine parameter file. This looks like some form of password file?
Are there any circumstances under which we would need to regenerate that file? We are using SQL Server with windows authentication for the DI Repo’s
When you created a schedule, the bat file had all the parameters in it required to execute the job, including the repo password. Now if the repo pasword changed you had to recreate all schedules which was fine if it is one job, but in case you 100s it’s no fun doing that each and every month.
So we added the option to the scheduler page to either go via the old method or read the passwords from a particular file instead. So now you have to change the password file just once and all schedules can remain as they are.
But as said, usage of that is driven by the end user choice. In case you are using windows authentication, you are not using passwords so the entire feature is of no use to you.
Following this discussion, is there an AL_RWJOBLAUNCHER option to indicate DI that we want to connect to the SQL Server repo with Windows Authentication, instead of user-password?
I’ve already tried to execute connect without the /U and /P options but it didn’t seems to work.