Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Update SysLogins Question

Quick question about the SRP program “Update_SysLogins” that is called when we log in to our MDI frame. This is from your old framework.

After upgrading to OI 9, we’ve noticed that when we view “User Login Information” the table is missing users’ login IDs. See this screenshot.



Do you know why this might be happening now in OI 9?

Here is the code from our copy of Update_SysLogins:
Compile subroutine Update_SysLogins(UserName) $insert APP_INSERTS If Assigned(UserName) else UserName = "" Open "SYSLOGINS" to hSL then Select hSL AP = @DBID UN = @USERNAME ST = @STATION SL_Key = AP:"*":UN:"*":ST Read SLrec from hSL, AP:"*":UN:"*":ST then SLrec<10> = UserName Write SLrec to hSL, AP:"*":UN:"*":ST Else End end end Return
Here are some things I noticed that might help:
1) The record is read (into the variable SLrec), and it has information in it like login time already, but the username (in row 10) is not written. The write statement fails (it traces to the else condition).
2) If I look at the record in the SRP Editor, the record is locked (although, from what I understand that shouldn’t stop from writing to it).
3) The record shows up as a four part key in the SRP Editor even though the program reads a 3 part key in the program.
4) If I try to open the 3 part key in the SRP Editor (by manually typing in the key, since it doesn’t show up in the list of records) then it opens and the data is the same as the four party key in the SRP Editor
5) Some example keys are
a. Four part: SYMMETRY*SYMMETRY*HUMBLE64622*3280
b. Three part: SYMMETRY*SYMMETRY*HUMBLE64622
6) The record data:
<1> 16643.7481018519
<2> 2
<3> SYMMETRYSYSPROG
<4> 3280

I really appreciate you guys reading this. If you have any ideas why this might be happening, I’d love to hear them.

Thank you very much,
Adam Chan

User: Adam Chan

