8122 Datapoint Drive
San Antonio, Texas 78229
is a product allowing customers to implement a client/server
application architecture in a heterogeneous system consisting
of RMS servers and Windows
clients and this can be accomplished without making the large
investment it would require to move applications to some database
management system, which is the only alternative available to
achieve the same architecture. RMSRAS
allows true client/server
architecture without forcing heavy investment in very complex
Another great advantage RMSRAS
has to offer is it allows applications to be enhanced
via modern graphical interface without having to replace the
whole application. Applications can be modernized at whatever
tempo is advantageous. New functionality can be implemented
or existing interactive programs can be moved to a GUI environment
in any sequence required, with the assurance that the rest of
the application will continue to work and operate as it has
always done. This is the low-risk path to more modern systems.
The reason this product set is described as a "Client/Server
Environment" and not as a "Client/Server Tool" is that, it is
used at run-time for applications that can be developed using
almost any tool the customer wants. The product consists of
a client part and a server part. The purpose of these two components
is to provide transparent communication across a network between
an application's client and server components.
The degree of sophistication with which the product is used
can vary greatly - especially on the server side. In some applications,
the RMSRAS Server
itself may be the entire server component used, while in others
this piece of software may only act as a means of communication
between application components.
The RMSRAS product
set brings the advantages of the flexible RMS
application execution environment into the world of heterogeneous
systems consisting of RMS
servers and Windows workstations connected on a Local Area Network (LAN).
The RMSRAS Server
This is an RMS application,
executing as an independent task in an RMS
server. It will listen for client requests on the configured
network(s), perform the I/O operation requested, and return
the result to the client. In the current version, all types
of file I/O and RMS Pipes
are supported. Other types of resource access are planned for
For ISAM and AIM file access, the RMSRAS
Server will resolve all indexes locally, sending only
the actual data record back to the client, thus minimizing the
amount of network traffic generated. In this respect, it closely
resembles the functionality of the RMS
File Management Task (FMT).
Working on shared files, the RMSRAS Server will fully support
the RMS record level locking
(RLL) mechanism, as well as the older file locking through the
RMSClient is a Windows 2000/ Windows XP based COM component
that allows users to create, read, write, update and delete
files or pipes on an RMS node via a connection to an RMSRAS
server process executing within an RMS Operating System environment.
RMSClient executes as a local COM server and is a replacement
for the previous Windows client interface to the RMSRAS product,
The RMSClient product is composed of five COM interfaces: IRasDbio, IRasDirect, IRasIsam, IRasAim, and IRasPipe. There is also one library, Rms32.dll which provides backward compatibility for existing applications. The interface marshaling is free threaded and multi-threaded. Applications built using the 16-bit mode are not supported with this product.
This implementation of the RMSClient software has two important consequences.
First, the RMSClient software is not a program in its own right. You cannot
start an RMSClient
program under Windows and then engage the RMS
server in other operations. That also means that it does not
consume any resources, such as memory or CPU cycles, on the
PC as long as it is not being used. In order to use it, you
need to have Windows applications that know how to summon the
RMSClient routines in
order to gain access to resources on the RMS
server. Customers do not have such Windows applications today,
so they will need to initiate application developments in order
to be able to use this technology - unless applications are acquired from a software house that does this for them.
Second, these Windows applications customers can write using
any software development tool for Windows that has the capability
to summon DLL routines. Most software development tools for
Windows have this capability. That means applications written
in languages such as C, C++, Pascal, Visual Basic, or even PL/B
for Windows, can now access resources on an RMS
Many of these tools are very easy to use, allowing true Windows
applications to be developed quickly. Ease of use is also a
characteristic of the RMSClient interface. The logic and syntax used by the programmer have been designed to closely resemble that used in DATABUS.
This means that individuals who have written DATABUS programs
before will immediately recognize the syntax, and individuals
with other programming backgrounds will find it very easy to
understand and learn.
The RMSClient API contains routines supporting all types of
file I/O available in Standard DATABUS on RMS,
including all variations of ISAM and AIM access, and also including
variable length records and record locking. In addition, RMS
Pipe I/O is also supported. That means you can create interactive
communication between Windows applications and RMS
Communication from the Windows client to the RMSRAS
Server is supported on TCP/IP.
How to use RMSRAS
With a general type of tool kit like this one, there are numerous
ways customers can use it to enhance the value of their RMS installations.
The application scenarios mentioned below are listed in, what
is believed to be, an "ease of implementation" order....
New Functionality in Existing Applications
The great thing about this alternative is that the customer
can exploit the benefits of RMSRAS
without any change at all to existing applications.
The most typical example in this category would be where a customer
uses this technology to provide new information from existing
data by using the Windows GUI to present information in new
ways. Using Rapid Development tools, such as Visual Basic, customers
can implement such new application features very quickly and
Another possibility is to re-write one or more interactive parts
of an existing application to improve its functionality and/or
performance. There can be no doubt that many interactive programs
written for a traditional character based user interface can
be improved considerably by being moved to a graphical environment.
Users are asking more frequently for such improvements in their
current applications. Unfortunately, those requests, as they
come into the customer's MIS departments, are often presented
as requests for new applications, based on the assumption that
the old ones cannot be changed. This is one of the greatest
misconceptions surrounding our RMS
systems in such environments.
The great advantage RMSRAS
facilitates in these situations is that the users can
get their GUI functionality without having to change the entire
application -- everybody wins. The customer's MIS department
(or application RAS) wins because they have a lot less
work implementing changes to the application front end only,
the users win because they will not have to learn a completely
new application, only some positive changes to existing concepts,
and the customer's business wins since they get improved, modern,
systems at a lot less cost than any alternative. And besides,
Datapoint U.S.A., Inc. wins as well since we get to keep our
Using RMSRAS, customers
creating new applications will have a lot more options open
to them than what they have had so far.
One fundamental advantage they can draw on is the fact that
even for new applications, RMS
can be a viable server alternative. This should be an attractive
option in many ways. An RMS
server is a secure, stable, reliable and well known server environment.
This is not always true of other candidates for the server role.
So why not let RMS continue
to do the job it does best - act as the server - even for new
applications? Some might argue that the "proprietary" nature
of RMS will still prevent
this from happening, but there are two main questions individuals
with such perceptions should ask themselves. (1) Is
RMS, after all the recent changes to the product,
really as "proprietary" as they think, compared to
some of the more easily accepted alternatives? The answer to
that question might be "no". (2) If the answer to the first
question is a weak "yes", how important is that really, compared
to the reliability of an RMS
system in a server role of a business critical nature?
Integration Between RMS
and Windows Applications
There are plenty of applications being offered on the market
that are of interest to customers. Sometimes the usefulness
of such applications might even be enhanced if they could be
integrated, one way or another, with the current ones. Such
integration is made a LOT easier when a tool like RMSRAS
is available allowing the customer to use commonly
available programming tools for Windows to design a link between
the two. For example, we could imagine a small program communicating
with the Windows application using a readily available Windows
mechanism, such as DDE or OLE, bridging the gap to the data
stored on the RMS server.
This could be used for simple data lookup operations, or even