|
I went to IBM school on some of this eons ago but was able to find my notes & extract some pieces of information that might be helpful. I have NOT yet tried all these ideas, some of which may be a bit controversial. There is also the topic of when it is best to schedule some things that can take a loooong time during which no one else able to use the 400. Useful Commands --------------------------- Some of these mentioned earlier in this thread You do know about wild cards? ... key in part of a command with an asterisk on the end & see list of all commands that start that way ... e.g. DSPF* Also you know that GO CMDxxx will get you a menu of all commands that contain the string xxx for example GO CMDSPLF There are some other key menus & you can get at the big picture via GO MAJOR or GO ASSIST CLROUTQ QEZJOBLOG CPROBJ DSPJOBTBL DSPSYSSTS GO DBMON GO CMDDSK GO CLEANUP GO PROBLEM WRKDSKSTS WRKOUTQ WRKPRB WRKSYSSTS WRKUSRJOB *ALL Key System Values ----------------------------- WRKSYSVAL QPFRADJ QPRBHLDITV QRCLSPLSTG There's lots more, but these are ones that I think might be relevant to this thread Clean Up ------------- GO CLEANUP program is called QEZUSRCLNP if you want to add function Computer Manage Itself ----------------------------------- WRKSYSVAL QPFRADJ then F1 then ask folks here to explain this This value is discussed in Chapter 14 of Work Management Manual Data Access Optimization -------------------------------------- GO DBMON do not start this then go to lunch - it collects a lot of info in a short time, and is itself resource intensive in gathering the info - someone might have done this in the past & led to disk space consumption ... intention is to use Query or SQL to study the data to optimize performance of how we do things. Disk Objects Inventory -------------------------------- Do you have artifacts left over from some implementation or conversion effort that might not be needed anymore? We have source code on all our software, but there are thousands of programs, thousands of DDS, thousands of other things ... the odds are that I might need to access a hundred of these in like the next year, I just do not know which hundred. CPROBJ compresses objects that must be on system for those rare times that someone does need to use them, but in fact are rarely accessed such as source programs ... think of CPROBJ as being like ZIP/400 Disk Status ----------------- WRKDSKSTS each unit should be less than 50% busy - if over 70% we need to use performance tuning to balance our files Performance is enhanced if data "balanced" across different hard disks V4R3 added DSKBAL (via PTF for earlier V's) to do this at IPL time (I betcha that takes a looong time) V4R4 enhanced this. See News/400 Dec 1999 tips. File Size Fluctuation ------------------------------ Files Grow in disk space consumption to accommodate requirements of the data, up to some limits that may need periodic review (DSPFD to *OUTFILE & query compare current capacity with ceiling capacity) but as I get around to cleaning out dead records, those files are still eating the disk space needed when their content was inflated, so there may be a need to check & see if some files have excess capacity, wasting disk space IPLs ------- IBM Hardware & OS/400 improvements mean that doing an IPL becomes less & less useful or neccessary, but there are a few things it does that may be relevant to helping your situation, with respect to helping you clean up stuff. For example, if you have some large system logs, IPL ends them all & restarts them, then you go delete your system logs. There are some work areas whose disk space gets cleaned up. Do you need to IPL? Look at WRKSYSSTS (all kinds of commands) What % addresses used? ... if 70-80% you need IPL What's your % disk space used? ... the higher it gets the more often smart to IPL Job Logs ------------- WRKOUTQ - get list of output queues - scroll & find joblogs You can delete all joblogs in one command 14 - clear an outq You do not want to delete the outq so do not get confused what the options do I have put CLROUTQ QEZJOBLOG on a menu for purpose of doing this after backup & after a WRKOUTQ review to see if I need to keep any ... typically I kill several hundred a day after moving 1-2 a week to another Q for study. WRKF QHST* How many do you have? We have 4 days worth Message Queues -------------------------- When full they get extended (more disk space) When empty they as big as they ever get to make them smaller you can delete & recreate Performance Monitoring ---------------------------------- Are there objects y"all finished with? LIB QPFRDATA Reclaim Storage ------------------------ If you run RCLSTG reclaim storage, afterwards DSP QRCL & QReclaim directory to check out the stuff that Reclaim did not know what to do with Reports clogging Spool ---------------------------------- WRKUSRJOB *ALL & F4 ... try different mixes ... see which users most prone to leave reports open. When locating & clearing ancient reports, I favor the end users doing this, but sometimes they say "Al it is Ok for you to kill ......" certain categories of stuff, like say file maintenance audit trails that are over a week old. I most comfortable with WRKSPLF _______ (name of user) which gets at everything for that one person where I can put 4-delete in front of many lines at one time If you want to have a CL to do some repetitive kills of ancient reports, check out CHGSPLFA Change Spool File Attributes *SELECT lets us select all reports that match criteria such as USER (name, *CURRENT or *ALL) PRINTER (specific OUTQ, *ALL) FORM TYPE (specific or *ALL) User Data field (specific or *ALL) so for example, with one command string we can move 100% of one person's reports from one OUTQ to another or change # copies or save after printing & etc. Check the archives for info about shareware to do stuff like killing all spool file entries that are over some date age for a selected list of users with some other exceptions You know when you do display job information on people prior sessions that created unprinted reports? There is a certain amount of 400 baggage to keep track of all that. It is not just number pages. If people really need to keep reports on spool, you might want to explore ways to get that report data into some other form that gets saved without tying up 400 jobs. DSPJOBTBL shows how much space has been allocated for keeping track of multiple jobs on the system & how much of that has been consumed so far. >From a performance standpoint it is better to not be slowing people down by the system creating new jobs a lot, as opposed to reusing them, but you also might not want this sort of thing accumulating indefinitely. This is a big subject to understand ... currently I have our values set at what I think is reasonable, with IPL clearing out some accumulation. If you have had large #s of deleted spool files, reclaim space via system value QRCLSPLSTG or perhaps after heavy printing activity such as end-month do RCLSPLSTG Security Auditing ------------------------- Are you doing this? System Problems -------------------------- GO PROBLEM & WRKPRB default shows current list 99% of OUR problems shown here are idiot events outside IBM relevance such as PC goes down & IBM thinks there may be a hardware problem, or ma bell goes goes down in weather front & IBM thinks there may be a hardware problem, so all these incidents get opened that we know are not in IBM hardware & I want to delete them but they are more days than system value QPRBHLDITV allows so I need to lower this value to get rid of the garbage then raise it again in case we ever do have a hardware problem that is IBM Threads Other -------------------- See recent midrange-L thread on "deleting logical files" I may be approaching diminishing returns on my own effort to clean up our disk space, once I complete the stuff I know needs to be done. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
