vscode-ibmi: SQL query runner needs to take chosen ASP into account when not set at a user profile level

@worksofliam @Wright4i Sorry for not having done anything about this yet - except for creating a to-do list… 😄 I have been quite busy the last month both on work and in private, but I hope to start looking at this soon - if not anyone else has begun working on this issue…

@chrjorgensen @Wright4i First off, I thank you deeply for looking into this problem. I am very sorry because I am so worked right now and I am neglecting how much time I’m putting into it. I hope this can change in the next two weeks after I have some work travel out the way.

Next, to your question:

we can probably make a function setCurrentIASP

This is a very good idea, and we should make use of the existing ASP property in the configuration

present the current and available iASP’s in a list

Also a great idea. I am envisioning a simple quick pick list for this. We actually go and fetch the ASP information and store it in the connection class so we already have that idea.

I think we need to combine those efforts, with the change I recommended above:

But, to fully support ASPs, we need to ensure the user has SQL enabled (which is true most of the time since we are now using system programs to run SQL) so we can make use of QSYS2.OBJECT_STATISTICS in an statement where we can define the ASP to use. This requires a change to getObjectList to support the use of SQL.

The real heavy lifting here is adding the ability to specify an ASP name on IBMiContent#runSQL and then refactoring the calls to it. When this happens, the interface to code-for-ibmi.runQuery cannot be broken due to compatibility to other extensions.

I think if there is only one ASP (as in just *SYSBAS), then we likely don’t need to add anything to the UI to make sure the UX is not affected.

To @Wright4i’s point:

SETASPGRP isn’t even a viable option with the way the new jobs are spawned for each command.

Code for IBM i is stateless, so we’ve had to build our entire extension like this - the way ASPs would work is exactly how the library lists work… we have to send it in on every command - luckily we can easily do that with the system SQL program we use:

system "call QSYS/QZDFMDB2 PARM('-d' '-i' '-t' '-r' 'IASP1')"

I think I need to create an user ASP on my test system…

Looking back on this again. I am still thinking we need a button/API on the User Library List view to switch ASP group, which would really create a unique JOBD for that user (that we manage) so we can set/change the ASP group.

@chrjorgensen I believe you’re correct on the action items from @worksofliam.

On your issues:

1. Agreed, we should call validateLibraryList
2. Yes? If we’re treating ASPs like the library list works and library lists part of the profiles then iASP should be too.
3. No idea I’ll leave this one to @worksofliam

No additional thoughts here! I’m also a bit over worked these days so Fridays aren’t a good day for new ideas 😆 but everything listed here so far sounds good to me. Happy to help out (testing, etc.)!

My testing brings the question: Should it be the job description on the server that controls what Code for IBM i can see on the server, orr should Code for IBM i try to attach to an independent ASP using the SETASPGRP command?

@chrjorgensen I agree with you it should be on the JOBD to describe the job. SETASPGRP isn’t even a viable option with the way the new jobs are spawned for each command. If we go this route I think it’d be completely fair to just document how to setup a Job Description using an ASP and leave it up to the end-user to setup when configuring Code for IBM i.

The real heavy lifting here is adding the ability to specify an ASP name on IBMiContent#runSQL and then refactoring the calls to it. When this happens, the interface to code-for-ibmi.runQuery cannot be broken due to compatibility to other extensions.