<
  Manycom DTS
 
Manycom Solutions

Home > Products > Manycom DTS > Benefits

 
 

Product Description

Contents
Introduction | Benefits | Technical Description | Cases and References | System Requirements | Prices | Availability and Support | Manuals and Documentation | License and Maintenance Agreements

Benefits

  • 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 logic itself.
  • 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 times.
  • 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 API.

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 real-time.

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.

Without DTS

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.

With DTS

All the above described communications functions are already built for you. You can concentrate solely on building and testing the application logic itself.

 
Top of the page