Automic Workload Automation

  • 1.  Setting time limits for users

    Posted Oct 29, 2013 11:25 AM
    Is there a way, or has anyone found a way, to limit the amount of time a specific user or group of users can be logged in? I know you can set the actual times that a user can be logged in, eg 1am - 5am, but I'm looking to be able to kick a specific group of users after 2 hours of being logged in. Any help is appreciated! EDIT: I should add that we're on OMV8...for now.


  • 2.  Setting time limits for users

    Posted Oct 29, 2013 03:15 PM
    Hi Jim! Obviously, there is no way to do this from within the current GUI, as you stated.  The options just aren't there. The only other way would be from the back-end (or a JavaAPI) as long as you could pull the right values from the DB.  The problem becomes that there is no where in the DB that I can find where a User's logon timestamp or duration is recorded by the AutomationEngine.  The USR table doesn't have it and the MQ* tables don't seem to have it.  I've been scanning through the tables for a bit now and haven't come up with another location this could possibly be. The AH table has some potential with the TimeStamps but those are only statistical records, not current records.  This hints that the connection logon time is recorded *somewhere* I just don't know where.


  • 3.  Setting time limits for users

    Posted Oct 29, 2013 03:47 PM
    Jim: Though I haven’t tried it, I’m guessing that you could create an Event that has an Interval Process similar to the following untested code.   A Variable object has Validity Keywords of the user and the Value is their department. “ :SET &vid = PREP_PROCESS_VAR(the_variable_of_users) :PROCESS &vid : SET &user = GET_PROCESS_LINE(&vid,1) : SET &dept = GET_PROCESS_LINE(&vid,2) : SET &resp = SYS_USER_ALIVE(&user,&dept) : IF &resp EQ "Y" :  SET &activated = GET_STATISTIC_DETAIL(,ACTIVATION_TIME,"&user/&dept") !  Calculate the connect time to whatever is needed :  IF &calculated_time GT 2 :   DISCONNECT "USER","&user/&dept" :   ENDIF :  ENDIF : ENDPROCESS :CLOSE_PROCESS &vid Hope this helps.


  • 4.  Setting time limits for users

    Posted Oct 29, 2013 04:18 PM
    In a few months that will definitely be a viable solution. Unfortunately, my predecessors set our current system up so that we have about 200 people that have access to use a single read-only user. I'm thinking that if I tell it to disconnect that user, it's going to disconnect however many people are logged in at that time using that user. I was looking for a possible DB route to uniquely identify each session to be able to kick. We end up with off shore associates that leave sessions running and use up our licenses. Then we have to disconnect them, based on session start time, to allow access to our on shore associates. Many thanks for the suggestion though!


  • 5.  Setting time limits for users

    Posted Oct 29, 2013 06:50 PM
    Here's a select statement to find out the Users connected in all clients: select AH_oh_idnr, oh_name, AH_HostDst,AH_timestamp1, AH_idnr from AH, OH where AH_OH_Idnr=OH_Idnr AND AH_OType='USER' AND AH_SType='DIALOG' AND AH_TimeStamp4 is NULL; It'll return the User ID, Username, where they are connecting from, when they first connected and the session id. c1cde9ad11fa051eaaf7322fe7a0e0.png


  • 6.  Setting time limits for users

    Posted Oct 30, 2013 09:42 AM
    I did do a similar query. select ah_idnr, ah_name from ah where ah_otype = 'user' and ah_timestamp4 is null. I think we're going to bite the bullet and just set up all of the users and force them to user their own ID. I'll end up using a combination of what Mark suggested and a DB query. I'll have a job that queries the DB for just the ah_name then pulls the user names from the job report and puts them into a vara object. From there I'll use the GET_STATISTIC_DETAIL and compare the activation time of each user to the current time. If the difference is > 2 hrs, then I'll disconnect the offending user. Thanks for the suggestions!


  • 7.  Setting time limits for users

    Posted Oct 30, 2013 11:16 AM
    Glad we could give you multiple ideas. :-)