One last long-running theme (going back to the old Revelation forums), is how to avoid network GFE's on 32 bit Windows networks. Since I am still supporting ARev 1.16 systems, the Network Products have not been an option for me. Nevertheless, I have had fairly good luck, and I would like to share this and run a few things by all of you.

First off, out of the roughly 70 workstations running Win9X on various systems that I support, I have never found it necessary to shut off the write-behind caching. Is the need to do this genuine or is it an urban legend? I support systems with NT, Win98, Win2000, Novell 3.x, 4.x and 5.x, servers, without benefit of the Network Products. None of the networks exceeds 15 users, however. I have not found GFE's to be a problem at all on the Novell networks, as long as the Novell-issued clients are used.

On the Windows-server based networks, my experiences have been varied. I have a couple of networks that have NEVER experienced a GFE. I have a couple that DO suffer intermittent but rare GFE's in indexing files (and very rarely, unfortunately, in data files), and on several occasions I have experienced plagues of GFE's. These latter situations are almost invariably caused by one of the following: Use of real-time virus-checking software on the server; use of the server for a secondary purpose (such as sharing an internet connection); use of specialty disk controllers on the server (generally RAID, although a client with Novell 3.x and RAID 0 has no problems); failure to load IPX protocol on workstations or server; faulty hardware.

I have at least two networks running Win98 workstations and Windows NT servers that have NEVER had a GFE (knock on wood).

So, after all this, I have no doubt that the Network products make the networks more stable, and I am always nervous whenever one of my systems is moved to a new network, but over all, at least ARev 1.16 CAN run reasonably well on an Windows network without shutting off write-behind caching and without the Network Products.

I have three questions:

1. Is there any reason why 1.16 would be more stable than later versions or OI without the Network Products? (Actually, the use of the !INDEXING file in this version, the file that suffers the vast majority of GFE's when they do occur, would make it LESS stable, I think).

2. Is anyone else out there supporting networked ARev without the Network Products, and if so, are there additional suggestions for maximizing the chances of success in such an environment?

3. Re IPX on Windows networks. Of course, these days, you almost always have to have TCP/IP protocols running. ARev does seem to function when this protocol is the only one running, but more slowly than with IPX, and GFE's are virtually guaranteed. Almost always, simply loading IPX onto the workstation as well solves this problem. Why does TCP/IP work, but not well, with ARev. When both IPX and TCP/IP are available, how does ARev "know" to use IPX?

Thanks,

David Kafka

David ..

In response to some of your questions:

1. I think that AREV 1.16 was the last of the "hard-coded" releases which is what probably makes it the "fastest" version of AREV. The !INDEXING file was a bugaboo since all index transactions for all attached files were forced through it. Lock contention was always a problem and lockups generally caused GFE's there.

2. I support a number of "small" AREV/OI sites without the NLM or NT (Win2000) service on Win9x/NT platforms - generally less than 5 workstations. Since I migrated all of my AREV users to AREV 2.12 (as a minimum), I am able to use the NPP driver which goes a long way towards minimizing the issues of Opportunistic Locking and Write-behind caching. Write-behind caching without this is a genuine headache in machines with oodles of memory (64MB or greater) on Win9x platforms without the NPP driver. I've seen a lock released via an UNLOCK statement, but the data has not yet been written to the network. This is never a problem with non-networked single user installations.

3. IPX and TCP/IP protocol stacked simply depend on what server you are talking to. In general Netware uses IPX/SPX with a default packet size of about 1K (+packet overhead). TCP/IP will use a default packet size of 16K. The algorithm used to time-slice the packet decoding favors TCP/IP at the expense of IPX/SPX (which is why Netware can take a big hit). Another issue is frame type (802.2 / 802.3). Netware will respond to TCP/IP packets providing the server is setup to recognize them, albeit at a slower rate than IPX/SPX. Netware 5.0 and 6.x are supposedly much more efficient than 4.x and earlier. If both protocols are loaded on a workstation (as they mostly are), I normally recommend that IPX/SPX be installed ahead of TCP/IP and the default protocol layer should be IPX/SPX. A big problem that I've seen in performance is mixing 10/100 connections on the same leg. Timeouts (which result in all kinds of errors) seem far more prevalent here.

Don Miller

C3 Inc.

Q1. Is there any reason why 1.16 would be more stable than later versions or OI without the Network Products? (Actually,

the use of the !INDEXING file in this version, the file that suffers the vast majority of GFE's when they do occur, would make it LESS stable, I think).

A1. AREV 1.16 was flaky, especially in low memory situations, and with indexing. AREV 3.12 is undoubtedly the most stable and best featured version, followed by AREV 2.12. There were limitations on the TCL query size in 3.10, and the SELECT engine problems between 3.0 and 3.10. We recommend upgrading (wherever possible) to AREV 3.12.

Q2. Is anyone else out there supporting networked ARev without the Network Products, and if so, are there additional suggestions for maximizing the chances of success in such an environment?

A2. If you must do this, attach local LISTS files (assuming this is OK with respect to your app and LISTS is not addressed programmatically)

Turn off write behind caching in Win 98 (and any other version of Windows where this is possible). Not folklore - if the OS caches the LK and not the OV (or vice versa), and the file has heavy use, then the chances of a GFE are increased.

Q3. Re IPX on Windows networks. Of course, these days, you almost always have to have TCP/IP protocols running. ARev does seem to function when this protocol is the only one running, but more slowly than with IPX, and GFE's are virtually guaranteed. Almost always, simply loading IPX onto the workstation as well solves this problem. Why does TCP/IP work, but not well, with ARev. When both IPX and TCP/IP are available, how does ARev "know" to use IPX?

A3. The network driver (see WHO at TCL) determines the network specific features (eg. @station & locking calls) which are supported. These are different for every network. There is a standard DOS call (DOS int 21h function 44h if memory serves) which alerts the running program to the presence of network disk drives.

AREV doesn't use/support TCP/IP directly at all. AREV will use NETBEUI if present (so that drive mappings and devices are supported), or IPX if present.

The "All Networks driver" (NPP) on AREV on the workstation uses named pipes to communicate with the Windows 2000 / Windows NT service on the server.

IPX is (almost) exclusive to Netware. We still have some clients running 3.1x Netware servers with the AREV Advanced Netware drivers, over IPX. Rock solid, (especially in Payroll environment, with large reports, large data files). Pity that Novell rewrote the product in C and lost all their assembler gurus (and product stability). From then on they've been wrestling with Microsoft for NOS market share in a race that they had previously won with superior product.

We advise in favour of the NLM and Windows 2000 service because they are technically superior solutions.

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...