jkzup wrote:I went to that link earlier this morning and twice submitted a disconnect request. I still couldn't log on. I shut down my PC a few hours and just now tried logging on again; this time I got in. I suppose when I request a disconnect it may take quite a while for it to be executed.
I hope something can be done to restrain those who place too great a burden upon the system and thereby punish those of us who try to minimize their impact and use the system responsibly. Slow system response and system lockouts are quite frustrating.
Tell me... The fact that the disconnects are, just guessing, running on the same VMWare system as the z/OS system may have something to do with this.
As for me, I do what I can by canceling jobs that are obviously looping and regularly clearing the held output queue when some, excusez-le-mot, idiots leave a million lines of output in the spool, but I do have other interests - this week I was on holiday and doing this kind of work from the
Open-BPM - Standalone 3270 Emulator is somewhat over the top - I did it once and then again tonight after we came home, with about 2000 jobs on the output queue - just canceled the whole lot, excuses if your output was still of interest.
"sysprog" did a great job by revoking all TECHxxx userids, but they are now back, just named ZINDxxx and AAx000x - I did slow them down somewhat by deleting all 'TECH*.**' datasets, but they just create new ones by the truckload, occasionally with totally ridiculous allocation parameters (like PDS'es with a secondary space of 50 cylinders for a primary space of one cylinder), or GDG's with 100 generations... What makes matters even worse is that one single 'XXn000n' userid may in fact be shared between in some cases 30 users who all create their own set of similar datasets...
If
I had more RACF authority, I would mercilessly revoke any userid that leaves six jobs with more than one million lines of output on the spool, or cannot be bothered to think about a job that has been clocking up more than 18,000 seconds of CPU time...