Provide error handler for secondary thread of multi-threaded job

When a multi-threaded job encounters an unhandled exception, the system should be able to gracefully handle the error with the standard *INQ message to *EXT or QSYSOPR.

Background
When an unhandled exception occurs in the secondary thread of a multi-threaded job, instead of displaying the *INQ message panel for user response, the job loops on the error, filling the job message queue and crashes.

It is very important to have the error handling stability that IBM i has always had.

This is a poor way for IBM i to handle errors. The standard way has always been for the system to send *INQ~ to *EXT or QSYSOPR for handling by the user.

This problem came up when an SQL user-defined function had been incorrectly created without the "not fenced" statement to indicate "run single-threaded". When the job ran, SQL started a second thread. The function tried to use commands and programs that were not coded "thread safe", and the system tried to send *INQ to *EXT, which looped and crashed

Possible solutions
1. Allow the *INQ message program and display file to be used in a secondary thread.
2. Send the *INQ to QSYSOPR for handling.

=====================================
Resubmission information 2017/05/15

Since the development team determined that a secondary thread cannot access the WS I/O, my suggested option #1 above, that being an *INQ message to the screen, is eliminated.

So then, option #2 (which was not addressed by the developers) is the logical way to correctly handle the error, by treating the secondary thread as if it were a batch job, in which case error messages are sent to the QSYSOPR message queue.