- Any programmer can use the high-level
DTS API and build solutions based on real-time communications.
With DTS, the programmer doesn't need any skills with communications
programming or lower level communications interfaces, and
can concentrate solely on building and testing the application
- The client program can with a single call to the DTS API
program handle the entire query or update transaction including
the opening and closing of the network connection.
- The time to build and test the application is shorter
because the communications part of the application (DTS)
is already available and tested. The result is a more reliable
solution with less cost.
- Exchanging data messages between the applications is
an optimal way to communicate. The communication stays simple
and effective and facilitates optimal use of system and
line resources leading to optimal throughput and response
- DTS makes the location of the server application and
the used communications technique 'transparent' to the local
application. The local application can call and start remote
programs as easily as it calls and starts local programs.
- DTS is so robust and easy to use that development projects
have always been successful.
DTS makes it possible for any programmer
to build solutions based on distributed processing and real-time
communications. No communications programming skills are needed.
DTS makes the location of the remote
application 'transparent' to your application. Calling a remote
program is as easy as calling a local program. The remote
server application doesn't need to be active, because the
local application (actually the DTS server program) wakes-up
the remote application when calling it through the DTS client
DTS provides the necessary communications
code and has been tested in hundreds of applications over
several years. Thanks to this, programmers can concentrate
on developing and testing the application logic itself - no
communications programming or related testing is needed.
DTS is a middleware software built over
the well-defined and widely used communications programming
interfaces such as SNA/APPC, DECnet, and TCP/IP. Exchanging
data messages with DTS keeps the systems 'loosely' coupled,
because only user data are exchanged between the systems.
This means that communication based on DTS is very seldom
affected by the changes in the operating systems, data base
management systems and other system environments.
The distributed processing type of communications
used in DTS allows optimal way to maintain and access distributed
databases in multi-platform and multi-vendor environments.
Data entry is needed only once in one system, and the data
can be sent, processed, and saved in the other systems in
With DTS, the user interfaces of the
applications used for the data entry, query and update operations
are defined in the local applications providing an optimal
user interface for the local users. Security controls can
be maintained in DTS and on the application and object levels
so that no user id maintenance is needed in the server site.
This can be a substantial benefit when compared with the traditional
way to use remote terminal sessions for running remote applications
for remote database access.
The required line capacity is smaller
and the response time faster, because only the 'raw data'
(plus 39 bytes of DTS headers) and no screen formats or additional
protocols are transferred over the line.
DTS based on distributed processing and
exchange of data messages make it possible to optimize the
use of system resources: processor, memory, and use of line
capacity. Only the necessary number of control bytes, i.e.
39 per transaction in DTS, is sent over the line. Other methods
for real-time communications, for example, distributed database
communications uses longer headers and needs more control
traffic per transaction to maintain the database integrity.
You need to learn and do APPC, TCP/IP
socket, DECnet or other complicated communications programming.
Notice also, that programming in the OS/400 TCP/IP socket
interface requires ILE C programming skills.
Without DTS, you have to build the functions
for opening and closing the connection and sending and receiving
the data from the communications interface without forgetting
the related error handling routines. In multi-vendor environments
the ASCII/EBCDIC character code conversion routines are mandatory.
Spooling or store-and-forward functions
for the update transactions are practically necessary in real
environments. You should not either forget the logging functions.
The file transfer (record copy) features could also be useful
in your solutions.
All the above described communications
functions are already built for you. You can concentrate solely
on building and testing the application logic itself.