Fix TSO prompt detection when HIDDEN field is absent from TsoReply response

[frankgiordano]

Due to network packet fragmentation or z/OSMF buffering behavior, the initial TSO prompt data (for example, the standard READY state) may arrive in a payload without the HIDDEN field being included in that same payload.

As a result, the Java implementation can fail to recognize that the TSO prompt has been received. It may incorrectly assume that the mainframe is not ready, skip the appropriate collection logic, and subsequently send a premature tsoReply.reply(), resulting in the IKJ566021 error.

Proposed Fix

Change the prompt detection logic to check only for the existence of the TSO_PROMPT item and remove the dependency on the HIDDEN field:

final JsonNode prompt = item.get(TSO_PROMPT);
if (prompt != null && !msgLst.isEmpty()) {
    promptReceived = true;
}

This treats the presence of a valid TSO_PROMPT block as the indication that the operation has completed, regardless of whether the HIDDEN attribute is present in that particular payload.

Comparison with Zowe Node.js SDK

The official Zowe Node.js SDK implementation follows this approach. It uses the presence of a valid TSO_PROMPT block, once data has been accumulated, as the completion marker rather than requiring the HIDDEN attribute to be present in the same response segment.

This makes the implementation more resilient to network packet fragmentation and z/OSMF response buffering behavior.

Expected Result

The Java SDK should recognize a completed TSO prompt even when the HIDDEN field is not present in the same JSON payload as the TSO_PROMPT, preventing a premature tsoReply.reply() and the resulting IKJ566021 error.