The %qparsets issue that you're seeing has been resolved internally and should be shipped as part of IRIS 2022.1.0

$system.OBJ.IsUpToDate()might fit the bill for your first question.

set sc = $system.OBJ.GetClassList(.classes)
set cls="", outdated=""
for {
    set cls = $order(classes(cls))
    quit:(cls="")
    if '$system.OBJ.IsUpToDate(cls) set outdated = outdated _ $lb(cls)
}
for i=1:1:$listlength(outdated) {
    write $listget(outdated, i)
}

should work for your 2nd question (documentation here: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic....)

Create a simple %Status like

set status = $system.Status.Error(5001, "This is an error")

and if you do 

zwrite status
status="0 "_$lb($lb(5001,"This is an error",, ....."

I cut out a significant chunk (...) because it's not relevant.

You can see that the first character in status is "0", that is because if you try a unary operator

+status, -status, 'status

 It will evaluate to the integer 0 and effectively work as a boolean flag. The part that matters is after the "0" inside the $listbuild.

The first element of $listbuild is the error code, followed by the message.

Because you set Test to 0 and nothing else, Objectscript recognizes that as a failure condition but has absolutely no information to provide beyond that. The recommendation is that you properly assign Test as a fully qualified %Status or change it to a %String where its value is equal to 

$system.Status.GetErrorText(/* some %Status instance*/)

If you run "jar -tf" onto the jar file,  does the directory structure of the jar file match example/KafkaBusinessOperation?

To unfreeze:

  • Do $SYSTEM.SQL.FreezePlans(0,1,,.Errors) // Unfreezes all SQL statement plans in the current namespace
  • Do $SYSTEM.SQL.FreezePlans(2,1,,.Errors) // Unfreezes all SQL statement plans in the current namespace that were marked Frozen/Upgrade.

Then execute $system.SQL.Purge()

That should unfreeze everything and delete all CQs.

The noted difference between %SQL.StatementResult.%Get() and %Library.ResultSet.%Get() is regarding the actual column names, not the values they contain.

Given that I am using InterSystems IRIS, but here is how I reproduced your example (I don't use a left-join, but they should behave the same)

CREATE TABLE testTable("Column A" INT, "Column B" INT, "Column C" INT, "Column D" INT)
INSERT INTO testTable VALUES(1,2,3,4)
INSERT INTO testTable VALUES(1 NULL, NULL,4)

-------------------------

USER>set stmt = ##class(%SQL.Statement).%New()
USER>set query = 1, query(1) = "SELECT * FROM testTable"
USER>write stmt.%Prepare(.query)
1
USER>set rs = stmt.%Execute()
USER>write rs.%Next()
1
USER>write rs.%Get("Column B")
2
USER>write rs.%Next()
1
USER>zwrite rs.%Get("Column B")
""

USER>do $system.Status.DisplayError(rs.%Get("Column E"))
 
DO $SYSTEM.Status.DisplayError(rs.%Get("Column E"))
^
<PROPERTY DOES NOT EXIST> *Column E,%sqlcq.USER.cls15

As you can see, %SQL.StatementResult.%Get() should only throw an error if you pass in an invalid column name such as "Column E" in the code snippet above.

I recommend that you check the %SQL.StatementMetadata to check if the columns exist in the first place.

USER>set rsmd = rs.%GetMetadata()
USER>set columns = $LB()
USER>for i=0:1:rsmd.columnCount-1 set $li(columns,i+1)=rsmd.columns.GetNext(i).colName

Once you have columns populated, you can use $LISTFIND to determine whether or not the column exists.

If you cannot do the above then you can wrap the use of %SQL.StatementResult.%Get() with a try-catch block as seen below:

while(rs.%Next()) {
     try {
         set var = rs.%Get(columnName)
     } catch {
         set var = ""
     }
}

I do not recommend the try-catch fallback assignment