Kbase 9148: Additional Release notes for TLI
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  10/05/1998 |
|
Additional Release notes for TLI
910724-hwa01
There is additional information regarding TLI/Streams and
Remote Clients in the porting folder section TLI54stat.txt.
Tue, OCT 30,1990
PROGRESS TLI in UNIX SYSTEM V.3 and V.4
UNIX SYSTEM V.3
PROGRESS supports the TLI protocol on machines that have
UNIX SYSTEM V, release 3. This version of PROGRESS TLI is
completely dependent upon the TCP/IP protocol underneath
the TLI protocol. The advantage of using it for these machines
is that it may offer some device independence. In cases where
the TCP/IP version of PROGRESS has the device name hard-wired
into it as a result of loading the library routines for one
device driver, but the user is running with a different machine
with a different device driver, native TCP/IP will not work
correctly. The user will get an error message something like
"Unable to open socket, errno 2" which indicates that the
device name loaded into PROGRESS and the device name on the
machine do not match. TLI, unlike TCP/IP, allows for the
designation of the device dynamically. To support
this aspect of TLI in PROGRESS we have created a new parameter
-Nd <device-name>
to allow you to specify the device name when connecting to a
database. The syntax for the PROGRESS server or client is:
connect
proserve <dbname> -H <host> -S <service> -N TLI -Nd <device-name>
pro
where <dbname> = database name
<host> = the TCP/IP host name of the PROGRESS
server's machine from /etc/hosts
<service> = the TCP/IP service name of the PROGRESS
server process from /etc/services
<device-name> = the TCP/IP device --default is /dev/tcp
example:
connect demo -H hostx -S demosv -N TLI -Nd /dev/tcp
Because this version of PROGRESS TLI is not protocol independent,
but rather TCP/IP based, it is very easy to connect a TCP/IP
machine (-N TCP) with a TLI machine (-N TLI). The machine that
does not have TLI, but just native TCP/IP can connect through
the underlying layer of TCP/IP on the TLI machine in a way that
is completely transparent to the PROGRESS executables.
At this writing, the machines that have UNIX TLI Version V.3 are:
machine possible device name
DDE /dev/tcp
TOWER650 /dev/tcp
TOWER700 /dev/tcp
ARIXS90 /dev/stptcp
SCO386 /dev/inet/tcp
ATT386 /dev/tcp
UNIX SYSTEM V.4
PROGRESS also supports the TLI protocol on machines that have
UNIX SYSTEM V, release 4. This version of PROGRESS TLI is
device AND protocol independent.
The syntax for the PROGRESS server or client is:
connect
proserve <dbname> -H <host> -S <service> -N TLI
pro
where <dbname> = database name
<host> = some qualifying name appropriate for
the underlying network being used
<service> = some network name appropriate for
the underlying network being used
example:
connect demo -H hostx -S demosv -N TLI
In PROGRESS executables we are no longer locking in any
specific device names as in TCP/IP version V.3. In addition,
we are no longer making direct use of any TCP/IP library
routines. If you have two machines connected through an
underlying TCP/IP protocol, but are using the PROGRESS TLI "umbrella"
protocol to connect them in PROGRESS, you still have to insure
that someone has set up the appropriate /etc/hosts and /etc/services
entries, and your -H and -S parameters to PROGRESS will contain
those entry names. However, in addition to the hosts and
services entries, you will also have to insure that there exists
an entry in the /etc
etconfig file on your system that
describes the network you are using. This entry contains the
network name, the device name (e.g. /dev/tcp), and among other
things, a name-to-address-mapping dynamic library name,
(e.g. tcpip.so). The /etc
etconfig file is described in the
"Network Selection and Name-to-Address Mapping" section of
the AT&T UNIX SYSTEM V RELEASE 4 Programmer's Guide to
Networking Interfaces.
The PROGRESS TLI V.4 version reads through the /etc
etconfig
file and tries to find/create the network name you gave to
PROGRESS through the -H and -S parameters for each of the
networks described in that file. The order the file is searched
can be altered if you wish to define a NETPATH environment
variable (also described in the Network Selection AT&T
documentation). PROGRESS creates a nd_hostserv structure
using the -H and -S parameters passed it. For each entry in
/etc
etconfig, it invokes a TLI routine that tries to
get that name mapped to an address using the library (e.g.tcpip.so)
in the /etc
etconfig entry for that network. If it succeeds,
in then opens the device (e.g./dev/tcp) for that /etc
etconfig
entry, and binds the device to that address returned from the
name-to-address mapping library(e.g.tcpip.so). It then can
listen for connections under that address, or try to connect to
a server for that address, depending on what PROGRESS executable
you are running. The great benefit of all this is that PROGRESS
has no prior knowledge of the device name, or of the name-to-address
mapping algorithm being used -- presumably, with the right
/etc
etconfig setup, you could use TLI to connect from UNIX
to NETBIOS, SPX or X.25 networks, or any other TLI supported
networks.
TLI over TCP/IP networks:
Because PROGRESS can no longer assume that the TLI communication
is TCP/IP based, it is somewhat more difficult to handle
TLI to TCP/IP communication, and spawned servers can no longer
use on-the-fly port numbers as before, but must have actual
defined network names to use.
If you want to run TLI over a TCP/IP network, you will need some
new entries in /etc/services, one for each spawned server
you might need. For example, if your -S parameter for the PROGRESS
database is demosv and you are planning to have 3 spawned
servers (see -Mn parameter), then you will need the following
entries in /etc/services:
demosv 2050/tcp
demosv1 2051/tcp
demosv2 2052/tcp
demosv3 2053/tcp
If you give the parameter -S <svname>, the rule is that the
first spawned server will use <svname>1, the second <svname>2,
and the nth, <svname>n. It is up to you to create these entries
in /etc/services for each database you are running.
CROSS COMMUNICATION between TLI and TCP:
Because spawned servers under TLI will now be using a specific
name rather than a transparent on-the-fly port number as before,
you will have to make some modifications for any TCP/IP
partners that need to talk to a new TLI V.4.
To communicate you need to by-pass the TLI PROGRESS broker. To bypass
the broker:
CLIENT TCP pre-6.2g, SERVER TLI V.4
instead of connecting to the service name -S <svname> as
usual, just connect to one of the spawned servers directly,
-S <svname>n, for example,
proserve demo -H hostx -S demosv -N TLI
connect demo -H hostx -S demosv -N TLI (causes server
to be spawned
with -S demosv1)
connect demo -H hostx -S demosv1 -N TCP
TCP clients after PROGRESS 6.2g have been modified to connect
automatically to the spawned name instead of the on-the-fly
port, so the above is unnecessary.
CLIENT TLI V.4, SERVER TCP
Because the TCP server will be spawning servers with
the on-the-fly port, the TLI client will not be able to
talk to them through the broker, and you must also by-pass
the broker in this case:
Start a manual server on the server side, with a different
service name from /etc/services and the -m2 server parameter
which tells PROGRESS to start a server manually:
proserve <dbname> -S <svname> -N TCP
proserve <dbname> -S <svname>n -m2 -N TCP
Then connect the client directly to that server:
connect <dbname> -H <host> -S <svname>n -N TLI
Example:
proserve demo -S demosv -N TCP
proserve demo -S demosv1 -m2 -N TCP
connect demo -H hostx -S demosv1 -N TLI
SERVER -H Parameter:
The -H parameter has been largely ignored for PROGRESS servers
up to now. For new TLI V.4 servers, the -H parameter will be
required, since we can no longer infer what it would be by
using the TCP/IP host name of the machine.
At this writing, the machines that have UNIX TLI Version V.4 are:
machine
ICL6000
ICL3000
NCR3000
Progress Software Technical Support Note # 9148