SYSTEM REQUIRMENTS FOR CLAIMS

The following are the requirements for executing CLAIMS. Higher

values may yield better performance depending on various factors,

and in some special circumstances, lower values may actually

work, but are not supported.

1) A 386sx-class PC or better

2) Client operating system requirements:

16-bit character mode: MS-DOS 5.0 or Windows 3.1 or higher

32-bit character mode: MS-DOS 6.22 or Windows 95/98 or NT

32-bit gui-mode: Windows 95/98 or NT

3) Memory requirements: all numbers reflect the amount of memory that

must be available to CLAIMS

16-bit character mode: 512 KB free conventional

1,024 bytes free environment space

120 available file handles

32-bit character mode: 512 KB free conventional

3.1MB free EMS (expanded) or XMS (extended)

1,024 bytes free environment space

120 available file handles

32-bit gui-mode: 64 MB RAM

4) Disk Space required for programs

16-bit character mode: 30 MB

32-bit character mode: 45 MB

32-bit gui-mode: 65 MB

5) Disk Space required for data: 120 MB minimum (1 GB recommended)

6) OPERATING SYSTEM SPECIAL PARAMETERS

The following are in addition to the above requirements. These

vary with the combination of client and server operating systems

in use.

The most important issue with recent versions of Windows and

networking software is the introduction of write caching of data

at the client. This is a way of "cheating" to improve network

throughput. It is also a way to guarantee that data being shared

from a central server will get corrupted on a multi-user system.

YOU MUST DISABLE THIS DATA CACHING unless you are using a

client/server database such as Btrieve, DB2, Oracle, SQL Server,

etc.

Another performance improvement technique which is inadvisable in

most circumstances has to do with file and record locking for

handling multi-user updating of the database. The technique is

referred to as "Opportunistic Locking." If you use it, it will

become an opportunity to corrupt your database. It should be

disabled.

MS-DOS clients and DOS sessions under Windows 95 or NT running on

Novell 3.1 and higher servers:

- 90 file handles for the Novell client redirector

- For the Microsoft Netware client you must have an [NWREDIR] section

in the SYSTEM.INI with an entry below it of: READCACHING=0

- For Novell Client 32 and Intranetware client software change

properties as follows:

Opportunistic Locking: OFF

Cache Writes: OFF

Close Behind Ticks: 0

Delay Writes: OFF

File Cache Level: 0

Maximum Cache Size: not applicable when file cache level = 0

True Commit: OFF

WINDOWS 95/98 clients on Windows NT servers

- The windows file: VREDIR.VXD must be version 4.00.955 or higher

- Registry Key: DiscardCacheOnOPen must be set to true (1 hex). This

key is located in:

HKEY_LOCAL_MACHINES/System/CurrentControlSet/Services/VXD/VREDIR

WINDOWS NT servers: regardless of client, opportunistic locking must

be disabled; this is done by setting the Registry Key REG_DWORD

values shown below:

EnableOpLockForceClose set to 1 (the default is 0)

EnableOplocks set to 0 (the default is 1)

These settings are located under:

HKey_Local_Machine/System/CurrentControlSet/Services/LanManServer/Parameters

SPECIAL NOTE:

Windows versions prior to Windows-for-Workgroups (a later release

of version 3.1) are NOT capable of multitasking DOS sessions or

running DOS sessions in the background. When you leave the window

or minimize it, the session gets suspended by Windows.

Under Windows 95 there is a property setting under the

miscellaneous tab for a DOS session. On this tab there is a

check-box item under the "background" label which says: "Always

Suspend". This MUST NOT be checked. If it is, your application

will be suspended when you minimize the window or switch to

another window.

If a running CLAIMS application is suspended you risk locking your

system since the multi-user database places locks on data at the

beginning of an update and unlocks when the update is completed.

In a suspended window, the update won't complete.

The Windows 95/98/NT-specific console mode runtime cannot be

suspended in the background since it is not a DOS executable.

Therefore we recommend you use it instead of the DOS executable

in a Windows 95/NT environment.