RMSRAS

RMSRAS 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 software technology.

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 later releases.

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 NQDQ mechanism.

RMSClient

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, Rms32.dll.

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 server.

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 applications.

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 easily.

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 RMS customer!

New Applications

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 for updates.