Easy access to library size

[Guest.Visitor]

How do I get easy access to a library size ? I know DSPLIB *print, you get a spoolfile, but it gives to much information, I only want to know the last (total size). Is it possible with the API QLIRLIBD ? What parameters do I need to fill in, when I call the programm ?DSPOBJD only gives the compressed saved size of the object.I tried DSPLIB *all *print. Then CPYSPLF to get it into a database file, but now I can't make a query on TOTAL SIZE. Is there an easy way to get the size of ALL libraries ? John Dikken

[Guest.Visitor]

Easy access to library size

On Tuesday, May 18, 1999, 02:26 AM, johnic wrote: How do I get easy access to a library size ? I know DSPLIB *print, you get a spoolfile, but it gives to much information, I only want to know the last (total size). Is it possible with the API QLIRLIBD ? What parameters do I need to fill in, when I call the programm ? DSPOBJD only gives the compressed saved size of the object. I tried DSPLIB *all *print. Then CPYSPLF to get it into a database file, but now I can't make a query on TOTAL SIZE. Is there an easy way to get the size of ALL libraries ? John Dikken John: A couple of options here - one is DSPOBJD and the other is DISKTASKS. Here's an article I wrote for the Toronto Users Group magazine - "Where Did All the DASD Go?" If you already know what is using up disk space on your AS/400, and are sure that your system has no garbage whatsoever on it, just turn the page and go on to the next article in the newsletter. However, if you wonder what is chewing up the disk space lately, and want to know if there is anything you ought to clean up before spending money (or begging for money) for new drives, keep reading. Create a File Start by creating a file that has information about every object on the system. At first, it may seem unreasonable to create a big file of information, when the point of the exercise is to reduce DASD usage. However, it is likely that you will save a lot more space than you use when monitoring DASD usage. Another advantage of gathering all of your object information in one file is that you will then have the information available for running a series of specific housekeeping reports. How to Create the File Create this file in one of two ways. Use command DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*ALL) OUTFILE(mylib/myfile). Alternatively, use GO DISKTASKS to get to the DISKTASKS menu and then Option 1. Collect Disk Space Information (RTVDSKINF) to collect information. The RTVDSKINF command will output the information to file QAEZDISK in library QUSRSYS. When to Create the File Both of the above commands will run for a long time, so run in batch, preferably off-hours. The first reason for running off-hours is obvious - to avoid annoying all the other system users and developers while you run a long tedious job. The second reason for running in an off-hours time slot is that you can get incomplete information if objects are in use when you try to gather information on them. Authority for Creating the File For either RTVDSKINF or DSPOBJD, ensure that you have provided for sufficient authority to get all of the information you need. The AS/400 will give you information for only those objects to which you are authorized. Commands that adopt authority can be helpful for this purpose. For example, if you use the command DSPOBJD as QPGMR, you will get only object descriptions that QPGMR is authorized to see. So, create a command and command-processing program called, for example, ALLOBJD. Have QSECOFR compile these new objects with USRPRF(*OWNER). When you use the command ALLOBJD, you will get object descriptions for all objects, without the inconvenience of requiring QSECOFR to always submit the command, or the security problem of giving QPGMR permanent authority to all objects. Create Reports Now that you have a file with information on every object, what you do to create reports depends on which way you gathered the information in the first place. If you used the DISKTASKS menu, then you can use Option 2. Print Disk Space Information (PRTDSKINF) on the same menu. The PRTDSKINF command allows you to create custom reports by library, or by folder, or by object. It also allows some selection based on object or library size, to provide only the information that is most likely to be interesting. If you used DSPOBJD to create the file of information (or if you used RTVDSKINF, but want additional reports or a different format than that available in PRTDSKINF) you can use query to summarize by library, or to sort by size, or to select libraries or objects of a certain size and print reports. Summarize in File A small summary file can be handy for future reference. If you create a summary file with one record per library to record the library name and the total storage used by the library, you will have the ability to do a quick comparison next week when you re-run and summarize, and highlight the major changes immediately. Unused Objects Unused objects information can be very helpful. In both files (through DISKTASKS and DSPOBJD) the last change and the last used dates for every object are provided. By comparing those dates to your run date, you can determine if you have any objects that may be obsolete, and therefore wasting disk space. Now What? Now that you know where storage is being used unnecessarily, and where the largest, most useless objects are located, all that’s left to do is to employ a little friendly persuasion, to encourage those responsible to tidy up! ********* I also wrote one on the similarities and differences re DSPOBJD and DISKTASKS and when to consider the use of each. If you'd like to see it, please say so and I'll post it here. Regards, Debbie Gallagher

[Guest.Visitor]

Easy access to library size

