Windows 2000/XP workstations, on a Windows Server network, using the NT Service (all versions), do not process the AREVPID.DAT file. This leads to the session number in @station always being 0, which creates problems in a number of operations. For example, it causes conflicts in the processing of select statements in SYSTEMP when two sessions are running select statements at the same time.

If you delete the AREVPID.DAT file, AREV does not detect its absence and does not recreate it. If you manually recreate the file and place a 0 in it, that number is never incremented. Windows 98/ME machines on the same network, using the same arev.exe, process AREVPID.DAT correctly.

Any ideas?

Dan,

Not certain, but are you using CMD.EXE as the command shell? What happens if you use command.com instead? And does the Windows FORCEDOS command help? All things to maybe attempt to trick the AREVPID into working.

Otherwise, there's always a workaround - not elegant, but you can roll your own routine to suit the application. A DOS environment variable (like the environment username= along with TIME()) may suffice as a surrogate station ID, set at login time.

Steve

Hi Steve,

Thanks for your help! The $setstat "workaround," followed by a EXECUTE "RESET" seems to solve a lot of the problems I have been struggling with. For example, it allows me to change the name of the sort file from within an arev session, so each session on the same machine can have a unique sort file.

What is the correct way to use this utility, so the system initializes correctly, and as early as possible in the startup sequence?

Regarding your questions about cmd vs command, we are launching arev.exe from a pif file, and launching the pif file in one of two ways: 1) double-clicking the icon (pif), and 2) suspend "cmd.exe /c start my.pif" from within rbasic programs. Either way, the session number is always 0. Is there a better way to launch arev?

Dan,

I've used it on old REVG systems under Novell where the NIC (network interface card) address wasn't always "readable" or set correctly. ABout five years since I've needed it.

All it does is set the variable @STATION. For the location I'd favour VOC LOGON, but you have evidently found some extra benefits I hadn't anticipated .

Remember to check your locking still works and LISTS records carry your the modified @STATION in the key for selects, etc etc.

I'd recommend the Network products as a far better solution, or else assigning the NIC address (@STATION) from the hardware drivers either via Windows or via those utilities that accompany the network card.

Steve

Steve,

Thanks again for your help with setstat. Let me tell you more about what we are trying to fix. Maybe that will give you some idea about how we should or should not use setstat, or perhaps trigger some other ideas. Maybe I am just making this harding than it needs to be.

First, we are using the network products, and the problem that we are encountering is reproducable by RTI tech support.

The presenting problem is that reports hang, or return inaccurate results, when more than one select/sort process is occuring on the same machine at the same time. For example, the problem will appear if two users on Citrix or Terminal Services are running reports at the same time, or a power user launches two arev sessions on a desktop and runs a report in each session.

The problem occurs (in arev) only on Windows 2000 or XP machines on a Windows network, and it occurs on workstation nodes, Citrix or Terminal Services machines. Windows 95/98/ME machines on the same network, using the same arev.exe, do not have this problem. Novell networks also appear unaffected by this problem, (so perhaps it is related to the All Networks driver?)

A similar problem also affects OpenInsight under similar circumstances… just search the Online Discussion for SYSLISTS to see more (although I have been told that it was fixed in the most recent update of OI, so you might want to upgrade if you are using OI).

I have found two contributing causes of this problem in arev, and at least one of those applies to OpenInsight:

1) The name of the sort file used by arev (e.g., R12345.SFX) is derived from the value of @station. If every session has the same value for @station (which it does), every session derives the same sort file name (see get.sort.file()). One session, therefore, can step on the sort file from another session on the same machine. More often than not, the reports hang. If they complete, they are not accurate.

2) In Arev, all selects ] 64K are also written to SYSTEMP before they are copied to LISTS. The record keys in SYSTEMP include the value of @STATION as part of the key. So, for example, the key might look like T*0*MACHINENAME*10*1 (where the 0*MACHINENAME segment is the value of @station).

If each session has the same value in @station, each session uses the same key values to hold its results in SYSTEMP. If a value is already there, it just gets overwritten by the second select process.

