slow system response

This forum provides the support of Dezhi Mainframe systems. Please post your questions about logon, usage of our mainframe environment.

Moderators: sysprog, prino, sfan, steve-myers, Tim001

slow system response

Postby jkzup » Fri 19 Mar 2010, 14:42

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
jkzup
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06

Re: slow system response

Postby sysprog » Mon 22 Mar 2010, 14:36

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.
Regards,
sysprog
sysprog
 
Posts: 126
Joined: Wed 20 May 2009, 04:03

Re: slow system response

Postby prino » Mon 22 Mar 2010, 18:55

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.
Robert AH Prins
robert.ah.prins @ the.17+Gb.Google thingy
Some programming here :mrgreen:
prino
 
Posts: 479
Joined: Sat 06 Jun 2009, 21:41
Location: Vilnius, Lithuania

Re: slow system response

Postby sfan » Mon 22 Mar 2010, 20:50

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
 
Posts: 41
Joined: Wed 20 May 2009, 03:14

Re: slow system response

Postby prino » Tue 23 Mar 2010, 18:39

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...
Robert AH Prins
robert.ah.prins @ the.17+Gb.Google thingy
Some programming here :mrgreen:
prino
 
Posts: 479
Joined: Sat 06 Jun 2009, 21:41
Location: Vilnius, Lithuania

Re: slow system response

Postby jkzup » Wed 24 Mar 2010, 11:58

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
jkzup
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06

now I can't log on at all

Postby jkzup » Wed 24 Mar 2010, 12:14

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
jkzup
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06

Re: slow system response

Postby Rakesh kotha » Wed 24 Mar 2010, 13:54

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

cgi-bin/mainframe/mainuser
Thanks
Rakesh Kotha
CICS & MQ System Programmer
Rakesh kotha
 
Posts: 33
Joined: Sat 30 May 2009, 04:46

Re: slow system response

Postby jkzup » Wed 24 Mar 2010, 19:38

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
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06

Re: slow system response

Postby prino » Thu 25 Mar 2010, 22:54

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...
Robert AH Prins
robert.ah.prins @ the.17+Gb.Google thingy
Some programming here :mrgreen:
prino
 
Posts: 479
Joined: Sat 06 Jun 2009, 21:41
Location: Vilnius, Lithuania


Return to Dezhi systems: Mainframe

Who is online

Users browsing this forum: No registered users and 0 guests

cron