🚀 go-pugleaf

Greetings all,

I'm posting this to the list to maybe save some people some of the head
aches that I've had which were caused by a design flaw in their idle
processing routines.  Even though SCI admits this is a design flaw, they
are classifying the proper operation as an "enhancement request" since
the code is "working as designed" even though the "design is flawed".
Figure that one out!

THE SYSTEM:   VM/ESA 1.1.1 and VMMONITR/E 1.0.

THE PROBLEM:  Active users are erronously getting forced or force
disconnected because VMMONITR calculates incorrect idle time values.

THE HISTORY:  Somewhere between here and VM/SP 5.0 (big jump) IBM
provided a standard interface for vendors to obtain performance data.
SCI uses this interface to report idle data as well.  CP provides this
data based on the "MONITOR SAMPLE INTERVAL" command which we have set to
2 minutes.  VMMONITR processes this buffer to calculate the idle times
based on the "SAM IDLE INTERVAL" directive which we have set to 240
seconds (4 minutes).  These timers are not synchronized in any way which
causes my problem no matter how SCI has me tweek any of the settings.
This creates an exposure window:  CP provides a data buffer, a user who
was idle for 90 minutes starts working again, VMMONITR processes the
data provided by CP and calls the idle exit telling it that this user
has been idle for 90+ minutes when in fact the user is currently working!
(Insert your favorite value for "90" above.)

The maximum size of this exposure is really a fraction less than the
length of your MONITOR SAMPLE INTERVAL.  You'd think that it would be
hard for a user to start working again after exactly "X" minutes of idle
time and hit this two minute exposure window.  My inspection, however,
indicates that with an average of 90 users logged on at any one time
over an 8 hour period, 16 users will be incorrectly tagged as idle and,
in our case, FORCE DISCONNECTed or FORCE logged out.  That's 2 mad users
every hour.  (They don't mind getting dropped IF they are idle!)

THE SOLUTION:  The solution is really more of a circumvention rather
than a solution and SCI certainly couldn't or wouldn't help with it.
Oh, they offered suggestions and their support team did the best they
could:  I have no complaints with them.  The developers on the other
hand....  Oh yes, my circumvention.  It only took me an hour to discover
a field in the VMDBK that records the last time that a user started a
transaction.  Now the values are cryptic (at least to me), but I worked
out a little REXX exit that uses this value to calculate my own idle time
value.  Yes, I know we're not supposed to peek at control blocks directly,
but it's the only solution I could come up with without SCI's help.
Anyway, my value is not 100% accurate, I'm sure, but it appears to augment
SCI's value very nicely.  The idle exit only takes action if BOTH values
indicate the user should be forced to logout or disconnect.  My value is
almost always with 5 minutes of SCI's value except:  1)  When it fixes
this whole problem they say "92" minutes and I say ".233" minutes and
2)  sometimes, for reasons unknown, SCI reports "0" minutes idle and I
calculate "63" minutes idle (no action taken and this clears up next time
the idle exit is called.  Why call the exit if the user is "0" minutes
idle any way, SCI?)

THE SUMMARY:  If anyone is trying to do idle user processing with VM/ESA
1.1.1 and VMMONITR/E 1.0, it won't work and your users will hate you.
If you'd like a copy of my idle exit, just let me know and I'll send you
a copy.  If you want to jump on the band wagon, I don't even have a
track number for my "enhancement request", but my problem number is
212557.

I hope that I may have saved someone some of the grief that I have had.

Thanks for your time,  -Mark


Mark F. Harsen                         Bellnet:   (417) 836-4392
Systems Programmer                     Bitnet:    MFH043W@SMSVMA
Southwest Missouri State University    Internet:  mfh043w@vma.smsu.edu
Springfield, MO.  65804                ICBM:      93 17 N / 37 63 W