|
All of the answers that you received are good suggestions and will work just fine, but I have another tactic that I've used to discourage interactive queries that was much more fun. Typically when a user runs a big honkin query from their terminal, I would call them to ask them not to do that but... they weren't there!!! Of course they weren't there. After tying up their terminal with a 2 hour query, they weren't going to sit at their desk. They were out yakking with someone else. :( So, I'd send them a break message that ask informs them that their query is making the system run slower and that I had dropped there priority to 99 so they probably wouldn't get their results until much later. As you know, a break message stops all activity at the current job until someone answers it, so the query would be suspended until they got back to their desk. :) I'd make it a point to send several messages through out the day so as to gaurantee that the query wouldn't finish by quitting time, all the while freeing up the system for more appropriate uses. I never actually got around to this, but I was considering writing a little CL that would send break messages to the offending terminal every 5 minutes. That would bring the query to a virtual standstill. It didn't take them long before they begged me to kill their job so that they could submit the query to batch. :) OK, so changing the query run attribute is more effective, this method was more fun. jte Bob Clarke 3rd x4502 wrote: > Hello All. I've been off of the list for a while and recently > re-subscribed now that I've once again had additional AS/400 > responsibilities thrown at me - but it's nice to be back. > > Recently an old ongoing problem has reared it's ugly head and caused me > fits - that of rogue users running queries interactively during normal > business hours. This of course results in numerous complaints about > response time, etc. As I recall from way back then, there really wasn't > a whole lot one could do to stop or restrict these miscreants. However > quite some time has passed (since I've been involved or concerned about > the issue anyway), and I wondered if there has been any new light shed on > the matter. Also, we've since upgraded from V3r1 to V3r2 - any changes > there that might help? > > I hope I'm not beating a dead horse here - my apologies if that's the > case. Either way, I'd appreciate any feedback (short of anything > resulting in insult or injury, that is). Thanks in advance! > > Regards, > > Bob Clarke > > ------------------------------------------------------------ > > Name: WINMAIL.DAT > WINMAIL.DAT Type: Text Document >(application/x-unknown-content-type-txtfile) > Encoding: BASE64 -- John Earl johnearl@powertechgroup.com The PowerTech Group 206-575-0711 PowerLock Network Security www.400security.com The 400 School www.400school.com -- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.