SOAP should write WTOs

Make SOAP Gateway enterprise ready by having error messages generate a WTO. This allows automation products, like SAOS390, to be able to take actions like trying to fix the problem or to alert a human. Similarly, any time an error has been resolved an information WTO should be put out so that validation of the automated correction can be performed. Of course, each of these should be unique, with the message text containing only 1 field that is variable for a given started task. This allows the automation product to determine the appropriate action without requiring needless parsing. An example of a bad message is one of the BPX message IDs that is used for indicating a file system utilization: it has variables for utilization percentage, aggregate name and file system name, and it is produced for a handful of different percentages; this requires automation to parse the message to determine the percentage to see if it is high enough for a particular action to be taken.

Based on our conversation, some installations may have the desire to toggle the usage of WTOs, but on a default z/OS installation, I would expect this to default to the way a well written z/OS started task operates: the default should be to produce potentially copious quantities of WTOs.

Examples of events that should produce WTOs:
i. Any error at startup time, such as being unable to read a file (or member), such as a WSDL, XML, properties, etc.
ii. That a connection with infrastructure, such as IMS Connect, has been reestablished
iii. Shortage of memory - or that there is no longer a shortage
iv. User configurable thresholding for how many of certain types of events within a time frame:
1. How many timeouts occur within a timeframe for a particular WSDL
2. Any error maintaining a connection with infrastructure, such as with IMS Connect.
3. A failure to connect to a remote server, such as defined in a WSDL
4. A failure to authenticate with the remote server
5. Any other message that would be useful but could flood the log
v. The task is starting
vi. The task is ready to take traffic
vii. The task has received a command, especially a stop, or force command
viii. The task has completed the action for the command it received
ix. The task has initiated the stopping sequence
x. The task is sufficiently down that if it gets cancelled that there are no concerns
xi. That an ABEND has occurred and has started being handled (such as starting to write out a SYSDUMP)