QINACTITV Sysvalue OS400
Hello,
our iSereis (V5R3M0) end jobs in 1h or 3h intervalls (many jobs at the same time)
with CPI1127.
Sysval QINACTITV is: 180 min (3h)
e.g.abeou 300 Jobs are ending at 12:05 15:05 18:05 ; not individual at Session.
Any idea how often QINTER checks QINACITV ? which program ?
Thank you for fast feedback !
Regards
Robert
our iSereis (V5R3M0) end jobs in 1h or 3h intervalls (many jobs at the same time)
with CPI1127.
Sysval QINACTITV is: 180 min (3h)
e.g.abeou 300 Jobs are ending at 12:05 15:05 18:05 ; not individual at Session.
Any idea how often QINTER checks QINACITV ? which program ?
Thank you for fast feedback !
Regards
Robert
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
hello Barry, Tom
first : thanks a lot for fast reply to my problem with QINACTITV !
My undstanding of QINCTITV was, that system will check (nearly) immediatelly, if jobs
are inactive for specified minutes in sysval QINACTITV.
But - you are right - this value meens first, in which "timeslices" the system checks Job of inactivity.
Unfortunatelly "Inactivity-time" is also also defined about QINACTITV value.
It would be better, if two values exists for these reasons :
1. value for time intervall, in which system checks inactive jobs
2. value how long (in minutes) "inactive" is defined.
Best Regards
Robert
first : thanks a lot for fast reply to my problem with QINACTITV !
My undstanding of QINCTITV was, that system will check (nearly) immediatelly, if jobs
are inactive for specified minutes in sysval QINACTITV.
But - you are right - this value meens first, in which "timeslices" the system checks Job of inactivity.
Unfortunatelly "Inactivity-time" is also also defined about QINACTITV value.
It would be better, if two values exists for these reasons :
1. value for time intervall, in which system checks inactive jobs
2. value how long (in minutes) "inactive" is defined.
Best Regards
Robert
Robert:
Note that there is also system value QDSCJOBITV that sets an interval for the time a job may be in 'disconnected' status. So, you might set QINACTITV to 15 minutes, QINACTMSGQ to *DSCJOB and QDSCJOBITV to 180.
After a 15 minute inactivity cycle, inactive sessions will be forced to 'disconnected' status. The jobs will remain, but the signon panel will be displayed. The user would enter profile and password to re-enter the job where it left off. (Kind of like a screen-saver with password.) But if the job remains disconnected across a full disconnect interval, then that job will be ended. By tweaking both QINACTITV and QDSCJOBITV, you might get more useful control.
Setting QINACTITV to a much lower interval will allow the basic cycle to be more precise. (Maybe you'd use 30 minutes or maybe 10 minutes.) Setting jobs to 'disconnected' generally keeps work from being absolutely interrupted, only a profile/password entry is needed to get going again. Setting an interval separately on 'disconnected' jobs also brings the ability to track jobs that are in 'disconnected' state.
Tom
Note that there is also system value QDSCJOBITV that sets an interval for the time a job may be in 'disconnected' status. So, you might set QINACTITV to 15 minutes, QINACTMSGQ to *DSCJOB and QDSCJOBITV to 180.
After a 15 minute inactivity cycle, inactive sessions will be forced to 'disconnected' status. The jobs will remain, but the signon panel will be displayed. The user would enter profile and password to re-enter the job where it left off. (Kind of like a screen-saver with password.) But if the job remains disconnected across a full disconnect interval, then that job will be ended. By tweaking both QINACTITV and QDSCJOBITV, you might get more useful control.
Setting QINACTITV to a much lower interval will allow the basic cycle to be more precise. (Maybe you'd use 30 minutes or maybe 10 minutes.) Setting jobs to 'disconnected' generally keeps work from being absolutely interrupted, only a profile/password entry is needed to get going again. Setting an interval separately on 'disconnected' jobs also brings the ability to track jobs that are in 'disconnected' state.
Tom
ASKER
Hello Tom,
thanks again for your explanations.
This solutioin should fix the Problem, that about 300 Jobs are ended by QINTER in the same moment(12:05),
which causes sometimes problems (QEZJOBLOG-queue locking, recovery of devices etc.)
Anyway, we will splititing our "Monster-SBS" with more than 3.500 Jobs in several Subsystems, according to IBM recommendation.
Best Regards
Robert
thanks again for your explanations.
This solutioin should fix the Problem, that about 300 Jobs are ended by QINTER in the same moment(12:05),
which causes sometimes problems (QEZJOBLOG-queue locking, recovery of devices etc.)
Anyway, we will splititing our "Monster-SBS" with more than 3.500 Jobs in several Subsystems, according to IBM recommendation.
Best Regards
Robert
Robert:
If the actual problem is a resource bottleneck, then a never-ending message monitor program can be written and assigned to the message queue named in QINACTMSGQ. It could receive the messages and stretch out the wait between ending each job rather than having the subsystem handle them.
It could also have a database (files, user indexes, whatever) to make decisions over. Maybe some users are allowed to stay inactive, maybe some devices never need to end, maybe sessions in certain subsystems,... whatever. Upon receiving each message, the program would choose the action to take -- some jobs might be ended, some might be disconnected, others ignored.
Tom
If the actual problem is a resource bottleneck, then a never-ending message monitor program can be written and assigned to the message queue named in QINACTMSGQ. It could receive the messages and stretch out the wait between ending each job rather than having the subsystem handle them.
It could also have a database (files, user indexes, whatever) to make decisions over. Maybe some users are allowed to stay inactive, maybe some devices never need to end, maybe sessions in certain subsystems,... whatever. Upon receiving each message, the program would choose the action to take -- some jobs might be ended, some might be disconnected, others ignored.
Tom
Robert,
The inactivity timer for a subsystem starts when the subsystem starts. After the monster subsystem is split in several smaller ones, consider staggering the start-up of the new subsystems by a few minutes. This will allow the inactivity checks to be staggered as well.
Barry
The inactivity timer for a subsystem starts when the subsystem starts. After the monster subsystem is split in several smaller ones, consider staggering the start-up of the new subsystems by a few minutes. This will allow the inactivity checks to be staggered as well.
Barry
Hi Guys
I have been on holiday for a few weeks, (I do Ironman Triathlon for fun).
This has come up a few times. I will did out the code I did last year (it takes less the 0.2% on a 720) an make it available; we can then make it shareware / freeware as a joint venture.
Dave
I have been on holiday for a few weeks, (I do Ironman Triathlon for fun).
This has come up a few times. I will did out the code I did last year (it takes less the 0.2% on a 720) an make it available; we can then make it shareware / freeware as a joint venture.
Dave
Barry has given the correct answer. The QINACTITV interval defines a "system-wide" interval; it cannot be directly applied to specific sessions. There is a direct implication from this.
Assume a QINACTITV of 180 minutes. And assume the next interval begins at 11:05 AM.
Now, at 11:06 AM, you have a session that goes inactive. At 2:05 PM, the 180 minute inerval ends and OS/400 runs a check of all sessions. Your session has only been inactive for 179 minutes at that time, so it is skipped over. The next time inactivity is checked will be 5:05 PM.
If you start some activity at 5:04 PM, then your session will have had 358 minutes of inactivity but will slip past the inactivity timer. I.e., it won't be caught by the default system inactivity timer.
Again, the timer is "system-wide" not for each individual session. It's handy as a free feature, but isn't as precise as some sites need. If you need definite precision, you'll need to acquire a 3rd-party product or do some significant programming.
The programming may need to track each individual job as they start and end as well as track interactive transactions within timers that _you_ create for each individual interactive job. (It all depends on exactly what you want to happen.) There is a potential for some significant CPU usage if you have a lot of users starting and stopping jobs.
Dave Slater has a good start on such a function (and I _really_ need to find time to get back to him on that) and might be willing to work with you on it. Barry's apparently at least looked over the problem and might have more help that he can give. I can't do much to help due to contractual obligations in this area except to say that either of those two guys are worth listening to.
Tom