I strongly discourage the use of embedded sql, it has many disadvantages.

Sorry Theo but I don't agree at all.

The differences (disadvantageous or not) between Embedded SQL and Dynamic Queries have evaporated since few years now, please have a look to this article from @Benjamin De Boe :

New in 2020.1: the Universal Query Cache

In general, I advice to use the query type (Embedded vs. Dynamic) that best fit in given code pattern, for example Embedded SQL is very convenient for query that returns 1 row.

Or maybe you have other issues with Embedded SQL?

I think you are mixing hosts (production component) and jobs.

A host can be enabled or disabled, when a host is enabled there are a number (PoolSize) of jobs and each job has a status.

You can view/list the status/details of production jobs in the Management portal Interoperability -> Monitor -> Jobs.

You already know how to get if an host is enabled/disabled, to get the status of all jobs you can use the query Enumerate in the Ens.Job class, to test it:

Set rs=##class(Ens.Job).EnumerateFunc()

Do rs.%Display()

I'm not familiar with ODBC on Linux, however it seems that Caché is unable to use the configured DNS named "DSN".

Is that DSN properly configured and successfully tested in Linux?

For configuring ODBC, have a look to this "Ask AI" answer.

If you still have issues, I suggest to open a new question and provide detailed information on what you have configured/done and the results/errors you had.

it doesn't seem like the Results of the Class Method are coming back correctly 100% of the time.

This is VERY strange, I would add a test/check if an error occur testing SQLCODE and %msg after &SQL() to see if/when/why it fails.

When using embedded SQL you are not supposed to check/access a returned variable (ExtDisplay in your case) before checking for success/failure via SQLCODE variable.

If you need to check if the query found a row, you should check the SQLCODE value, not ExtDisplay  value.