Comments

  • Hi Adam,

    First, for future information, there is an Upload Image link on the left side of our wiki page. You can use this to upload screen shots. Then you can click on the icon in the forum post editor (it has a a framed picture icon on it) to insert the tag for embedding images. Then just enter the name of the file (exactly as it looks on your system, this is case sensitive) and it will appear. Since you had originally emailed me this image I uploaded the file and edited your post for you.

    Second, you are on the right track toward solving this problem. Since OI 7.2.1, they have added another key part to the SYSLOGINS table: ProcessID. Your version of Update_SysLogins is so old it does not know how to properly generate a full key, thus the record is never successfully read. Below is an updated version of this routine that should work for you:

    Subroutine Update_SysLogins(UserName) /*********************************************************************************************************************** This program is proprietary and is not to be used by or disclosed to others, nor is it to be copied without written permission from SRP Computer Solutions, Inc. Name : Update_SysLogins Description : Updates the associated SYSLOGINS record with the logged in user's name. Notes : Parameters : UserName [in] -- User login ID, located in the USERS table. History : (Date, Initials, Notes) 11/30/00 fjt Original programmer 03/05/06 dmb Add ProcessID to the SYSLOGINS key to support OpenInsight 7.2.1. ***********************************************************************************************************************/ $insert APP_INSERTS Declare function GetCurrentProcessId If Assigned(UserName) else UserName = "" Open "SYSLOGINS" to hSL then Select hSL ; // Still needed to force @USERNAME to be the current user rather than SYSPROG AP = @DBID UN = @USERNAME ST = @STATION PI = GetCurrentProcessId() Read SLrec from hSL, AP : '*' : UN : '*' : ST : '*' : PI then SLrec<10> = UserName Write SLrec to hSL, AP : '*' : UN : '*' : ST : '*' : PI else null end end Return
  • Hello Don,
    Thanks for the quick reply and also for fixing my post by adding the screenshot.

    I pasted in the updated function that you posted, but I'm still not having success.

    It is indeed using the correct key now, but it still is not writing to the SYSLOGINS record. The old code actually was reading the record (even when I didn't use the ProcessID). That was weird. The new code reads the record as well, but no success on writing to the record.

    I can see data read into the SLrec variable (four rows) and then it adds the username into row 10, but the write statement branches to the "else" condition and if I check in the system editor the record is not updated with the username. Also, all rows in the SYSLOGINS table show as being locked when I open them in the system editor. I don't know if that matters.

    I really thought the updated key would do the trick. I'm not sure if I'm missing something, but I am using the exact code for Update_SysLogins that you posted.

    Any other suggestions you might have?

    Thanks again,
    Adam Chan

    User: Adam Chan
  • Adam,

    I am not sure why the "else" condition is getting triggered. Something is preventing the SYSLOGINS table from being updated. I think the only way you can get to the bottom of this is to check the error status within the "else" branch. What does @FILE_ERROR in the global variables contain?

    It is normal for all of the SYSLOGINS records to be locked.
  • edited December 2015
    The @FILE_ERROR global variable contained 3 rows
    <1>102
    <2>SYSLOGINS
    <3>SYMMETRY*SYMMETRY*HUMBLE63078*572

    How do I find out what the 102 means?

    Thanks again,
    Adam

    User: Adam Chan
  • I found the FS102 error message in the OI help (seems obvious now, oops) and it says, "FS102: Error while writing data. "%1%" is a read-only table."

    Do we need to change a setting for the table so that we can write to it? We went from OI 7 to OI 9 and that is when we stopped being able to write to the file.

    Thank you,
    Adam

    User: Adam Chan
  • Adam,

    @FILE_ERROR contains FS-type error codes. So you would look up this error number in the respective FSERRORS_xxx record within the SYSPROCS table. In this case, the record is FSERRORS_100 since this contains the error codes from 100-199.

    FS102 is the following error:

    EQUATE FS_WRITE_READONLY$ TO 102 ;* 0 Write error: attempt to write to read-only file / access to file denied by DOS.

    My first guess would be to check the OS files (should be REV30088.LK and REV30088.OV) for restrictions. Maybe the read-only flag got set somehow.
  • I checked those rev files and couldn't find any clear indication of something wrong. Neither of them were read only. I double checked in the database manager that they are the rev files for SYSLOGINS and they are.

    If you think of any other leads I could pursue, let me know, and thanks again for taking the time to offer all these suggestions. I really appreciate it.

    User: Adam Chan
  • Adam,

    This is a mystery, no doubt. I have a suggestion that might help narrow this down a bit.

    First, make sure you are completely logged out of OI. Then rename the OS files to something like REV30088.LKB and REV30088.OVB. Then manually copy the REV30088.LK and REV30088.OV files from the OI 8 system that works. Then retest.
  • Hey Don,
    Sorry for the delay in responding. We followed your suggestion. We took a copy of REV30088 from our backup. This didn't help. So we then took a copy of REV30088 from a client site's backup (just to be sure) and that made no difference as well.

    We're still getting the same Error Message: 102. We're consistent. :-)

    Clarification: We upgraded from OI 8008 to OI 932 and then to OI 94. We probably didn't look at the Login info until after our upgrade to OI94. We weren't looking and/or expecting a problem there since most of our efforts are fixing reports because of the changes in printing with OI9 and just came across this anomaly.

    Sure would like to know what the heck happen. It's kind of a minor thing, but it would be nice to get this back to normal.

    I know you're busy, but if you (or anyone) have any other suggestions, we would appreciate that. Thanks!
  • Hi Adam,

    I honestly believe you have done everything reasonably possible to resolve this. However, I am happy to schedule an online review of this with you or Ray in the near future. I am traveling this week but I plan to be back in my office next week. Drop me a personal note if you want to pursue this.
  • Don,

    I have pinched and implemented your code for Update_SysLogins and I see it being updated on a sinle development system. But when in a liver multi user network environment there is ever only one record in the SYSLOGINS which is my login.
    Are there supposed to be different usernames used when logging in, as the same username is being used (record locks work)
  • ....ooops sorry about the spelling errors, more haste less speed.
  • Actually if the routine is not called the syslogins records are there, when the routine gets called the last login call deletes the record from the first login call and also deletes it own record i.e. there are no records in the file.
    Am I missing something here.?

    Why is a select done on the SYSLOGIN file before it is read.?
  • edited January 2016
    Barry,

    You should indeed be seeing different usernames. I'm not sure why they seem to be disappearing. How are you listing the SYSLOGINS records?

    The reason for the select command is because OI always logs itself in using the SYSPROG master user. It's at this time that OI generates the SYSLOGINS record with the following format:

    @DBID*SYSPROG*@STATION*ProcessID

    The SYSPROG username will remain in the Key ID until the current session of OpenInsight performs an operation against SYSLOGINS, like the Select command. This triggers SYSLOGINS_MFS, which then replaces the SYSPROG username with @USERNAME.

    Our routine forces this to occur so that we can safely read the updated SYSLOGINS record using the Key ID based on the @USERNAME and then we can add content to the reserved fields for our own purposes.
  • Ok, even I was confused by that sequence.
    Here it is mapped out
    Open copy 1 of dev system
    syslogins 1 record with pi=9292
    launch app - runs routine
    syslogins with updated pi=9292 record

    open copy 2 of dev system
    syslogins 1 record with pi=9976
    Records pi=9292 gone

    Launch app - debug shows record 9976 found and updated
    edit syslogins - no records exist
  • How are you listing the SYSLOGINS records?
  • SRPEditor, TCL select, rti's editor
  • BTW, If I open SYSLOGINS when the oi copy is opened (no app launch), my username is already in the record.
  • Okay. Just needed to make sure we weren't overlooking something obvious. Usually I press Shift+F7 to bring up the HTML Viewer in the SRP Editor, and then press F5 to get to the command prompt and enter LISTS SYSLOGINS. Seems like you are doing very similar things.
  • What network driver are you using?
  • >>BTW, If I open SYSLOGINS when the oi copy is opened (no app launch), my username is already in the record.

    It must 'update' when any app in the oi menu is opened. If I open the editor from one of the first copies, then is is SYSPROG.
    Sorry
  • Well, at least I know now what the viewer is used for

    I have just opened 3 copies of OI and there are 3 records in syslogins.
    This is driving me crazy. ok, fine toothcomb logging now
  • >>What network driver are you using?

    Universal driver 4.7
  • Open 3 c opies of oi, 3 records in syslogins

    commented out the Update_SysLogins call and ran app (opens mainmenu MDI)
    2 records in syslogins

    Must be me so it is back in my court, thanks anyway.
Sign In or Register to comment.