BOUNCE Copyright (c) Allegro Consultants, Inc. 2017-03-02 NOTE: BOUNCE has been replaced by our KNOCKOUT program, one of our Toolbox products. For more information, please email info@allegrosupport.com BOUNCE is a program that allows you to automatically monitor the system and 'bounce' sessions that are 'idle'. BOUNCE is typically run from an always-running batch job. When BOUNCE starts, it expects a list of users & jobnames as input from $stdinx. Each input line is a single command, one of the following: END If an END command is found, no further commands will be read. An end-of-file is interpreted as an END command. IDLE jobname, user.account = seconds [ WARN | NOWARN] More than one IDLE command may appear, but the maximum number is about 40. Note that 'jobname', 'user', and 'account' may be exact or may use the usual MPE wildcards (e.g: @, or STAN??#). NOTE: if a user logs on as: hello mary.smith her jobname is empty (blank) (which will match "@", but will not match any other pattern). If the NOWARN keyword is used, then sessions matching this pattern will not be warned before being aborted. If the WARN keyword is used, then the session will be warned before begin aborted. NOTE: warning results in a sesion getting twice as much idle time as a "nowarn" session. If neither WARN nor NOWARN are specified, the most recent SET WARN or SET NOWARN value is remembered for this IDLE pattern. (The initial default at the start of BOUNCE is SET WARN.) If seconds is specified as NEVER (or 0 or 32767), then users matching this rule will not be bounced. LOOP seconds This command controls the number of seconds BOUNCE will wait at the top of its outer block loop. Setting this number to a very small value will waste system resources. The LOOP value defaults to 60 if BOUNCE is run from batch, and 10 if run interactively. SET [ WARN ] [NOWARN ] [ GLOBAL # ] [LOGWarn] [LOGAbort] [NOLOG] The SET command is used to specify the settings of various BOUNCE options. The following options are available: WARN (set by default). WARN causes BOUNCE to warn users before they are before they are aborted for idleness. NOWARN Tells BOUNCE to not warn a user when they are about to be aborted for idleness. Note that a "warned" user gets twice the idle limit, but a "nowarned" user gets only the specified idle limit. GLOBAL # The GLOBAL option specifies the number of seconds users who do not match any of the IDLE patterns are allowed to be idle before being (optionally warned) and aborted. If SET NOWARN is in effect as of the end of parsing the BOUNCE commands, then such users will NOT be warned before being aborted. The initial value of the GLOBAL timeout is 0, which disables it. LOGAbort When BOUNCE aborts a user for idleness, if LOGABORT is true, then it will send a message to the system operator reporting the bounce. This option can be cancelled by using NOLOG. LOGWarn When BOUNCE warns a user about idleness, if LOGWARN is true, then it will send a message to the system operator reporting the warning. This option can be cancelled by using NOLOG. NOLOG NOLOG turns off LOGABORT and LOGWARN. Default: LOGABORT and LOGWARN -------------------------------------------------------------- BOUNCE parses the input when it starts up, and then goes into its main loop, pausing for the number of seconds specified in the LOOP command (default value is 10 if BOUNCE is run interactively, and 60 otherwise). Whenever BOUNCE wakes up, it examines every session (ignoring batch jobs). If a session has been 'idle' since we last looked at it, then we will do the following: 1) compare the jobname,user.account of the session against the pattern specified in the FIRST IDLE command. If it matches, then we check to see if the session has been idle for the number of seconds specified in that command (or more). If so, then we do the following: a) if the session has not been warned about idleness, we warn it and remember that the warning has been given; NOTE: a warning is not given if either: 1) a NOWARN keyword was on the matching IDLE command; or 2) neither WARN nor NOWARN were specified in the IDLE command but a SET NOWARN command preceded the IDLE. b) otherwise, we abort it (via an ABORTJOB). 2) Otherwise, we go to the next IDLE pattern and repeat the check above until we either find a matching pattern or exhaust the list. 3) If no pattern matches, then the GLOBAL timeout value is used to see if we should abort the session. An idleness limit of 0 or 32767 means: inifinite...don't abort matching sessions for idleness, ever! By the way, a session is 'idle' if it has used 0 milliseconds of cpu ANYWHERE in its process tree since the last time we checked it. Whenever we notice a change in cpu utilization, we reset all flags/counters associated with a given session. The implication of the 'warn, then abort' policy is that a "warned" session must be idle for TWICE the amount specified by the matching IDLE pattern before it will be aborted. NOTE: some system managers have chosen to set "job security" to "high". This means that "ABORTJOB" cannot be performed across account boundaries (or perhaps user.account boundaries). If an ABORTJOB done by BOUNCE is rejected because of job security, BOUNCE will try a workaround. You can avoid this problem by running BOUNCE as MANAGER.SYS, or by running a 'god' program before running BOUNCE. -------------------------------------------------------------- Examples: Each of the following examples shows a set of BOUNCE commands and briefly discusses their results. Example #1: IDLE JOHN, @.@ = 10 IDLE @, MGR.SYS = 20 WARN IDLE @, @.@ = 99 Since no SET WARN or SET NOWARN commands were used, and no IDLE commands used the NOWARN keyword, all of the sessions will be warned before being aborted. The session JOHN,MGR.SYS has an idleness limit of 10 (i.e.: he is warned after 10 seconds, then aborted after 10 more), even though the jobname, user.account also matches the second IDLE command! Example #2: SET NOWARN IDLE JOHN, @.@ = 10 IDLE @, MGR.SYS = 20 IDLE @, @.@ = 99 This works just like the prior example, but users are not warned ... instead, they are simply aborted. When JOHN,MGR.SYS is idle for 10 seconds...he is aborted. The SET NOWARN is useful at sites where users have learned to respond to the idleness warning by hitting return a few times. Example #3: SET NOWARN IDLE JOHN, @.@ = 10 IDLE @, MGR.SYS = 20 WARN IDLE STAN, @.S@ = 5 SET WARN SET GLOBAL 34 When JOHN,MGR.SYS is idle for 10 seconds...he will be aborted without warning. When BEA, MGR.SYS is idle for 20 seconds, she will be warned, and then aborted after 20 more idle seconds. STAN, STAN.SIELER will be aborted without warning after 5 seconds. What about users who match none of the idle patterns? They, like STEVE.COOPER, will be warned after 34 seconds (the GLOBAL value) and aborted after 34 more seconds of idleness. --- Here is a sample job stream: !job bounce, manager.sys;outclass=,1 ! !run bounce.pub.allegro idle @, lazy.sloth = 5 warn loop 10 end ! !tell manager.sys; bounce done ! !eoj The above job will abort any user logged on as "lazy.sloth" after a total of 10 seconds of idleness. (They'll be warned after 5 seconds of idleness, and aborted after another 5 seconds of idleness.) Note: we generally don't change the "idle" loop to something as short as 10 seconds ... particularly on systems with many users logged on. Why? It costs CPU & time for BOUNCE to determine if a user is idle, so you don't want to waste it by checking too frequently. On the other hand, if you set IDLE to 3600 (one hour), and said "logoff lazy.sloth after 5 seconds of idleness", lazy.sloth would get an average of about 30 minutes of idleness before we notice them. -- BOUNCE 20201012