Dezhi Systems support site

Most times while I'm using TSO/ISPF, system response is very slow. Oftentimes I must wait an inordinate amount of time (10, 15, 20 seconds or more) even when overtyping text or scrolling. Can anything be done to improve system response?

Thank you

JK Zup

The system capacity is limited and there are more and more online users, sometimes up to 70 users at the same time.

The TSO sessions have higher priority than other tasks, unless your task is resource consuming, such as dataset size sort in ISPF 3.4.

If you constantly experience the slow response, please let us know your TSO userid, the time you normally logon, and the tasks you perform in TSO, so that we could find out the cause.

sysprog wrote:The system capacity is limited and there are more and more online users, sometimes up to 70 users at the same time.

The real problem is that companies in India offload their trainees to the system, and many of these people assume that they are all alone working on a Windoze box, submitting sometimes a dozen of the same jobs when the first one doesn't finish because it simply loops. There are also people who just log off without clearing the output, in one case over SIX million lines.

Meanwhile I'm thinking if we could raise some funds to upgrade the hardware, let say, donate via Paypal. Doesn't need to be a supre computer but now the bottle net is the CPU, also the I/O. If we can have a server with 2 x quad core Xeon and 14 bay SAS/SATA array that will be much better.

How many people would support this idea?

Thanks,
SFAN

sfan wrote:Meanwhile I'm thinking if we could raise some funds to upgrade the hardware, let say, donate via Paypal. Doesn't need to be a supre computer but now the bottle net is the CPU, also the I/O. If we can have a server with 2 x quad core Xeon and 14 bay SAS/SATA array that will be much better.

I would not object to giving paying users better access times, but the system is quite fast at silly hours... The main thing is to get rid of the Indians or severely restict the incoming connections from one IP address - yesterday I cancelled four jobs that had all clocked up well in excess of 5000 CPU seconds, all of them from the AAn000n userids...

I don't do anything besides simple browsing and editing of my datasets and background PL/I compile jobs. (Those compiles have also begun taking much longer to run -- they used to run in only a few minutes, now it's several times as long.) I purge my jobs from the hold queue as soon as I've viewed them, immediately after they finish.

I sincerely doubt anything I'm doing is bogging down the system. I am not the cause, but I surely am suffering from it.

Thank you

JK Zup

Just after I made my last post here, I tried to logon and it was rejected; my ID is "already in use". Yesterday when I tried logging on the system hung ("LOGON PROCEEDING") and I tried disconnecting the session. Evidently it didn't work. I have just now tried twice at the support site to disconnect but I still can't terminate the session or reconnect to it. (Yes, I tried logon with the "reconnect" option selected -- it didn't work. My ID is ZUMZUP.)

This is very frustrating. I strive to use the system responsibly. I feel I'm being punished for others' excesses.

JK Zup

Use below link to cancel your TSO ID, if you get error "your ID is already in use".

cgi-bin/mainframe/mainuser

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.

Thank you

JK Zup

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...