I am a little concerned over the network user controls in this RTI program. I understand the program is meant to check that no other users are logged on whilst it runs. There is no record locking for writing updated records.

Firstly, I had a case when it ran fine but I found someone else had remained logged in. By the way, I also have a client whose SYSLOGINS doesn't seem to record who is logged in.

Secondly, maybe it ensures that all other users are logged off when it starts running - but does it also bar any users from logging in whilst it is running?

Thirdly, we have a couple of networked dual OI/ARev installations. If it works OK for the OI users, does it detect any Arev users? Although one may normally update just OI elements, it is sometimes necessary to update jointly used items like dictionary records.

For this latter situation alone, I should have thought record locking would be a wise precaution which wouldn't affect update process times noticeably. I am going to add it myself so that I can sleep better!

RTI- any comments or reassurances?

Richard,

By the way, I also have a client whose SYSLOGINS doesn't seem to record who is logged in.

I sympathize with everything you listed out. The reason SYSLOGINS doesn't seem to work everytime is because at some version in OI, I don't rememeber which, the logic that auto-updated SYSLOGINS whenever somebody logged into OI was removed or disabled. Cameron Purdy confirmed this a few years ago for me.

The work around is to Open the SYSLOGINS table programmatically and do a Select against it. This invokes the logic (MFS I beleive) that will add the current login to this table. We wrote a routine that does this during the CREATE event of our main application window. Alternatively I believe this could also be added to the SYSENV record where developers can hook their own code to be called when OpenInsight itself is launched.

What I want to know is whether their really is a good reason to prohibit the RDK just because other users are logged into the application. Of course their should be a mechanism to prevent more than one person from running the RDK installation process at the same time (easily done of course) but I am having difficulty seeing the reason for having everybody out of the system. It is really somewhat encumbering to get everybody out of the system just to load a simple update when it is needed.

[email protected]

SRP Computer Solutions, Inc.

Donald

Many thanks. I thought it was just one of my clients whose SYSLOGINS wasn't working - but I'll check. Now I know it's probably disabled, I can follow your suggestions.

It's easy to record what happens at login and also at logout. However, one has to allow for crashes and task terminations when users are also logged out without going through one's carefully prepared procedures. This suggests the most reliable means might be based on dummy network locks which get released automatically when the app stops.

Regarding updates, I totally agree that it is often impractical or even impossible to ensure all users are logged off. As mentioned, I have had strong suspicions that OI's check on this doesn't always work and I have therefore put record and file locking into RDKMODULEINSTALL.

I suppose one should identify certain update tasks like installing new indexes or MFSs where there could be implications if users stay logged in and other tasks where records might just be locked and need to be done later or put into a deferred jobs facility.

When I've thought this one out, I might try removing the requirement for users to be logged off. In such case I wonder if OI's routine (I forget the name) will still release the bar on certain ops not otherwise allowed in a runtime.

Maybe we need to devise different classes of upgrade - those that need users logged off (including index installs, etc.) and those that don't. I suppose the update routine could detect the relevant ops automatically.

Thinking caps on!

Regards

Richard Guise

Donald

Many thanks. I thought it was just one of my clients whose SYSLOGINS wasn't working - but I'll check. Now I know it's probably disabled, I can follow your suggestions.

It's easy to record what happens at login and also at logout. However, one has to allow for crashes and task terminations when users are also logged out without going through one's carefully prepared procedures. This suggests the most reliable means might be based on dummy network locks which get released automatically when the app stops.

Regarding updates, I totally agree that it is often impractical or even impossible to ensure all users are logged off. As mentioned, I have had strong suspicions that OI's check on this doesn't always work and I have therefore put record and file locking into RDKMODULEINSTALL.

I suppose one should identify certain update tasks like installing new indexes or MFSs where there could be implications if users stay logged in and other tasks where records might just be locked and need to be done later or put into a deferred jobs facility.

When I've thought this one out, I might try removing the requirement for users to be logged off. In such case I wonder if OI's routine (I forget the name) will still release the bar on certain ops not otherwise allowed in a runtime.

Maybe we need to devise different classes of upgrade - those that need users logged off (including index installs, etc.) and those that don't. I suppose the update routine could detect the relevant ops automatically.

Thinking caps on!

Regards

Richard Guise

Firstly, apologies to RevTech for the double posting of my last contribution. My link broke just as I submitted and, when I reconnected, the message wasn't there so I resubmitted it.

I've just tried logging on to my copies here of five different client installations which I've just updated from 3.6.1 & 3.7 to 3.7.5.

SYSLOGINS appears to work on all of them.

Next week I'm seeing several clients on site to update both OI and the app. I'll check what happens on-site re SYSLOGINS. If any mysteries I'll post another contribution.

Richard Guise

Richard,

I've just tried logging on to my copies here of five different client installations which I've just updated from 3.6.1 & 3.7 to 3.7.5. SYSLOGINS appears to work on all of them.

How did you go about to prove this? If you simply logged into OI and then went to the System Editor, Ctrl-R, double-clicked on SYSLOGINS, and saw your login then you defeated the issue. This threw me for awhile until I figured out that while I could always see my own login I couldn't always see anybody else on the network. I then had everybody do their own System Editor check. Sure enough, the moment they looked at SYSLOGINS then their own login record would be created. That's when it dawned on us that Opening/Selecting SYSLOGINS was the trigger.

[email protected]

SRP Computer Solutions, Inc.

1. Thanks, Don, you're dead right! I did just as yiu said on a single PC. I'll try across my test network and see what happens and/or find a solution that works.

2. Re upgrades without getting everyone off the system. If someone is running a program and has called a subroutine and then the upgrade replaces the program and/or the subroutine. Would the user just carry on with the old version from the workstation's memory - or would the workstation crash to debugger? Apart from the inconvenience could such an event have any more sinister consequences?

3. As previously discussed, getting everyone logged out is a problem (even if upgrades don't need it, there are always other reasons from time to time). It is therefore necessary to be able to identify logged in users. We had some quite effective means for this with Arev and SYSLOGINS looked like being very useful for this in OI.

Any comments???

Thanks

Richard

2. Unless the subroutine is marked as expendable the subroutine will stay on the local user program stack until the main routine exits when it will be removed. The next attempt to run it should read from disk although there may be additional cacheing implications here. Apart from that it should be ok.

3. Using server tools to identify users with open REV*.* files is frequently the only effective way if the NLM is not loaded. Checking for entries in a login type file might not be effective if the user has abended as has previously been pointed out.

Theoretically a program could be written to identify how many users were currently logged in without actually identifying the users but again, in an abend situation this would rely on the server clearing up after the user.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks

View this thread on the forum...