Difference between revisions of "Degradation"

From MidrangeWiki
Jump to: navigation, search
m
Line 13: Line 13:
 
**** If it happens same time each day, and that time coincides with shift change, or lunch break, suggest to some co-workers that if they sign on or off a few minutes before or after shift change, it might go faster.
 
**** If it happens same time each day, and that time coincides with shift change, or lunch break, suggest to some co-workers that if they sign on or off a few minutes before or after shift change, it might go faster.
 
**** If it happens same time each day, and that time is like the middle of people's work day, then use DSPLOG to see what kind of tasks typically run at that hour.   
 
**** If it happens same time each day, and that time is like the middle of people's work day, then use DSPLOG to see what kind of tasks typically run at that hour.   
 +
**** If you identify a particular program that seems like it might be the culprit, take a look at the files it accesses how.  Perhaps there is a poorly designed join of some humongous files.
 
*** Analyse interactive tasks to see if any can be moved to JOBQ (my second choice)
 
*** Analyse interactive tasks to see if any can be moved to JOBQ (my second choice)
 +
**** Teach co-workers how to send [[Query]] to JOBQ.
 
*** Do something that can get you in big trouble with IBM
 
*** Do something that can get you in big trouble with IBM
 
*** Downsize the company
 
*** Downsize the company
 
*** Update your resume
 
*** Update your resume
 
* [[WHO BAD]] = [[CLP/400]] program to display what jobs are using 3 % of system resources or more.  You can customize where you do your cut-off.
 
* [[WHO BAD]] = [[CLP/400]] program to display what jobs are using 3 % of system resources or more.  You can customize where you do your cut-off.

Revision as of 03:46, 29 May 2005


We get so we are accustomed to some level of performance with our 400, then unexpectedly it is like someone has put on the brakes. Whoah, how come it is so sluggish right now? Here are links to tips and techniques what you can do when this happens, to figure out what is going on, and fix it.

These tips can also help when you experience what might be called a slide into oblivion, in which the 400 seems to slowly but steadily appear to be running more slowly. What the heck is going on, and how do we fix it?

  • SYSCMDUSNO = one of the CLP/400 examples. This CLP/400 program lists bad stuff that's recently been going on, such as:
    • CPF4058 = Here's a file with significant growth, better do something before it explodes.
    • CPI1479 = Your 400 has become over-taxed with interactive activity. Your choices include:
      • Grin and Bear it
      • Bare your company wallet to IBM
      • Check TIMES this is happening (my first choice)
        • If it happens same time each day, and that time coincides with shift change, or lunch break, suggest to some co-workers that if they sign on or off a few minutes before or after shift change, it might go faster.
        • If it happens same time each day, and that time is like the middle of people's work day, then use DSPLOG to see what kind of tasks typically run at that hour.
        • If you identify a particular program that seems like it might be the culprit, take a look at the files it accesses how. Perhaps there is a poorly designed join of some humongous files.
      • Analyse interactive tasks to see if any can be moved to JOBQ (my second choice)
        • Teach co-workers how to send Query to JOBQ.
      • Do something that can get you in big trouble with IBM
      • Downsize the company
      • Update your resume
  • WHO BAD = CLP/400 program to display what jobs are using 3 % of system resources or more. You can customize where you do your cut-off.