REV G2B and file corruption (RevG Specific)
At 29 JUN 2007 11:33:55AM Skip Hill wrote:
We have a client with a legacy REV G2B application running on XP SP2 workstations and the server is Netware Open Enterprise 6.5 SP05. The application supports about 30 users, and is run entirely off a shared network drive letter. There are no REV files on any client workstations.
This application has been in production operation for 20+ years, with few file corruption issues. In the last year or so, file corruption has occurred with increasing frequency to the point of almost daily problems. The problems appear as "broken" LNK files in an increasing variety of the hundred or more LNK files that comprise the application database.
We have developed applications in REV, AREV and OI over the years, and are familiar with the environments and their use of the Linear Hash file system. So we have our feet on the ground, but do not have extensive experience in transitioning REV environments through server and workstation operating system changes.
The following facts are known or have been observed about the environment and the corruption problems.
1. The original configuration was Netware with Windows 3.1, then Windows 2000, and finally Windows XP SP2. The application was stable before the introduction of Windows XP SP2.
2. The underlying enterprise network began eliminating IPX support about the same time that Windows XP SP2 was introduced. The current environment has no IPX support.
3. The workstation network driver has always been Novell Advanced Netware.
4. Among the files that have broken, we have seen essentially read-only files break, such as program libraries, as well as small to large LNK database files. Where small LNK files have broken and subsequently converted to ROS files, perhaps obviously, those files do not break again.
5. MEMFIX is the only client workstation TSR or utility being utilized.
6. We have only recently implemented a configuration change that will prevent users from terminating their DOS application window instead of exiting the application normally. We know that such terminations CAN cause corruption, we don't know yet if this change will reduce the frequency of problems.
Perhaps there are still some REV experts out there that have had experience supporting applications through the advancing technology of Netware servers, Windows client operating systems and changing network protocols. We are seeking knowledge or experience that might answer specific questions or indicate a direction to take toward resolving the problems and stabilizing the system.
1. Is IPX support critical to problem free operation? Even without it, we have verified that fundamental record locking works as expected.
2. Are there general considerations for sizing LNK files that minimize the potential of breaks? While we are aware of modulo, sizelock, and threshold parameters for AREV, and the potential for a client workstation to "trigger" file resizing even with read-only select/read operations, there is apparently much less control available in REV. For example, does experience dictate that larger more sparse LNK files are less subject to corruption, or the opposite?
3. Are there PIF settings or DOS environment utilities beyond MEMFIX that are critical or known to be helpful in minimizing corruption? We are aware of the tendency of REV to
4. Is there an alternative network driver, such as the GENERIC DOS 3.1 NETWORK driver, that is known to be more reliable for a Netware server, or is a Windows server platform required.
5. Is a Windows server platform, such as Server 2003 known to be more reliable in combination with other things (like the DOS 3.1 driver)
We recognize all this may be more than anybody wants to read and consider. Any comments, observations or suggestions will be appreciated. We will also be pursuing this with Revelation, their Developer Network and other technical support alliances.
At 29 JUN 2007 12:19PM Warren Auyong wrote:
LNK files are more or less optimized for the Netware driver but will work with the other network drivers which use a byte-range locking scheme. ROS files will not lock in a shareable fashion on a multiuser environment and should be used only for read-only files.
Are you using Novell's client to attach to the Novell server? Which version? If a Novell client is installed on the workstation disabling client side caching might help (as recommended by Novell for DB apps):