Closed szsascha closed 1 year ago
An awesome idea!!
I think we'll need a way to fetch the job list from both SQL and outfile (for when SQL disabled / db2util is not installed.)
Also, maybe we could disable the feature if SQL is not enabled?
What do you think?
@worksofliam
Thanks for your feedback. I think the power of SQL will safe us a lot of work here. But you're right. What do you think about just using outfile?
But yes. The other alternative would be to disable it at all if db2util isn't enabled, as you suggested.
Maybe we could start with the "hard solution" and disable it completely if db2util / SQL isn't available until the first bug issues are popping up. Then we can still decide what todo.
@szsascha maybe the next step is to define the possible SQL statement to fetch the job list.
Any in mind?
@worksofliam
In the past I got very good results with the ACTIVE_JOB_INFO UDF (https://www.ibm.com/docs/en/i/7.3?topic=services-active-job-info-table-function). Would also use it for this.
I think we should approach from what we want to show in the job browser. The first version could show the following information:
In another issue you wrote that you're planning to show object information as a json. Maybe it's also suitable for jobs. Showing job information, librarylist, etc.
@szsascha
So there are two parts to this:
How does that sound?
@worksofliam
Sounds great!
@szsascha I will assign to myself and get to work on this!
I work on:
The next step is adding the capability to add a custom filter like Object Browser.
I'm late to this discussion and generally I keep a 5250 iACS session open any way, but here's a thought.
From what has been said, you are planning to front end a number of IBM UDTs and UDFs. So, for a more general solution, how creating a list of SQL statements that could be run.
Each statement would have a meaningful name,
Each statement would have promptable parameters which would be substituted into the SQL statement
A set of standard SQL statements would be provided. People could be solicited to contribute. There would be an option to refresh the standard set.
There would also be a private set where the the user could create their own SQL statements from scratch or copy and modify one from the standard set.
Where to keep the SQL statements?
I think the user set should just be a directory/file structure. The location would need to be initially specified, but this would allow sharing by others. It also allows all the editing capabilities of VSCODE.
Note that much of this is similar to what iACS does. I don't think is does promtable parameters.
Is your feature request related to a problem? Please describe. Sometimes it can be pretty useful to see into some job informations while coding. I can't see the jobs in vscode right now. Maybe there is a functionality but I didn't found that yet.
Describe the solution you'd like A kind of job browser would be cool.
Describe alternatives you've considered The alternative is to use a 5250 client besides the extension
Additional context There are some pretty nice SQL UDF's to get the required informations.