We are running Arev 3.12 and have our indexing processes running on a stand-alone machine. We have been doing this for several years without problem. A question was posed to me regarding moving the indexer to an existing server (our Intranet server). Does anyone have comments that may be helpful to ensure we make the right decision? And is running the index process on a stand-alone machine important enough to justify a license just for indexing?

Thanks in advance for your suggestions.

Heidi Korell

Indexer has to be logged in as another AREV user. StandALone is the best bet; indexer is not a separate piece of AREV system software which can be placed on the server unlike AREV LH services or NLMs.

I hope that clarifies….

I understand the concept that Indexer is an Arev user. But my question is… Is it better to log in as Indexer from a stand-alone machine or from an existing server that is used for other reasons?

You say that stand-alone is a best bet. This is what I'm interested in hearing more about. Why is it a best bet?

As a general rule, because indexing needs to have locking active, and locking is only properly active on workstations, conventional wisdom is to run an indexer from a workstation.

We have seen implementations where the server-based indexer has been attempted, albeit with a few kludges to get it running. We usually recommend against this practice.

The Sprezzatura Group

World Leaders in all things RevSoft

I know that the party line has been to run a dedicated indexer on a stand-alone workstation.

However, from a core Linear Hash locking stand point, I do not see any reason for this.

Seems like the server itself should be a good place for it, assuming you have the CPU power available. It would save a lot on network traffic.

Does anyone know what the specific issues are?

Pat McNerthney

OI32 Grunt Coder

We suspect this grew from two things - one the old thing about various non Novell software being more strictly peer to peer and local drive mapping being difficult and two the CPU utilisation of an "always on" indexer along with the frequent disk access having a bearing on the overall server performance. The argument was against penalising all server users for a process which could be run on a redundant 386 on a separate NIC (thus eliminating the additional traffic).

With today's server software, and as you say adequate CPU (and adequate tuning to ensure AREV is not trying to take 100% of this CPU ) this shouldn't be as real a problem as it has been historically.

The Sprezzatura Group

World Leaders in all things RevSoft

The use of INPUT x, -1 inside F.DISTRIBUTOR is a fair reason not to index on the server. This may peg the CPU on the server at 100% during index update cycles, depending on your AREV version and the indexing workload.

The Sprezzatura Group

World Leaders in all things RevSoft

I'll add my two cents into the mix here.

I think there is no firm rule on whether to have a dedicated indexing workstation. If your users, for example, have Arev loaded idle much of the time and are using stable workstations, there's no reason why their systems cannot be used as indexers, particularly if updates are few or an occasional delay as indexes get caught up can be tolerated, or the application has been designed to update indexes immediately following updates.

I worked at a site, for example, that used to have a dedicated indexer. We had it set up because there were frequent updates to indexed fields and frequent reporting on the data. Eventually, however, we changed to having all workstations performing indexind during idle time because the system turned into an inquiry-only system, with only occasional updates.

One problem that used to happen somewhat regularly with a distributed indexer setup was that if a workstation locked up in the middle of an index update, or if the workstation on which indexing was occcurring was rebooted or powered down by a user who didn't know better, corruption of the indexes resulted. The consequence/remedy was costly down time. Rather than play Russian roulette this way, many opted for a dedicated indexer. The workstation was controlled, and there were no other processes occurring on the workstation that might potentially bring down the whole box.

Now, with the NLM or NT service running, the likelihood of creating a GFE, or otherwise making only partial updates, is substantially reduced, so the need for the dedicated, controlled machine is less.

I'd be wary about putting it on the server, though. If you want to consider it, test for CPU utilization and locking. If you are satisfied that locks are working properly, and performance is not a problem (performance of other apps on the server), then you should be able to run the indexer from the server.

Consider, though, that the indexer need not be a workhorse of a machine. You can probably get an old computer that is otherwise just wasting space to be a dedicated indexer for you.

I forgot about the license question. How will you be saving a license by moving processing to the server? You will still have to run a DOS process at the server, which, unless I'm mistaken, will cost you an Arev license.

Well, as far as this section of the collective is aware, it's not really an issue if everything is set up correctly (it being running on a server).

The hard part, in the past, has been coordinating the locking. As said, one should never run the Novell server in non-dedicated mode, but they got rid of that option when, 1990? 1989? Netware/286 was the last version anyway.

We've had great sucess with the NPP running on local NT Servers handling locking correctly provided you run off a mapped drive. Older versions of the LanMan shell didn't allow this, but NT 4 and higher lets you map a drive to a local share and it's treated as a network drive for ARev's purposes.

We had one site where this wouldn't work, but it has in all the other.

I don't see what's so wrong with running ARev on the NT Server, as long as the locks are set and the server is tuned.

The Sprezzatura Group

World Leaders in all things RevSoft

Hmmm…off hand I see no reason for the mapped drive requirement when using the NPP.

The NPP will always perform locks against the REVLOCKS file, local or private. This can easily be verified by running AREV in two different DOS boxes on the same machine and editing the same record.

You are correct that the old byte range driver did distinguish between local and remote drives, but that was in the days before multiple dos sessions were possible. The NPP attempts to work on today's operating systems.

Pat McNerthney

OI32 Grunt Coder

Let's talk, since I'm sure it should work as well, it's just we've been having some problems with this, FS1030 errors or access denied errors or other errors like that. Mapping to local shares solves this.

The Sprezzatura Group

World Leaders in all things RevSoft

I was talking about a Windows 95 license. That was the reason this question was posed to me.

Another possibility that may be worth exploring is to add the indexer as a process on an existing workstation. There's no reason you cannot have more than one Arev session going in Windows 95 (as long as you are on version 2.1 or higher of Arev I think). If there is a workstation that is always available, you could set it up to kick off an indexer at bootup, which could remain minimized while the user is using other applications, including another Arev instance. The two Arev instances would use two different .INI files.

Victor ..

I did exactly that for a customer. There was a workstation that was always on because it was a printer server. Just loaded AREV indexer and minimized it at startup. The only glitch was if the network was not alive (but then the printer wouldn't work either). There are a number of Startup Managers available for download. Look at http://www.mlin.net/ for a pretty good one. Works in Win95 too.

Don

View this thread on the forum...