Hi, Israc.

Yes, many HATS customers are running CICS transactions successfully.

I think the issue may arise from a misunderstanding of the communications protocol, and some incomplete information from your CICS programmers.

When one chooses to negotiate for contention resolution for 3270E connections, you are negotiating a contract between the host and the client. This contract says that the host applications will not unlock the keyboard until the host is completely done with its communication. The keyboard unlock will be the agreed-upon signal that the client is now free to send.

This contract is exactly what allows HATS (or other programs) to react so quickly to 3270 host screens. Without this contract, you are forced to use timing rules of thumb and other heuristics to guess when the client is free to send. With this contract, HATS knows for certain that the host application has officially turned over control to the client.

If one's applications return control and then immediately bid for control again, these applications will not operate properly with HATS or any other computer program that is trying to interoperate with them. It is not a problem specific to HATS.

Ignoring a null RU won't work, either, because a null RU is one of the most common ways for signaling the client's turn to send. It is a legitimate part of the communications protocol. If HATS ignored null RUs, you'd immediately cause the opposite problem--many screens that are now operating correctly would signal they are done, but the browser would simply continue to spin waiting. Even within your own shop, suddenly screens that have been working fine with HATS would stop working, and only those that were broken before would have a hope of being okay (though I'm not sure what HATS could do but just wait some amount of time and hope for the best). Actually, the ones that aren't working for you now may continue to fail, only later in the process because after the final transaction is complete, it might send a null RU, and HATS would ignore it.

The CICS programmers are correct that running transactions this way was quite common. They failed to mention, though, that this technique has significant exposures to terminal problems, and prevents the transactions from interoperating properly with other programs. I suspect that like most CICS transactions, nobody expected them to interoperate with anything when they were first written. Now that you have higher expectations of these transactions, though, they need to be altered to "play well with others."

A quick Google search for cics return immediate (the new technique) uncovers lots of information explaining the problems with the old technique. CICS Transaction Server for z/OS

Even your terminal users can cause your transactions to fail if they were to type at the wrong moment: Tips for CICS Application Developers They can even abend your job Send Receive Mode

In short, "Common? Yes. A good idea? Nope."

Perhaps an analogy will help to explain (I think better in analogies):

It is very common practice for men (and some women) to sit in their living rooms on the weekend yelling very rapid (and usually very poor) instructions at the soccer or basketball players on the television. It is a common practice and in this environment it is a harmless one since the video tube isn't expected to react to the instructions being shouted at it.

These CICS applications are the same. They are giving signals that somebody should "take the shot" even when the goal is nowhere in sight. Milliseconds after that, they then scream for the ball to be passed to somebody else. Both instructions cannot be right, but since these applications were only communicating with a dumb terminal green screen, it caused no real harm. The humans using the applications are up to 10.000 times slower than a computer system, and couldn't react to the contradictory instructions even if they tried. In fact, these misleading instructions come so fast the humans are not even aware it is happening. Common, hardly a best practice, but mostly harmless.

This same behavior when moved from the living room onto the ball field, however, is no longer harmless. While it might be common, it cannot be done while you are part of an actual team trying to play together. The results would be, as you point out, havoc. Your teammates will be completely confused and the entire effort will fail.