Answer Wiki

I’m not aware of any way to do this. There is the inactivity time out, but I guess you’re talking about jobs which may still be active. If you want to do this for all users in a subsystem you could end the subsystem after a certain amount of time.

If you end interactive jobs, you may end up with problems with whatever applications the users are running. Why do you want to do this?

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 10 &nbspReplies

There was an error processing your information. Please try again later.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

If you are trying to protect possibly sensitive information being left on a screen when a user leaves his/her desk for a period of time without logging off, then the inactivity timer is the way to go. You need to make sure however that your software will recover from a job being terminated.
Anything else would have to be done programatically. Build in a process that checks how a long a job has been running and if it exceeds your parameters, kill the job. This also has risks of losing data or corrupting data.

I have that set on my system to 180 minutes. The action taken is in QINACTMSGQ which I have set to *ENDJOB. The users complained about it at first. Now they just remember that if they don't use the system it will log them off. If they have left an interactive job on a maintenance screen they could lose what they have done on that record, but nothing else. I've been on the AS/400 since it first came to market and I've never had a problem using this feature.

The following CL will monitor the a message queue we have setup for the 'QINACTMSGQ' and end jobs that have execeeded the value specified in 'QINACTITV'. We also have code to not log off QSYSOPR. We have used QSYS/INACTIVE as the message queue to monitor. The program sends a message to QSYS/INACTKILL when a job is ended or spared. This has worked for several years.

We have been doing this for quite a while with no problems. During the day we capture user stats for QINTER using API QUSLJOB. We capture the amount of cpu time for the job and store it in a very simple file (four fields). Then every two hours we run the job again. This time we check the CPU time against the users CPU time from the prior check. If the number is the same, we end the job, otherwise we update the CPU time in the file and move on to the next user. Starting at 6 PM we check every hour to minimize locks which could slow the nightly backup.
If a user just presses the enter key one time in the two hours the CPU time will be different and their job will not be terminated.
Some users just talk away from their screens at the end of the day. Without this utility we would have lots of problems.
By the way, this job starts automatically at IPL and only ends when we power down the system. We use DLYJOB to control how frequently the job runs, i.e. every two hours during the day, every hours at night.

You should be aware that the QINACTITV system value does not monitor each interactive job individually - It basically "wakes up" and checks the status of each current interactive job every X minutes - with X being the QINACTITV system value. Action (based on the value in the QINACTMSGQ system value) only occurs if the user job been inactive since the LASTtime the job was checked. Yeah, it's goofy.
So, if you set QINACTITV for 180 minutes a user job could be inactive for up to almost 360 minutes before any action would be taken.
We just had a requirement to implement this for a 30 minute timeout and noticed that the timeouts were frequently more than 30 minutes. After a bunch of digging I actually found IBM documentation (which I can't find at the moment !) that describes what QINACTITV does.
As far as user jobs being terminated and a possibility of data loss - there is a certain amount of education for the users.
What you can also try is to set the QINACTMSGQ value to *DSCJOB and set the QDSCJOBITV to 8 hours. What that will do is disconnect any job which has been inactive and then actually terminate the job 8 hours later. The user can sign back in any time within that 8 hour period and resume where they left off. BUT there is a gotcha. All user workstations must have a name and not be dynamically assigned a QPADEVxxxx name.
Regards
Mike

Most comments so far are correct.
The inactivity timer (available through QINACTITV and QINACTMSGQ system values) is system-wide and cyclic. It does not operate on individual jobs, but rather on all interactive jobs at essentially the same time when each inactivity interval cycle completes. That means that if session "inactivity" began just after the system ran its test in one cycle, then that session would be marked as having been active during that cycle. Only when that session remained inactive during the entire next cycle would it receive the configured action. For most sites, that's not a big problem.
Also, there are four "actions" that can be taken through the system inactivity timer -- end jobs, disconnect jobs, send a message about the job to a message queue or do nothing (ignore the inactivity through setting the interval to *NONE). As far as the system inactivity timer is concerned, the chosen action will be taken against all jobs that meet the criteria. A "disconnected" job can be re-entered by the user; activity will take back up right where it left off. An ended job is... ended. By choosing to send a message to a message queue, you are able to have a program that you wrote make some decisions. Your program can receive the messages and choose to end some jobs, disconnect other jobs, send messages to the session, whatever you're innovative enough to do.
Sessions cannot be disconnected if they are running within a device that is named according to default system naming. (They may be ended, however.) Sessions using devices with default system naming are exempted from disconnection for a couple of reasons, at least one of which allows some useful capabilities to some sites. Because of this, you should have a naming standard that is enforced through exit programs or system values if you want to manage inactivity. If you write your own programs to manage this, you should consider also exempting default-named devices.
Disconnected jobs have an additional system value -- QDSCJOBITV. This tells the system how long a session may remain in disconnected state before the job is eventually ended. If the user enters profile and password before that time is up, the session can be re-entered without disruption. Be aware that re-entry might be impossible if the current job has swapped to a user profile that has no password.
One minor elaboration on one point. The inactivity timer doesn't necessarily look at CPU times for jobs. Jobs can be active without using CPU. Consider also watching for 'interactive transactions'. Group jobs, jobs that spawn child BCI (Qshell/PASE/Java) jobs, or even jobs that might run in SQL server mode or internally communicate with a host server so that CPU is being used in a separate batch job while the interactive job is in a wait state, these and other conditions _might_ skew results.
For most sites, the inactivity timer can work "good enough". Just know your own system.
Tom

Thanks all for response,
For Gilly regarding question about why we want to do this our software supplier has claimed that someone who is signed on for more that 8 hours is using more than 1 licence (we have a user based licence)? I'm under the impression that going inactive still leaves the user signed on in the ideal world we aould wnat to end the job. If data does become corrupt we would fix.

If you are strictly looking to end sign on interactive sessions, knowing they could have other connectivity, and you have a little program knowledge then this may help. You could leverage the registration facility under job notification (QIBM_QWT_JOBNOTIFY), which for this particular situation is actually just a data queue. The program data of (0001*ANY *ANY) triggers an entry when someone actually signs on to any subsystem. Activation will occur one the subsystem starts. You could then have a program running in batch set to a delay of (###) and upon execution call a program that will read the data queue (job name, user, and job number). The program can manage via a file or just create a unique job scheduled entry to occur one time at the designated interval to end the job. It depends on how fancy you want to get at this point but a file may be more beneficial depending on wither you are going to notify the user before ending the job because you could leverage the cycle to determine how far in advance you want to notify the user. Via a file during each cycle it could update the file then turn around and read though each entry and react for those within the expiration time frame.

My problem is that I have one virtual session that terminates even while the user is still typing. This usually happens several times a day and is not only irritating to the user, but she loses all her work on a given order and has to start over for that order. What can be causing this?

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy