Recognize active users in a Profound instance

[dieter]

Hello,
is there a possibility to identify users, who are working with a special Profound instance? In the subsystem QHTTPSVR i can find lot of jobs like "PROFOUND...". But i don't think that these are active users, because the user often is QTMHHTTP. If we had 2 instances (profound1 and profound2), can i get the active sessions of the instance profound1 by typing "WRKACTJOB JOB(PROFOUND1)" and then looking which users are there who have not the name QTMHHTTP?

(sorry for my bad English).

Dieter

[Scott Klement]

Your English looks perfect to me!

Profound supports 4 different ways of launching sessions:

1. 'regular' sessions (authenticated sessions using the PUI sign-on)
2. 'auth' sessions (authenticated sessions using browser sign-on, or kerberos, SSO)
3. anonymous sessions
4. Genie (interactive) sessions.

It souinds to me like you are using regular sessions -- and for the most part authenticated sessions all work the same way... If that's true...

In one of the recent versions of IBM i (not sure if it was V5R4 or V6R1) IBM started showing the "current" user in the WRKACTJOB display. Prior to that version, it showed the original user (from when the job was started.) So it's important to know what you're looking at -- in older versions, you would have to take option 5=Work with Job, then 1=Display Job Status attributes to see the current user. But, recent releases show this right on the main WRKACTJOB display.

Anyway... The active user sessions will show up under the user who has signed on to them. If you have anonymous sessions, those will show up under the QTMHHTP1 userid.

However, there are miscellanous other things, such as SQL jobs, etc, that only switch userids for a very short time (a second or so) and then switch back to the original QTMHHTP1 userid, so you should be aware that those jobs are also part of Profound UI and need to be there for certain widgets to function properly. There are also jobs that are waiting for someone to connect, and jobs that are responsible for running the HTTP server itself that are there... these wouldn't be "active sessions", but would still be necessary for proper operation.

Does that help?

[dieter]

Thank you for your answer.

We are on V7R1, so in wrkactjob we can see the current user. Normally our authentication way is kerberos.

I think it is OK for me to use wrkactjob for determining if users are working with a special instance. Normally our users don't use anonymous calls. So if i can't find a user with a "normal" name (not QTMHHTP1), i can be sure that no user works with that instance. It is not important for me to detect all jobs of a user. I only want to know if the instance is free for maintaining.

ps:
Scott, i heard from your health problems. All the best wishes from here. It was announced that you will take part via video conference on the MIDRANGE EVENT „IT-POWER“ in Stuttgart (Germany) next week. I hope this will be possible.

Dieter

[thutcheson]

My understanding is that you can't really see all the users who are currently active, but rather only those who have opened connections from Profound UI to the iSeries.

• for instance, a user could have initiated a batch interactive session through a tab in the UI but left it go stale and thus not truly be active. The session could still be waiting for a request from the UI that never comes.

Is this correct?

Is there even a way to see UI sessions that have interacted with the iSeries within a certain amount of time? Manually I guess you could look at each job but we have someone who just wants to run a report.

-Thanks

[Scott Klement]

Hmmm... I think what you're saying is that if someone opens up a PUI screen on their display, then just leaves that display idle (switches and does work in another window, or walks away from the computer, etc) the session will remain active on the IBM i. That is true, but it's no different than 5250 -- if someone opens a Client Access session and then just leaves it idle, the same thing will happen, right? For example, if they forget to sign off and go home for the night, the Client Access session will remain connected, and this will appear to be an active session to the server. And the same is true of Profound UI, if you open up a session and go home for the night, it'll sit there and look like an active session.

Like 5250, it's possible to configure a time out that will occur if the user does not submit a screen for a certain amount of time. By default, Profound UI is configured to disconnect when the session has been inactive for 60 minutes, but this time interval is configurable.

Profound UI does have JavaScript code in it that will notify the server if you close the window, or navigate to another site, etc. That way the server sessions will get closed down if the user leaves the page, so server sessions will not simply sit there "stale" when the PC is not looking at them.

It's possible to create stale server sessions by powering off your PC (since the JavaScript can't tell the server to close if it has no power) or by suddenly cutting off the network connection, etc. If this happens, it'll still close the session down when the timeout interval is reached, of course. Our experience is that this happens very rarely, but if you're in a shop where this happens frequently for some reason (such as doing mobile access over a network that isn't very reliable) then you can configure your timeout to be a lower value so that this is detected sooner. You can also enable keep-alives so that the timeout isn't simply due to the user not typing something for awhile, but is truly due to the network or power being disconnected.

Is there a particular circumstance where you're having trouble with an inaccurate count of active users? If so, please explain the situation and I'll see if I can recommend something that will help.

[thutcheson]

Fantastic - thanks for that clear and complete explanation! We have noticed sessions that seem to hang around but we have not confirmed that they hang longer than the timeout setting. If we find anything that doesn't work as you described I will let you know.