The QLIRLIBD API can give you the total library size, and the following CLP is an example of how to use the API. The CLP accepts two parameters. The first is the library name, the second is a packed 15,0 field which will be set to the size of the library.

 PGM PARM(&LIBNAME &LIBSIZE) DCL VAR(&LIBNAME) TYPE(*CHAR) LEN(10) DCL VAR(&LIBSIZE) TYPE(*DEC) LEN(15 0) DCL VAR(&RCVVAR) TYPE(*CHAR) LEN(256) DCL VAR(&RCVVARSIZ) TYPE(*CHAR) LEN(4) + VALUE(X'00000100') DCL VAR(&ATTRIBS) TYPE(*CHAR) LEN(8) + VALUE(X'0000000100000006') /* Define one + attribute of value 6 (library size) */ DCL VAR(&ERRCOD) TYPE(*CHAR) LEN(4) + VALUE(X'00000000') /* Error code = 0 so + exception will be returned */ DCL VAR(&ONE) TYPE(*CHAR) LEN(4) + VALUE(X'00000001') /* Binary 1 */ DCL VAR(&SIZE) TYPE(*DEC) LEN(15 0) DCL VAR(&MULT) TYPE(*DEC) LEN(15 0) CALL PGM(QLIRLIBD) PARM(&RCVVAR &RCVVARSIZ + &LIBNAME &ATTRIBS &ERRCOD) IF COND((%SST(&RCVVAR 1 4) = %SST(&RCVVAR 5 4)) + *AND (%SST(&RCVVAR 9 4) = %SST(&RCVVAR 13 + 4)) *AND (%SST(&RCVVAR 9 4) = &ONE)) + THEN(DO) /* Make sure the requested + information was returned */ CHGVAR &SIZE %BIN(&RCVVAR 29 4) CHGVAR &MULT %BIN(&RCVVAR 33 4) CHGVAR &LIBSIZE (&SIZE * &MULT) IF (%SST(&RCVVAR 37 1) = '0') THEN(DO) SNDPGMMSG + MSG('Incomplete library information') + TOPGMQ(*EXT) ENDDO ENDDO ENDPGM 

[Guest.Visitor]

Easy access to library size

If using DSPOBJD, remember that instead of ODOBSZ, to use the expression ODSIZU*ODBPUN to calculate object sizes; the former can no longer support larger object sizes. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[Guest.Visitor]

Easy access to library size

Thank's for your reaction Bruce, but could you tell me more about the second parameter (LIBSIZE), what should I fill in here ? Where does this variable appear ?

[Guest.Visitor]

Easy access to library size

Thank's Debbie. PRTDSKINF works fine, the command DSPOBJD though doesn't give the real size of the library, but much less (is it the compressed size saved to tape ?). And yes, could you please post the difference between DSPOBJD and DISKTASKS.John

[Guest.Visitor]

Easy access to library size

On Tuesday, May 25, 1999, 05:41 AM, johnic wrote: Thank's Debbie. PRTDSKINF works fine, the command DSPOBJD though doesn't give the real size of the library, but much less (is it the compressed size saved to tape ?). And yes, could you please post the difference between DSPOBJD and DISKTASKS. John *********** John: Chuck Pence added a note that I had not remembered to mention. To get the size of any object using DSPOBJD, you have to multiply ODBPUN by ODSIZU. Then, add up the size of every object in the library to get the size of the library. Not sure I understand your question about DSPOBJD not giving the real size of the library - could you be more specific about what exactly you are looking at and what you find? Next post will be the requested article on DSPOBJD vs DISKTASKS. Regards, Debbie Gallagher

[Guest.Visitor]

Easy access to library size

On Tuesday, May 25, 1999, 05:41 AM, johnic wrote: Thank's Debbie. PRTDSKINF works fine, the command DSPOBJD though doesn't give the real size of the library, but much less (is it the compressed size saved to tape ?). And yes, could you please post the difference between DSPOBJD and DISKTASKS. John ******** John: Here is an article I wrote on DSPOBJD vs DISKTASKS. It was published in the Toronto Users Group Newsmagazine in January 1998. So, since the figures for processing time are out of date, you may want to run your own samples. As far as I know, the rest of the info is still correct - if any one else has more up to date information, please add it. Debbie Gallagher DSPOBJD or DISKTASKS - Which is Better? In the January 1996 issue of the TUG Newsmagazine, I explained two basic methods for creating a report on disk storage used by all objects on your AS/400. If you missed it, check out the TUG web site at www.tug.on.ca. So, since there are two methods, both widely used, which one is better and why? The answer is that it depends on the type of AS/400 shop you are running, what kinds of objects you use, how much your disk usage varies, and how much information you need on your objects. Reports Based on DSPOBJD To create a report based on DSPOBJD, start by creating a file, using the command: DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*ALL) OUTFILE(mylib/myfile). Once the file is created, you need to create a program or a set of queries that will summarize the objects by library and extract the data you need for analyzing what's in the libraries. Reports Based on DISKTASKS To run DISKTASKS, type on a command line: GO DISKTASKS Select Option 1. Collect Disk Space Information (RTVDSKINF). Then, once option 1 has completed, use Option 2. Print Disk Space Information (PRTDSKINF) on the same menu to produce reports of disk storage used. Shared Folders If you use the DSPOBJD method, you will have no information on storage used by shared folders, and will have to create a separate file and report for them. See the March 1996 issue of this Newsmagazine for details. If you used DISKTASKS, the information on shared folder storage is in the same file as the other objects. Storage Reports The DISKTASKS method will create reports for you. The PRTDSKINF command allows you to create custom reports by library, or by folder, or by object. It also allows some selection based on object or library size, to provide only the information that is most likely to be interesting. The RTVDSKINF command creates a file QAEZDISK in library QUSRSYS, so if you need more customized reporting, you can query the file, or write a program to report specific information from the file. If you used DSPOBJD to create a file of storage information, you'll have to write a program or create some queries to summarize the objects by library and to extract other data you want. Information Available Both files have the Last Used Date and Last Change Date for each object. These dates are very useful for determining what may be old and useless on your system. The DISKTASKS file has the object size for each object, including documents in shared folders. It even shows a size for the Licensed Internal Code, which is not reported as an object. With the DSPOBJD method, the object size must be calculated by multiplying fields ODBPUN and ODSIZU. The DSPOBJD outfile has the name of the system for which the information was obtained, while the DISKTASKS file doesn't. If you run reports for multiple systems, you really need to print the system name on your reports. The DSPOBJD outfile also has the user profile of the user who created each object as well as the object owner, but the DISKTASKS file has only the object owner and does not indicate the creator. The creator of an object is very helpful to know if you have to find out what the object is for and if it is needed on your system anymore. Time Needed to Run On a large system with many objects, the DISKTASKS method is considerably slower than the DSPOBJD method. For example, when I started DISKTASKS and DSPOBJD together on a system with 200 gigabytes of DASD and over 100,000 objects, I ran both programs in batch at the same priority on a quiet Sunday morning. The DSPOBJD data collection and reports were done in less than three hours, and then I ran the QRYDOCLIB command and some reports for documents in shared folders, they were done in less than an hour. So, that method was done in about three and a half hours in total. However, the DISKTASKS data collection ran for twenty six hours. On a smaller system, the differences are much less noticeable. If your system is large enough that DISKTASKS will run for a very long time, it will take too long to be helpful if your disk usage varies a lot, especially if it rises quickly. How to Choose The method to use is up to you, and depends entirely on the type of operation you run and what your needs are. If you run a small shop with a single system that doesn't have a lot of variability, you will probably find that DISKTASKS suits you just fine. You can put it on the scheduler and check the reports once or twice a month. However, if you have several large systems, a lot of fluctuations in storage used, and many staff members who may have created objects, you will probably find the few extra steps required to make use of DSPOBJD worth your while. If your shop is something in between, you could try running both methods for a month or so, and see what suits your situation best. ********** Debbie Gallagher

[Guest.Visitor]

Easy access to library size

Re: DSPOBJD's size for the *LIB. The DSPOBJD of *LIB object is just the size of the library; an index to the objects, and each object's information like text and sav/rst information. The DSPOBJD of Libname/*ALL *ALL against which the summation of the previously noted expression of size*units is calculated is the size of the objects in that library. As both the *LIB and each object in the *LIB are objects, each has its own object size. To include the size of the library and the object from DSPOBJD requires two invocations... one against the *LIB, the other against Libname/*ALL OBJTYPE(*ALL). Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[lls_51@yahoo.com]

Easy access to library size

Bruce, I am interested in the code you posted on acccess to library size. I would like to display library name and size for viewing. I know that you can use the SNDPGMMSG command. When I displayed size, it did not correspond library size from the WRKOBJ & 8 option. Is there something I am missing? Thanks Larry L Swain

[GlenKerner]

Easy access to library size

Debbie, I looked into the file you mentioned (QAEZDISK) and I think I would rather use that file than they way I'm totaling disk usage. Currently I use DSPOBJD and then if a file use DSPFD (thus getting the correct size). It seems that this file has everything I need except 1. A definition as to what the types mean (i.e. DIRCR, RCT, etc). Is there someplace that has a definition for these types. Also, the special objects listed (the ones beginning with an '*') is there someplace that defines them. Most are obvious but a few are not. I did find some help text but would like to print it off and would like more detail if possible. Before I forget. If I wanted to restore prior versions of the file (I.E. from back ups to build up history) would it be on a *NONSYS backup?