I would like to stop (particularly stand alone) users from logging into Arev more than once.

I've checked through the forum and there was a nice easy way to check if Arev was already running by using the pcperform mem /c command. Unfortunately, this command doesn't give the same results as Win'98 when using XP and so fails to detect more than one instance.

Is there a nice uncomplicated way of preventing the user from logging in twice, thrice or ??? In particular stand alone XP users.

TIA

Claude

I can think of several ways to do this.

In our application, the logon scripts all write a row to a table. The key to the row is @STATION. This allows us to check and see if the workstation is already logged in. If they are, we ask if they want to start another session. We then replaced the OFF command with one of our own to delete the entry from the table and then call the original OFF command to log out.

The downside to this is if they do not log out properly, the system will think they are logged in when they aren't.

Another option would be to write a small VB wrapper for ARev. Instead of launching ARev directly, you launch the VB program first. This program could check for a previous instance of itself, and if there is one, not allow ARev to be launched. If there is not, then it can launch ARev, wait for ARev to complete, then unload itself.

Again, the downside to this is you have to have some way for ARev to tell it that it has finished.

In short, I do not know of a "perfect" solution.

[email protected]

Greyhound Lines, Inc.

Thanks for that Matt,

I had hoped not to have a downside - like dealing with unauthorised exits. Checking if the program was in memory was a nice way.

I have ice cream and chocolate wrappers, but no VB wrappers so looks like I'll have to go for option 1.

Claude

Claude,

Our Arev batch file just uses the ECHO command to write out a file, and it first checks to make sure that file isn't already there. At the end of the script (when the user logs out of the AREV system), it does a delete on that file. To handle the 'crash' exit, we give them a shortcut to another .bat file that just deletes the file so they can get back into AREV.

IF EXIST C:\WINDOWS.RUN GOTO cant

ECHO ]] C:\windows.run

… (call the AREV system)

DEL C:\WINDOWS.RUN

goto end

:cant

@cls

echo Another AREV application is running.

:END

Works with any OS, but I've heard some OS doesn't like the .RUN extension, so you might use a different one.

Claude/Matt,

