Mapepire as SQL runner

[worksofliam]

Changes

Rips out the legacy SQL runner with Mapepire, which is bundled in the VSIX and installed as a component.

ILE command improvements

runCommand has a lot of new logic. We now we should do all compiles with SQL. This means no more system, no more standard in or standard out from system. Due to that, we no longer have access to the job log or spool file generated by the executed command.

runCommand has four steps now:

1. Set the library list (using qcmdexc - if required)
2. Execute the command (using qcmdexc)
3. Fetch the latest job log entries job log (using qsys2.joblog_info('*'))
   • I am not sure if this logic is sound proof, since we are depending on ORDINAL_POSITION and I believe there are some instances where it is not updated correctly from prior commands. The only way to get around that is to always fetch the job log even if it's not needed (skipDetail)
4. Fetch the spool file (using a complicated statement)

Due to this implementation, runCommand cannot really run asynchronously like system allowed. At the runCommand level, I have had to implement a queue system so that these sequence of events can only happen one at a time. This ensures the right job log and spool file is returned for the correct command.

To do

• Update build to run npm run dsc as part of VSIX build
• Ensure all test cases are passing under Mapepire
• Test different CCSID scenarios
• Remove/replace all liblist usage
• Ensure that the component is valid with the existing install from the database extension

How to test this PR

• Ensure the test cases pass

Checklist

• have tested my change
• have created one or more test cases
• updated relevant documentation
• Remove any/all console.logs I added
• have added myself to the contributors' list in CONTRIBUTING.md

[github-actions]

👋 A new build is available for this PR based on a651d6f.

• Download here.
• Read more about how to test

[sebjulliand]

I added a new connection settings:

I remembered this guy in Code for i Friday who could not use the Db2 extension because it would not let him use a secure connection (his LPAR banned all JTOpen non-secure ports.
With this setting, it won't be a problem.

[sebjulliand]

@codefori/core I pushed a few changes:

• Spooled files are now correctly retrieved (for actions only)
• A new connection setting allows to keep these spooled files on the server
• SQL Queries are logged to the output
• Libraries/Files/Members with variant character could not be displayed if CSSID was not 37
• The file created in QTEMP when source date support is enabled is now created or replaced in QTEMP

[worksofliam]

@sebjulliand happy to see test cases are passing. My user testing, which includes opening sources from the Object Browser, and running Actions, works as expected.

I did note this to do item in the PR:

Ensure that the component is valid with the existing install from the database extension

And the database extension still works as expected.

So.... what's left? 😄

[sebjulliand]

So.... what's left? 😄

@worksofliam not much, really. There are two things coming to my mind though:

• The RunCL request on the server side retrieves the QUALIFIED_JOB_NAME column which has been introduced through an update.

It's not a big deal, but I had a 7.4 LPAR with which I was unable to use which Code for i. I know one has to keep their LPAR updated, but that makes me think we'll need to update the prerequisites; or remove that column from the query on the server side.

• When I was trying to figure out why some CL commands were failing while fixing CCSID stuff, it proved to be hard to troubleshoot from VS Code because we were using runSQL with @ statements, and when the command failed, we could only get the last message from the failed command, which is sometimes not enough (hence why you build all that logic when calling IBMi::runCommand). We should be careful when using runSQL with @ statements in our code as the error feedback is not great. I added more output when calling a CL through SQL. But shouldn't the Mapepire JS client just return the result object instead of throwing an error when the CL fails? (the result object has a success field and the data field seems to hold the messages). What's your take on this?
• Note for later: the Db2 extension will have to be updated to not install the server component anymore once this is released.

That's all I have in mind for now...after that, I guess we can build a v3 pre-release so this can be tested at a larger scale 😁