The Need for a Data Manager

For years, PL/B programmers have relied on our Indexed Sequential Access Methods (ISAM) or Associated Access Methods (AAM) to solve complex data storage and retrieval issues. Sunbelt has led the way with ISAM products that offered both balanced tree (B+ tree) and deleted space recovery logic. Our unique AAM access methods are far superior to other technologies available today for free form searches. These technologies are a mainstay of our product line and keep our PL/B products at the forefront of programming languages.

Using PL/B in a networked environment seems simple enough from the programmer's standhipoint. It can be completely transparent to the user whether the files accessed by the programs are stored locally or on the network server. The program simply opens the files on a redirected drive and the program behaves as usual. Well, almost... There can be that issue of performance.

On a small, lightly loaded network disk access times may not be apparent. This is especially true if high-speed network components are used. But, what would happen if that link was slower - perhaps it was even the Internet or, worse yet, a dial up Internet connection. Odds are that performance of any language would suffer in this configuration. That's not true with Sunbelt!

Let's start by examining what takes place during a normal ISAM read statement.

1. The program begins by passing the key of the record to be retrieved to the disk routine.

2. That routine starts its journey through the ISAM structure by reading the top level of the tree from the ISAM file.

3. The routine then determines the next level of the tree structure and reads that level from the file.

4. The process is repeated until the key is found in the lowest level of the index.

5. The lowest level of the index points to the location of the record in the data file.

6. That record is then read and the data returned to the program.

Next, we introduce the network to the process. The program works just as it did before. The important thing to note is that each of the index file and data file reads now take place across the network. Even on a lightly loaded network, this is many times slower than access the local drive. Combine this with a busy network or a slower link and you can see there might be a performance issue.

Now, we implement the same logic using the Data Manager. We begin by executing a test on the server called the File Management Task. This task sits and waits for a network request by an application. When the application performs a disk access, only the key is sent to the DMT. All the index and data file accesses needed to locate the record are done on the server by the Data Manager Task. Finally, the data is returned to the application. The result is that disk performance using the data manager across a network is on par with what you would expect with local disk access.

What about AAM you ask? It turns out that even though the Associated Access Methods have tremendous searching capabilities, most of what they accomplish are done through a "brute force" method of disk access. When comparing networked AAM access to managed AAM access the numbers are even more impressive than ISAM.