Open ThePrez opened 2 years ago
Possible name space colllision: https://en.wikipedia.org/wiki/Tc_%28Linux%29
Would you be duplicating cron or IBMi scheduler functionality that already exists ? On the surface it seems maybe 🤔
Would you be duplicating cron or IBMi scheduler functionality that already exists ? On the surface it seems maybe 🤔
Service Commander does a great job at running never-ending jobs/services. It can also be used to run batch jobs which doesn't run multiple times in parallel. So integrating none native languages with native schedulers is now very easy as you don't have to write a native wrapper for setting up the environment because you can very easily start the process through the STRTCPSVR command.
So I suggest not putting any scheduling feature into Task Commander. You just need a native way to start a task just like Service Commander does with STRTCPSVR.
Agree with possible duplication of other licensed programs. Now we all have the advanced job scheduler as well as the standard one, IMHO I dont think there is a need for another scheduling application. Having said that, keep up the great work with SC.
@m1h43l If you're referring to a native way to run any open source task this probably fits this bill: https://github.com/richardschoen/QshOni
You can schedule to run any QSH/PASE task from the standard IBMi job scheduler via the QSHEXEC and QSHBASH commands.
Not sure if that overlaps with Jesse's thought process or not.
You can schedule to run any QSH/PASE task from the standard IBMi job scheduler via the QSHEXEC and QSHBASH commands.
Yes, but Service Commander lets me configure the environment in a very easy way. Especially setting env vars is very important for me.
Can you share an example of what you need to set up for a single task like exporting a spreadsheet ? Addenvvar from CL or export from bash script seem to work for me. I'm just trying to picture what is missing for running tasks. As Andy said though, Jesse keep up the good work. We all have our favorite ways of doing things.
@richardschoen et al, what I was thinking is that a "task" would be YAML-defined, much like services are now, just without the check-alive components. For instance
name: Export sales data to spreadsheet
dir: /home/MYUSER/myapp
start_cmd: python3.9 ./export_sales.py
I wasn't thinking of creating another scheduler, just another way (among many) to tie into existing things. The benefit would essentially be a way to organize these tasks into a centralized spot, rather than having a bunch of possibly-disconnected CL wrappers or QSHONI calls, etc.
(still not asserting this is a great idea, just explaining my thoughts)
ah! apologies for going of on the wrong track.. it don't take much these days :-(
Like that idea of a task, I would find that very useful. 👍
@ThePrez Makes sense. If you create a Task Commander won't you have to have a scheduler behind it to kick off the task on a regular interval as well ? I guess what I'm saying is if you create a task, there needs to be some way to schedule it since I didn't recall ServiceCommander having an event scheduler. Or does it ?
@ThePrez Makes sense. If you create a Task Commander won't you have to have a scheduler behind it to kick off the task on a regular interval as well ? I guess what I'm saying is if you create a task, there needs to be some way to schedule it since I didn't recall ServiceCommander having an event scheduler. Or does it ?
You are correct. I have no interest in creating YATS (yet another task scheduler). One would use cron
, AJS, or job scheduler entries. Those entries would just run the new tool (maybe through STRTCPSVR or a new CL command)
Probably something like a RunTaskCmd
or RunTask
CL command maybe. STRTCPSVR would be too odd to run tasks. Or just create a Task Commander runner java app that can be called to run a task RunTask.jar "TaskFileName"
. Overall this still feels to me like you're recreating the ability to run shell commands (.SH) when parms could be put in a shell script as variables. With the benefit of yaml environment config files though.
Describe the solution you'd like
The idea would be to build and ship a supplemental tool to Service Commander, probably called Task Commander. Essentially, it can be used for running tasks that don't necessarily result in a persistent "service" job running. For instance, if there was a task to export a database query's results to an Excel file using Python.
The idea is that the existing
sc
capability is very powerful for routing to subsystems, setting up the environment, etc., but that we could leverage this logic for "tasks" as well as services. Presumably, we'd have a separate executable for this, probably namedtc
.Additional context
A number of design decisions would need to be worked out, including but not limited to:
$HOME/.sc/tasks
and/QOpenSys/etc/sc/tasks
Some additional features that could eventually be added might include: