We run an AREV application and are having some problems getting it to run properly on some new computers we just received. These new computers are Dell Optiplex 745’s. Initially they would not create EMS and I was able to correct that by disabling the “USB boot” options in the system BIOS. We have always run the Optiplex line of computers without a problem, including Optiplex 620’s, the previous version of the 745.

Anyway, on the new computers one of two things happens, usually when running a search of some sort. Usually the first time running the query works fine but after that, an AREV message pops up and says, “IDX_SETS function 1 returned error code -9729.” If you OK that message, it returns to the original spot in AREV. If you try again, the same message appears. If you try it three or four times, a Windows error message pops up saying , “The NTVDM CPU has encountered an illegal instruction”. If you OK that message, it closes the AREV application.

As I say, we run AREV with Optiplex 620’s, 240’s and even some Dimensions without any problems.

Any ideas would be greatly appreciated. Thank you!

Tony

I am currently testing a replacement for this routine.

The problem arises from the use of indexed jumps into code blocks within the routine. I'm hopeful that by word aligning these blocks and not using a fancy jump scheme (but rather a bunch of conditional jumps at the top of the routine) that the fault can be corrected.

Steve

We are at AREV 3.1.1.1. Does this mean there will be an upgrade beyond 3.12??????

Thanks!

 Tony

We are currently on v3.1.1.1. Does this mean there will be an update beyond 3.12. Any ETA?

Thanks!

 T

There aren't any differences in this routine between 3.111 and 3.12

There aren't any version dependencies either.

Time frame? ASAP. You're the second person who has asked. I assume everyone else is yet to upgrade their OS / hardware.

At this rate the opportunity cost possibly well outweighs what you're willing to pay.

Very good. I have to "make the call" on whether to return 19 new Dell Optiplex 745's in the next day or two. If they can't run AREV, they aren't doing us any good. Getting a lot of heat for this ordeal to say the least.

 T

That's good to know. Here, they're busy replacing all of our HP computers with Optiplex GX620s. I've had mine for a couple of weeks now, mostly problem free. Available memory is lower than I'd like, currently about 219,000 bytes. But otherwise, everything seems to work fine.

I've got to the stage of properly recompilable source presently (the hard part), and now I'm reblocking and testing. I've been busy but I'll check back here in the next 24 hours with an update.

steve@state-of-the-art.com.au

Hoping for a solution from Steve, we've been re-writing our

rlist subroutines to buy us some time. We've found that by

making multipe single selects in the subroutine we are able to

complete an rlist select without triggering the IDX_SETS problem.

I've also noticed that the excellent synctime.com program Steve

created has quite working after 8 years. We upgraded a few months

back to Novell6.5, but I'm pretty sure it was working just recently.

Steve, is it possible the synctime.com routine is being affected by the IDX_SETS problem as well?

TIA,

Jim

This is an update to my post questioning whether the synctime program is also having a problem with IDX_Sets. My conclusion is that it isn't and that it is a coding issue in synctime due to the change in

DST dates…..

We are running Steve Smith's synctime program and are finding that

we have three times, Novell6.5 server time, W2kPro Workstation operating system time, and AREV time after running synctime.

The Novell time is set to the new DST, the wkstn operating system is also set to the new DST, however when synctime is run, the old regular Standard time which is one hour earlier is returned. I am

assuming this has to do with the synctime coding being based on old DST dates.

View this thread on the forum...