We do not want to time out everyone, only a couple of selected shipping users. I know there is a way to do this progamatically, but it has been a lot of years.

The QINACTITV system value sets the interval between inactivity tests. If QINACTITV is set for 15 minutes, for example, then the system will run a system-wide inactivity test every 15 minutes. It may be important to understand that this interval is for the whole system and not for each individual session.

The QINACTMSGQ system value sets the action that the system will take when a session is determined to be inactive (i.e., when no activity occurred in the session during the previous interval). The possible actions are:

• *ENDJOB — a full session signoff,
• *DSCJOB — a disconnect, like a password-protected screen-saver, and
• message queue — a message is sent to the message queue named.

Both *ENDJOB and *DSCJOB will apply to everyone. The message queue is nothing more than that — a CPI1126 message is sent to that message queue for each inactive session, nothing is done to the session jobs.

The message queue option would be what allows you to make individual decisions. You would submit a never-ending message queue monitor program that received each message and chose an action based upon user. (It might be possible to adapt a message monitor in Management Central so that it called a program, passing in details from the message. I haven’t looked at how that might be done.)

You might submit a job that assigns a Break Handling Exit Program (or Break-handling programs) to the named message queue (after first clearing the message queue to remove old messages). The job would then simply wait until you ended it, perhaps waiting indefinitely on the arrival of a data queue entry. The break-handler program would then run every time CPI1126 arrived on the message queue.

The logic of the break-handler would be whatever you wanted it to be. Much of the code can be copy/pasted right out of the Info Center.

Tom

That is way more complicated than we need it to be.

That is way more complicated than we need it to be.

Quite possible. Still, it’s less complex than any alternatives that I know other than purchasing a product (or obtaining some free-ware solution).

The restriction to some set of users is what complicates things.

If those users are limited to a particular application screen, then changes can be made to the display file and the application program. The display file can signal a timeout to the application program and the program can then issue a signoff. (Change to the DSPF is mostly a recompile with new attributes specified.)

But that process would apply to any user in the same screen unless the app implemented logic to discern different users. And if the user was in any other screen function that wasn’t similarly changed, there would be no timeout signal sent. (System displays such as WRKSPLF would have no timeouts at all.)

Tom

we use the QINACTITV too

I do it this way

ftsusdp4d cf e workstn
f usropn
f maxdev(*file)

…
…

// Override waitrcd on the display file for shorter interval
gCmd = ‘OVRDSPF FILE(TSUSDP4D) TOFILE(*LIBL/TSUSDP4D) WAITRCD(30)’;
gMsgid = utlty_RunCmd(gCmd);
// With override in effect, open the display file
if not %open(tsusdp4d);
open tsusdp4d;
endif;

- – - –
/free

if isTimeoutUser;
// Display the screen logic
monitor;
// Write screen, wait for input
write SCREEN1;
read tsusdp4d;
on-error 1331;
exsr @exit;
endmon;
else;
exefmt SCREEN1;
endif;

Wrap the display the screen logic where -
block 1 uses read/write and where -
block 2 uses exefmt.

At program initialization determine if the userprf is to be timed out
or not timed out and condition block 1 or block 2 to display the
screen accordingly.

John B.

Thanks John, that was what I was after. I only need it for two programs and the few user’s that use them.

I appreciate all of your responses.

Thank you
Lenny

Nice trick, sometimes we tend to look for too complicated a solution when some thinking can provide a relatively simple way to solve a problem that at first seems very complicated.

Having used the QINACTMSGQ solution proposed by Tom in the past I can assure you it’s not overly complicated and has the advantage of being selective in it’s application.

Splat,

One thing you must be aware of, is that some of us work in larger IT shops and getting access to system values is nearly impossible, or takes weeks to get done because of the chain of command.

One thing that must be considered is bureaucracy and working around it to achieve a goal.

I am not opposed to trying new things, but I have to have the time and authority to do it.

Lenny

AS400Lenny,

I realise that various shops are organised differently and developers have different resources available.

I was commenting on the particular approach, not the implementation.