Example 1: Windows NT

The customer in Example 1 is a medium-size bank looking for a system to manage its mortgage documents. The bank wants to start in its main branch office with a small system that eventually can be migrated to their S/390 mainframe.

In this first project the bank will have 30 users working on the system. The users have Windows-based workstations, and the departmental servers are Windows NT. The communication protocol used on the Token-Ring LAN is TCP/IP.

These 30 users process about 20 mortgages per day. They group all documents about each mortgage in a folder. Each folder has about 10 documents with 2 pages per document. Some of these documents come from word processors, others from e-mail. But most of them are paper documents that must be scanned and stored. One of these documents is a legal document that may contain more than 50 pages.

The bank has a well-defined business process, and the time between when the client asks for the service and the mortgage is granted or denied is never more than 90 days. During this time quick access to the documents is essential. It should take no more than 5 seconds to see the first page. When the users close the folder, all documents can be archived in a slower device. This migration must be done manually by the user, not on a time-scheduled basis.

The legal documents represent a special case. The users want to save all of those documents, but they know that the time to retrieve them could be

excessive. So they decide to create two different documents: one with the first three pages (90% of the time they need only those pages) and one with all pages. The document with all pages can be archived directly into a low-cost storage device.

When a folder is closed, it must be stored for as long as 20 years, until the mortgage ends. Then it must be stored for another five years for legal reasons.

Sometimes a folder is required in the next 10 days after it is closed. So they decide to maintain the closed folder for 10 more days in fast storage before the system migrates it.

Finally, the bank does not want to use the VisualInfo client application. It wants to develop an application integrated with its Lotus Notes workgroup environment.

4.1.1 Analyzing the Storage Requirements

The first thing to do is to determine the space requirements for the storage system. The best way to make such a determination is to take some real documents from the customer, scan them and find an average size for each kind of document. Suppose that each document has an average size of 100KB, so each folder is 1 MB in size. We need space for 90 days of work; if 20 folders are processed each day we need 20*90*1 MB = 1.8GB of storage. Then we will define one volume of this capacity in DASD. Magnetic disks are required to achieve the 5-second maximum response time.

Every folder has a large document, about 50 pages in size, so about 2.5MB are required per document. Those documents are stored directly to optical disks.

The bank will need about 16GB per year of online long-term storage, and the best choice is an optical library. So the documents are migrated from DASD to optical disks. Some documents must be stored for more than 20 years, and the reliability of optical disks helps guarantee that information will not be lost.

4.1.2 Defining the Migration

One of the most important requirements is that the bank wants to migrate the documents when the folder is closed, not after waiting for a number of

predefined days after being scanned. This is not a standard feature of VisualInfo, but we can use one of the SMS APIs to meet this requirement.

Note: A similar result could be obtained by reindexing into an index class associated with collection A.

We can define two management classes with these properties:

1. MGTCLASB

• Storage class FIXED with retention period of 90 days 2. MGTCLASA

• Storage class FIXED with retention period of 10 days

• Storage class OPTICAL with retention period of 365*20 days

When the documents are indexed, they are assigned to MGTCLASB. We have defined a retention period of 90 days because all of the documents are

processed in less than 90 days. If some documents are not processed in 90 days, they will remain on magnetic disk because there is no other storage class defined for migration.

When a user closes a folder, we change the management class of all its documents to MGTCLASA. The documents will stay on DASD for 10 days and then are moved to optical disk for 20 years. You can define a retention period of FOREVER, if you are sure that you will never need to migrate the documents to a third storage class.

The change in the management class can be made with the

SimLibChangeObjectSMS API. See Appendix A, “Updating SMS Parameters through APIs” on page 189, for the use of this API.

Note: A similar result is obtained by reindexing into an index class associated with collection B.

For those big documents that are seldom accessed, we define a management class with storage class OPTICAL and a retention period of 365*20 days, so those documents are stored directly into the optical library. We will use Write Once Read Many (WORM) optical disks to store the documents because we will not have to modify them, and WORM disks are less expensive than R/W disks.

Note: Be careful when destaging directly to optical. This can impact your performance and use more system resources. See B.1.5, “Object Server Performance Tips” on page 194.

Figure 41, Figure 42 on page 56 and Figure 43 on page 56 show charts of the SMS objects. First, look at collection B.

Figure 41. Properties of Collection CBR.CLLCTB

Next, look at collection A.

Figure 42. Properties of Collection CBR.CLLCTA

Last, look at collection C.

Figure 43. Properties of Collection CBR.CLLCTC

To configure this example in our VisualInfo system, we have to create ADSM objects and VisualInfo SMS objects. See 5.8, “Configuring Example 1” on page 76, for a detailed description of this configuration.