There is no downside if you LOCK the record rather than (or as well as) just writing it. Any system exit at all - a crash , or even the BRS option (everyone remembers the Big Red Switch, don't they? will drop the lock.

Only caveat is that this needs to be done in a login command that shells the execution of the top-level menu, otherwise the system itself resets all locks before you even get started. (And of course, you'll need an equivalent restart code & command.) If memory serves, Claude, your systems already shell most of the login anyway…?

Finally, if you're basing a lock on @station, remember to extract just the 2nd part of the variable. (A previous post once suggested using FIELD(@station,"*",2) but I'd recommend @station-1,"B*" as being both quicker and more generic…)

FWIW,

Cameron

Hmmm. I tried devising a lock-based scheme some time back and didn't find a workable solution. It seems there are just too many situations when an unlock all is performed. Rather than isolate them all, I gave up on the project.

Another idea to explore, if you are using the NLM is to ask the NLM what connections it knows about. Explore the source to NLM_STATS to get an idea of what to do. By way of illustration, type NLM_STATS at TCL, select Communication, then the server you're connected to. Next you see a listing of current connections. Appropriate calls can be used to get the MAC address, which can then be compared to the current MAC address to see if multiple sessions are being attempted.

This IS crackable but it's a tad low level

The fact that NLM_STATS source shipped on the earlier diskettes is incredibly useful!

The Sprezzatura Group

World Leaders in all things RevSoft

Being bored with the drudgery of testing, and being intrigued by the source code to NLM_STATS, I have had a go at hooking into the RTP57A calls to determine if the user logging in has already logged in on that particular machine.

The one downside that I've already found is that if you are hosting two environments on the same server, and are logged into each one then they "cross talk" and inflate the count. I could work around it I'm sure, by comparing paths to a particular known volume, but this was a quick and dirty stab.

If anyone is interested in the code, please let me know and I will gladly share it.

[email protected]

Greyhound Lines, Inc.

I don't know if this will work with MS-DOS programs from the Windows desktop, but it might be worth a look

http://cicom.kgb.cz/main.php?view=2&what=1&lng=en

Don M.

I just discovered another problem. I don't know if this is an NLM bug or what. But I'm getting unexpected results using the following scenario:

First, here at the Department of Human Services for the state of Texas, Arev is implemented rather uniquely. Systemwide, there are currently about 500 servers, each of which is a primary server for some number of users. Arev is installed so the executable and most files are local to each workstation. There is a total I think of about 17,000 users.

The NLM is installed on each of the servers, and users attach only to their own server, except for support personnel and a couple of other situations.

Everyone attaches to what is essentially duplicates of various volumes, thus making it impossible to attach more than one even if you wanted to, unless you took steps to change the volume labels, which would contravene the software distribution process.

One exception is the developers' server. The volumes on this server have different labels in order to facilitate the first steps of software distribution, which are done using Arev read/writes. This allows the developers to attach a volume on the development server and the equivalent volume on a remote server simultaneously, using qfiles in order to attach both files simultaneously (else, because the filenames are the same, the original set will be detached when the second set is attached).

Now that I've somewhat longwindedly explained the scenario, the situation can be described. I attached my normal development volumes, and then I attached a remote file as described above.

Querying the files using NLM_STATS, I see the entire (evidently) suite of files on the remote volume (which I attached only a subset of). I see very few files on the local volume. I gather this is because they have the same names and NLM_STATS is not careful about this.

When I detach the remote volume, the entire complement of files for my normal local server appear in the NLM_STATS file listing.

"I don't know if this is an NLM bug or what"

What I meant to say was NLM_STATS bug.

Claude,

You could always set "exclusive in foreground" on the shortcut

I wouldn't normally use Unlock All in an actual application, although you never can tell what the system will do - that's why you need to ensure the lock is reapplied on any crash.

You could really go to town, and do it from a post/replace index hook; or why not take a sledgehammer to the problem and shell Input.Char and do it every time the workstation is ready for input?

Only problem with the NLM solution is that on the "average" configuration if a user crashes out they might wait up to 10 minutes for the server to realise they've REALLY gone - not so good if your logic prevents them getting back to work in the meantime!

FWIW

We use simillar (*.bat) trick to prevent new sessions when we want to backup before batch closing. Our prevent file is called 'arev.lck' and is on network drive together with arev.exe and arev.bat ….

nonempty arev.lck usually contains "backup in progress" message.

———- arev.bat ———————-

if exist arev.lck goto locked

arev.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

goto end

:locked

@cls

@echo System not available

@type arev.lck

@pause

:end

---

] I wouldn't normally use Unlock All in an actual application, although you never can tell what the system will do - that's why you need to ensure the lock is reapplied on any crash.

It's not just crashes, though, that do an unlock all.

] Only problem with the NLM solution is that on the "average" configuration if a user crashes out they might wait up to 10 minutes for the server to realise they've REALLY gone - not so good if your logic prevents them getting back to work in the meantime!

I think a reboot of the PC (cold boot may be necessary) will resolve this problem.

What would that solve? Or are you just trying to be a troublemaker? If you did this, a lock held by the background session would be stuck until the user activated the session. That can bring an office to a screeching halt.

Victor,

Yes, I am a troublemaker.

Claude and I share a long history of beer drinking at some of Melbourne's finer establishments and he hopefully knows me better than to take my advice literally on this occasion.

Treat it as a flippant comment alluding to the independence of DOS virtual machines under Windows - the only interprocess communications readily possible between two DOS sessions on one Windows workstation are in terms of locking (RTP57A calls), or semaphore files.

Under Windows the DOS virtual machines are independent, so one AREV session can't see the other in memory anyway. Interestingly CMD.EXE behaves differently to COMMAND.COM with respect to MEM calls (which traverse the memory control blocks under DOS).

So the ultimate deterrent I (flippantly) suggested was to bring the second AREV session to its knees by encouraging the first session to occupy 100% of CPU - the anarchist's approach to a "solution".

Another solution might be to have each subsequent AREV session trigger the thermal overload in the CPU (possible with some BIOSes)

The other idea I had was to bludgeon idiot users to death before they opened a second session. This is accepted practice in many Australian workplaces.

I hope I've explained the rather weak joke to your satisfaction.

Regards,

Steve

I just scanned through the various utility diskettes and didn't see the nlm_stats sourcecode. Can anyone recall which disk it was on?

As I recall it is on the LH NLM diskette.

View this thread on the forum...