On 2020-11-20 4:08 AM, M. Khalid Khan wrote:
When running TSO on a non-SNA terminal, does it use SNA/VTAM at all? Can one use TSO in this configuration with VTAM not running?
Again, I am not a network guy, but VTAM is an access method. Programmers code up VTAM macros in their VTAM application programs in a way such that users who have access to the VTAM network can elect to logon to that VTAM application (assuming it is running and VTAM deems the application to be? active etc. etc.).
SNA is a protocol - a series of layers IIRC - to allow application data to be transferred over the network.
VTAM applications such as TSO/VTAM could be logged on to by users from terminals that connect to the system via connections to the VTAM network.? Such connections might be SNA or non-SNA.? The VTAM application itself might not even be aware if a particular session is SNA or non-SNA.
The SNA protocol may enable a facility such that an ATTN key on a 3270 terminal can be transmitted inbound even if input is inhibited, but that does not mean that a non-SNA protocol supports the same thing.
For a channel-attached non-SNA connection - which is what most of us appear to use for our MVS 3.8 under Hercules TSO sessions - all we have to do is hit RESET and hit PA1, and then an attention interrupt is registered by our TSO session.
This scenario is what we used to call local non-SNA.? What we used to call remote non-SNA was usually BSC connections, but IIRC the reset-and-PA1 scenario used to work there as well.
With an SNA session, RESET will not clear the input-inhibited status, or at best will convert an X-SYSTEM to a "clock", meaning that a normal AID such as from PA1 cannot be sent inbound - hence the need for ATTN.
Perhaps a real network guy will step in and explain it properly...
Cheers,
Greg
