1. No idea - it also doesn't matter. The product isn't really needed today.
2.SNA - Systems Network Architecture. Think of SNA as the "equivalent" of TCP (IP) or UDP. In the traditional OSI network layer model, SNA embodies part of OSI layers 3 (network), all of 4 (transport), and most of 5 (session). My personal opinion is that on its best day, TCP/IP is inferior to SNA yet here we are. The unit of information (packet) in SNA was an entity called a PIU - short for Path Information Unit - and could be in one of several formats, "FID's", that each had a number, FID1, FID2, FID3, FID4, FID5 - etc. As a packet traversed the network, each PU (short for Physical Unit) in the path used the information in the PIU header to obtain routing and other information before sending the packet on to the next hop. It might also alter the PIU format from one "FID" type to another, depending on what it knew the next hop would be expecting. The physcal transport mechanism for SNA PIU's (equivalent to OSI layers 1 and 2), equivalent to today's Ethernet, would have been SDLC (Synchronous Data Link Control) (over "phone" lines), Token Ring (LAN), or even Ethernet (LAN). Physical transport involved "wrapping" the PIU's in additional information according to the "physical" transport being used. The total package, PIU wrapped in that physical link information, was called a BLU (Basic Link Unit). One reason I said that SNA is superior to TCP/IP has to do with writing code to use it. In SNA, if I code a "read" operation and I specify a length, then that read will not complete until I've received the full length. In TCP/IP, if similary I do a "read" for say, 1024 bytes, IP will give me "whatever it feels like" giving me at the time and if it's not the full 1024, then I have to keep issuing "read" operations, keeping track of the total length myself, until I get it all(!). How stupid is that? The SNA API supports both synchronous and asynchronous API calls (what the TCP/IP world refers to as "blocking" or "non-blocking"). The calling application code has the option of being paced into a wait state until the operation completes, or being able to continue "doing something else" and subsequently being notified asynchronously when the operation has completed.
3. None that I know of, in "today's world" none are really needed. These days for "3270" (green screen type) traffic most often you'll be using a TN3270 emulator package on your workstation (Vista TN3270 from Tom Brennan is my favorite and is one of the best ones out there). TN3270 communicates via IP to a TN3270 server running on z/OS or z/VM that handles the "translation" and acts as a go-between communicator on your behalf to whatever the ultimate end-point application is - CICS or TSO for examples - which are "mostly" using the SNA API set to communicate (current versions of CICS are aware that your 'terminal' end-point is IP and can obtain your IP address from the z/OS Comm Server IP stack). z/OS Communication Server today supports both SNA (VTAM) connections and TCP/IP - UDP connections. The TN3270 service runs as a component of z/OS Comm Server. When your remote "terminal" emulator of choice connects over IP to the TN3270 service running in z/OS Comm Server, it will allocate an SNA/VTAM communications ACB (Access Control Block) from a pool of them and use that to complete the connection to your target end point (aka CICS or TSO for example). Once the session is established, the TN3270 service acts as the go-between, talking to you via IP "out of one side of its mouth", and talking to the endpoint application via that ACB "out of the other side of its mouth". Note this is just for "3270" type traffic - aka terminal "green screen". Other types of traffic, FTP, SSH, iDZ, CMCI (CICS Management Control Interface) are all natively supported via the IP stack in Comm Server.