I agree that 24x7 has a lot more functionality than the Windows or UNIX schedulers, that's why we want to use it. However, it DOES have some correctible shortcomings which are frustrating. We do not really want to create script jobs, we want to have the scheduler running as a service, yet monitorable and configurable via a GUI. We don't want to have someone at a programmer level administer the jobs, we would like to administer as much as possible via an NT systems adminstrator position. This means that the scheduler should present as much information and be as configurable as possible via it's GUI. If it's possible to have jobs impersonate users by running a script job where the only command in the script is "runAsUser " then it should be possible to add another screen to the job configuration wizard that allows the user credentials to be entered, and then have that job run as a separated process under the user's credentials. Sounds like an easy feature to add to the next version! Same for running complete jobs, build the functionality into the interface, don't require a script causing another instance to run with command line parameters, that should be handled internally. if we wanted to do complex coding we would run perl scripts via cron. Regarding the display of time to run information, the technician monitoring the scheduler needs to be able to see job related information in the console without running reports, he needs to be able to glance at the console to see the job status (similar the console in Backup Exec, if your familiar with that product). I'm sorry your current monolithic architecture makes this difficult, however I'm sure you can see that if the schedule service itself can figure out when a job is going to run, and the stand-alone instance can display the time-to-run column in the grid view when the serive is not running, then it should be possible to construct a stand-alone client that is not running the engine that could query the engine running in the service to obtain and display the same information. You have a decent product here, I'm suggesting you could sell a lot more if you made it more administration as well as progammer friendly. This might be accomplishable by moving away from a monolithic stand-alone instance orientation and towards more of a client server orientation for the 24x7 service. : Please note that only a separate process can be impersonated. Jobs are not
: separated processes and so they cannot be impersonated, at least through
: their properties. However, here are some tips on how you can do work it
: out. : If you just want to run a batch file or some other "external"
: process, create a script job and use
: RunAsUser "my batch file name her", … : If you want to run an entire job (with all scripts, emails, and other bells
: and whistles) use
: RunAsUser "24x7.exe /JOB [your job name here]", .... : Here is my 2 cents opinion on time-to-run and NT/2000 scheduler : Time-to-run information is available in the Job Forecast Report. Please also
: not that time-to-run is much more complicated than just the next run-time
: as a last one plus the recursion interval. It also depends on holidays,
: fails, reruns, timeouts, etc... So that in order to be calculated the full
: job scheduling and processing engine must be turned on and this is
: precisely what you don't want to have in the GUI console, this is what you
: run in the service. If you don't agree please let me know. : Now, about Windows NT/2000 scheduler, UNIX crons, etc... they do not have
: jobs. I mean they do not deal with jobs as complex objects with
: properties, instead they deal with is a single flat text file describing
: schedule to run some external processes. They spawn a process on the
: specified time and that is it. Don't even care to check whether it was
: successful or not.
|