3) OpenInsight's problem is similar to problem #2 above. OI uses SYSLISTS instead of SYSTEMP, and it writes out record keys like T*MACHINENAME*10*1, omitting the session designation altogether. I suppose this is related to OI's original single-session heritage. If OpenInsight uses an arev-style sort file, I am unaware of it.

The underlying cause in Arev is that AREVPID.DAT is not processed by Windows 2000/XP machines on a Windows network. This file never gets processed during logon. If AREVPID.DAT is missing, it is not even replaced. This failure to process AREVPID.DAT leaves the first value of @station as 0, (e.g., 0*MACHINENAME). Again, AREVPID.DAT is processed correctly on Windows 95/98/ME.

All of the Arev problems appear to go away when the session number is processed correctly. Each session, then, gets a unique value for @station like 234*MACHINENAME, 235*MACHINENAME, etc. This solves problems 1 & 2 above.

Unfortunately, using setstat is a little tricky. You can't just change @station and get a unique sort file name. You have to change @station, then PERFORM "RESET" In some cases for us it is easy to find a spot to do this, but not always.

OTHER WORKAROUNDS:

You can get around the first problem in environments like Citrix or Terminal Services by setting sort paths for users to a unique home directory, but if the same user has more than one session running at the same time, they will have problems.

You can get around the second problem in Citrix or Terminal Services by placing a copy of SYSTEMP in the users home directory and attaching it before running any select statements. But again, this does not work when a single user has launched multiple sessions.

I am not sure about a workaround for OI, but I would guess that a user-specific SYSLISTS table would solve the part of the problem that did not involve multiple cursors.

SIMILAR PROBLEMS

Rollout files in arev have similar conflicts. Unless you do something creative, you get one rollout file per INI file.

Dan,

I guess I'd try attaching local volumes bearing SYSTEMP and SYSLISTS files.

There seems to be (from what you're saying) something pathological about the behaviour of V119's choice of unique *.SFX filename prefixes with two+ concurrent sessions (using SFX files for the merge/queues during sort) on the same box, but I'm guessing here.

As for the AREVPID.DAT load, I'll take a look at it in codeview in my "copious free time". I'm sort of backlogged right now with OpenInsight stuff and a couple of other tasks.

I wonder if the solution isn't to run AREV from a batch file which ahead of AREV deposits some unique config information in a DOS based file, which is subsequently read and loaded ahead of your application.

Sorry I can't assist more - I guess I'd have to sit in front of the box to get an idea of the options available.

Steve

Steve,

You helped a lot with setstat! Figuring out how to apply it took some time, but it was a much better solution than the others I could come up with.

I previously tried batch files, as you suggested, to set a separate ini file for each session and/or to modify the INI file for each session, but it became tedious to keep track of open sessions, ini files, etc. It also created an explosion of INI and SYSTEMP files.

I do believe the core problem has something to do with the interaction between Windows 2000/XP and the All Networks driver, but that is just a guess. Setstat allowed me to process sessions and set unique values for @station on my own. This appears to have resolved the problems I was encountering.

FYI: It looks like this has to be PERFORM "RESET", not EXECUTE "RESET"

For the benefit of those that are also need to solve this, I found an entry elsewhere where Aaron Kaplan explained that the sort file name is set when the system initializes, and the name of the file is derived from the value of @station. It is also set in a way that it is not user-accessible, and this value is not reset automatically if @station changes. V119 does not have a role in this; get.sort.file() apparently does this work, but again, only once during logon.

Aaron suggested manipulating the INI file on the disk, then calling initialize() to solve this problem. I had trouble trying to coordinate multiple sessions attempting to manipulate the same INI file, and found that changing @station, then doing a RESET accomplished what I was trying to do.

Further update on sort file names… It seems that this approach is less than perfect. As it turns out, arev does not always assign a unique sort file name. In practice it repeats the same sort file names frequently, despite different station ids. It must be using some type of random process that is not all that random.

http://www.revelation.com/__85256DB80017688B.nsf/0/977DB2278E534879852567580068BC83?OpenDocument

View this thread on the forum...