Degradation
From MidrangeWiki
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?
- BPCS Files can have millions of records, going back a year or more, while 90% of the users really only need the last few weeks worth when they access inquiry into those files. There are enhancements available to archive the older stuff into another library, so it is not part of the standard inquiry, but is available for reports when needed.
- DSPMSG QCFGMSGQ = If you create this message queue, IBM will send to it messages about hardware problems. If some work station has gone flakey, it can connect, disconnect, connect, have a string of unwanted garbage.
- DSPMSG QSYSMSG = If you create this message queue, IBM will send to it some messages about very bad stuff, like perhaps the cache battery on your disk drive is going flakey and needs to be replaced.
- DSPMSG QSYSOPR = is there some problem right now awaiting a response? Do you know what a runaway job is?
- 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.
- WRKPRB = Get at list of recent events that IBM categorizes as hardware problems