Re: QINACTITV fails to sign user off -- MIDRANGE-L

Was the job at device A14 an INTeractive job in DSPW status for the entire time, without any increase in the "elapsed number of interactions" at the interactive display for the full sixty minutes? Perhaps an employee was actually using the INV001 program for a long time after starting that program? What evidence is there that no interactive transactions [or time in other than DSPW] had transpired to extend the time since the prior interactive response activity; i.e. what is known to contradict the results seen? There is no reason to expect the job was prevented from interactive timeout by that inactivity timer since eventually the job did end. Thus the most obvious explanation is that there was at least one interactive interaction within the plus\minus hour before the CPI1127. Had the job been a passthru or TELNET target device effecting indirection from the original client, or left unattended in a feature that does not allow the timeout to end the job, then that job would not be impacted by that inactivity timer even after five hours.

The message indicates that /all jobs/ were ended for the device, so be sure to review if any other jobs were active to that device from either group or secondary jobs. If INV001 seems improbable to have or allowed a user to have kept the workstation active until 19:## then perhaps it was another job at the device that four to five hours.

Note that a very long running transaction, for example several hours even just waiting, could have been performed. While awaiting completion of the transaction, the job would not be in DSPW; i.e. as far as the OS is concerned, doing real work and thus ineligible for timeout by the interactive inactivity timer. Also note that extensions to the time available to the job may easily result from buffered keystrokes allowing a job to continue with further transactions. Of no consequence, but noting also that a buffered /function/ key would also count as an interactive /interaction/.

Regards, Chuck

dale janus wrote:

I have QINACTITV set to 60 minutes and it has always worked fine.

But on Friday, one of our users started a job at 15:49 and it did
not time out until 20:42, about 5 hours later. Naturally, this kept some files active and they could not be processed by our nightly batch jobs.

Any suggestions as to what caused this and how I can prevent it from happening again?

I know I can shut down QINTER and I used to do that, but I am
trying to figure out what caused this error.

The user is running client access, and I suppose it is possible she ended the windows job without signing off the 400. Could that
cause the inactivity timer to goof up?

How do you check for that sort of thing?

*...+....1....+....2....+....3....+....4....+....5....+....6....+

*NONE Command 11/20/09 15:49:28.372144
QCADRV QSYS 03B7 INV001C INV5LIB 006D
Message . : 4100 - OVRDBF FILE(QUOTE2) TOFILE(*FILE)
RCDFMTLCK((QTREC *SHRUPD))
*NONE Command 11/20/09 15:49:28.372224
QCLCLCPR QSYS 04A4 INV001C INV5LIB 0071
Message . : 4500 - CALL PGM(INV001)
CPI1127 Info 40 11/20/09 20:42:35.815752
QWTMEINA QSYS 048F *EXT *N
From user . . . . . . . . . : QSYS
Message . . . . : All jobs at work station A14 ended.
Cause . . . . . : All jobs at work station A14 have been ended,
since the amount of time specified in system value QINACTITV has
ended, and all jobs at the work station have not been active
during the time specified by the system value QINACTITV.
CPF1164 Comp 00 11/20/09 20:43:07.907008
QWTMCEOJ QSYS 00D7 *EXT *N
Message . : Job 924765/DIANNE/A14 ended on 11/20/09 at 20:43:07;
1 seconds used; end code 50.
Cause . : Job 924765/DIANNE/A14 completed on 11/20/09 at 20:43:07
after it used 1 seconds processing unit time. The job had ending
code 50. The job ended after 1 routing steps with a secondary
ending code of 0. The job ending codes and their meanings are
as follows: 0 - The job completed

Display System Value
System value . . . . . : QINACTITV
Description . . : Inactive job time-out
Time-out interval in minutes . . : 60 *NONE, 5-300