Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Problem with record locks
Hello all,
This is going to be a little long, so thanks for your patience.
My client has a process that typically takes 6+ hours to run and runs in the wee hours of the morning, hypothetically before people are actively using the system. When the process is running, all the users know they are not to be doing certain things due to record locks and possible corruption of data. However, on occasion there are those who break the rules and can cause lock contentions with the running process. There are people who monitor the system overnight and are notified when such a lock occurs; but finding out who caused the lock and fixing it can be difficult, especially for non-OI-proficient people.
I know the function RTI_LOCK_OWNER will return the station ID that locked the record. From there, SYSLOGINS should contain the current usernames for the stations; but in my client's system, the username is always SYSPROG. Sometime back, there was functionality written that attempted to write the user's network ID to SYSLOGINS (a read-only table) upon login, but this seems to have been disabled or never worked.
My questions are 3:
1. Is there a better way to tell, from an OI session (Not from the UD server) which user has a record locked?
2. Is there a good way to remotely release said lock without going to the server?
3. Is there a good way to knock the offender off the system, again without going to the server?
Still using OI 9.4. I know all of this can be done easily from the server, but I'm trying for something the monitoring people can do remotely. Maybe there's an un/der documented feature that will remotely communicate such things to/from the LH service?
Thanks in advance!
Michael
This is going to be a little long, so thanks for your patience.
My client has a process that typically takes 6+ hours to run and runs in the wee hours of the morning, hypothetically before people are actively using the system. When the process is running, all the users know they are not to be doing certain things due to record locks and possible corruption of data. However, on occasion there are those who break the rules and can cause lock contentions with the running process. There are people who monitor the system overnight and are notified when such a lock occurs; but finding out who caused the lock and fixing it can be difficult, especially for non-OI-proficient people.
I know the function RTI_LOCK_OWNER will return the station ID that locked the record. From there, SYSLOGINS should contain the current usernames for the stations; but in my client's system, the username is always SYSPROG. Sometime back, there was functionality written that attempted to write the user's network ID to SYSLOGINS (a read-only table) upon login, but this seems to have been disabled or never worked.
My questions are 3:
1. Is there a better way to tell, from an OI session (Not from the UD server) which user has a record locked?
2. Is there a good way to remotely release said lock without going to the server?
3. Is there a good way to knock the offender off the system, again without going to the server?
Still using OI 9.4. I know all of this can be done easily from the server, but I'm trying for something the monitoring people can do remotely. Maybe there's an un/der documented feature that will remotely communicate such things to/from the LH service?
Thanks in advance!
Michael
Comments
Anyway, see if it works for you.
GetLockOwner:
UserId=''
owner = RTI_Lock_Owner( Filename ,Key )
if index(owner,'*',1) then
PcId=field(Owner,'*',2,2)[1,'_']
end else
PcId=owner
end
SysloginsRec=xlate("SYSLOGINS",owner,'','X')
if SysloginsRec then
UserId=SysloginsRec<10>
end
return
I didn't know if there was some un/der documented feature that could pull anything from the LH service or whatever. Or a call that would let me kick a session off.
The same client also wanted a way to view who was locking records from within their app without having to launch the UD tool. It didn't need to be fancy - just a way where they could see who had the lock so they would know which user to contact. Using a system wide promoted read event, whenever someone reads/locks a record in a window, the system writes out a log item to a table as to who locked the record, the station, what time, table, etc. The "user locking log" window then displays these entries so that other users can see what is locked in a nice simple report table format. The window also confirms that records are still locked, and removes log entries when the records become unlocked. If you had timers on those windows, a similar system flag could be set to "destroy" that window which would release the lock.
There could also be solutions based around something like the SRP Direct Connect control, where you could push messages out to the clients and client windows, which would then fire the appropriate events to both warn users and log them out. It would require a bit more work, but would give you more options/control if you ever needed to expand on the inter-window messaging.
I'll bat those ideas around a bit. Thanks!
I didn't know if there was some un/der documented feature that could pull anything from the LH service or whatever. Or a call that would let me kick a session off.
The SYSLOGINS table creates SYSPROG rows by default until the session owning the locked record selects the SYSLOGINS table. It's a quirky problem. The SYSLOGINS row is able to be updated by the Application Startup Procedure, which you can specify in field 32 of the ENV_appName row in SYSENV. Check out the ENVIRON_CONSTANTS insert if you haven't already.
If this client is the one I'm thinking of, we already built a solution for them. It uses the SRP DirectConnect control to talk directly to the running UD Manager on the server and give it remote instructions to show locks, issue unlock requests, etc.
Sorry, it is me that adds the username.
Will look into populating the username as you specified.
The control you mentioned: does it involve the SRPMONITORCONNECT API?
Thanks!
I'll see if I can get them to re-engage with y'all. Not an absolute need, but a nice-to-have.
Quick off-topic question: We started getting a msg
FS291: List over 64k bytes in BTREE.SUB operations or RELATER routines
I thought the 64k issues were a thing of the past? Is this just a holdover or is it actually limiting the results?
RTI_LOCK_OWNER doesn't work at all. In fact it abends OI altogether. Anyone have a workaround?
Again, off-topic: the client has upgraded several of the workstations to Win10. OI still "runs", but more accurately it walks. I don't think the infrastructure people re-ran the clientinstall exe. Should that make a difference? Has anyone seen such a severe performance dive after upgrading to Win10+?
Gratzi!