buzz@ncrcae.Columbia.NCR.COM (Buzz Bonnett) (12/20/89)
The latest releases of VTAM (V3R2) and the NCP (V5R2 or V4R3) support
peer-to-peer routing through the SNA Subarea backbone Network provided
the Peers function as NT2.1 End Nodes(EN) and the FEP, running one of
the above mentioned releases of ACF/NCP is a NT2.1 Network Node (NN).
This type of routing opens up all sorts of possibilities in what was
formally a hierarchical network. With this type of routing , the remote
login/virtual terminal application becomes a matter of writing a
client/server pair of LU6.2 peer-to-peer applications.
I recently (3 weeks ago) did this for a potential customer. They had
IBM RT/PCs running AIX on a Token Ring attached to a 3745 Front End.
The NCR Tower was attached to the FEP via a satellite link. They
already had their remote login program running between AIX boxes and
the requirements stated that it also run on the Tower. Here's the
block diagram of what was done:
RT/PC (machine A) | NCR TOWER (Machine B)
+----------+ +---------+ | +------------+
| keyboard | | display | | | /bin/login |
+----------+ +---------+ | +------------+
| A | | A
V | | V |
+----------+ +---------+ | +-------+ +------------+ -+
| RL | | RLTERM | | |RLSERV | |ldterm/ptem | | Pseudo-
+----------+ +---------+ | +------|+ +------------+ |- tty
| A | |A A+------->|Master/slave| |subsystem
V | | V| |-------- +------------+ -+
+-----------+ | +--------+
| LU6.2 | | | LU6.2 |
+-----------+ | +--------+
| NT2.1 |<--------->| NT2.1 |
+-----------+ | +--------+
|
>Bob Pasker of San Francisco write:
> Unlikely, since Lu6.2 is a peer-to-peer application protocol which is
> designed for client-server type of transaction processing...
Which is exactly why it would be used for this case. LU2 (3270 Data
Stream) works well for host oriented BLOCK mode transactions, but for
character oriented terminal applications between UNIX boxes LU2 is not
the answer.
So for the curious, How does it work:
Client machine A is running the remote login application naming the
remote machine B, ie the Tower, that it wishes a conversation with.
The NT2.1 in machine A sends out a BIND requesting a session with
machine B. Remember both machines are attached to the FEP. The FEP
gets the BIND request from A and (after performing some address
translation magic) passes it on to machine B. Once the Positive response
to the BIND is sent back from B to A and the two are in session, machine
A sends out the FMH-5 Attach requesting the activation of the RLSERV
transaction program at the remote machine B. The LU6.2/NT2.1 subsystem
then loads the RLSERV application. RLSERV opens the pseudo-tty master
and slave devices. It then forks a child process. The child dups the
slave file descriptor to stdin,stdout,and stderr and then execl's
/bin/login. Meanwhile, to have a FDX path back to machine A, RLSERV
allocates a conversation back the other direction requesting activation
of transaction program RLTERM. (Note:I would not have done it this
way, but it was not my place to question the customer's design).
So, data read from the LU6.2/NT2.1 subsystem on Machine B is written
to the pseudo-tty master (and then to login and, subsequently, the shell);
while data read from the master is written back to the LU6.2/NT2.1
subsystem on the 2nd conversation. When logoff time comes, the RLSERV
transaction program detects the closing of the pseudo-tty devices and
deallocates both converstations and everything falls apart.
Any body with questions or comments can write me as I don't have a lot
of time (read none) to read the news anymore.
E-mail is:
buzz@IBMcomm.columbia.ncr.com
Buzz Bonnett
NCR Corp.
E&M-Columbia
Tower Networking Systems
3325 Platt Springs Rd.
W. Columbia, SC 29169-2203