You can use two commands to work with objects within libraries: Work with Objects (WRKOBJ) and Work with Objects using PDM (WRKOBJPDM). The latter is available only if you have PDM installed on your system.
Both commands let you select the objects you want to work with. You indicate the name of the library (or libraries), the type of object, and the name of the objects (which can be generic). Here is an example:
WRKOBJ OBJ(*ALLUSR/CR*) OBJTYPE(*DTAARA)
This command shows all data area objects contained in any user library that have names beginning with CR. Once you have the list of objects on the screen, you can select a number of options. The option you pick depends on the kind of action you want to perform. For example, you can select option 4 to delete an object shown on the list.
Deleting a library is a drastic action. Deleting a library not only deletes the library itself, but all the objects contained in it. For this reason, the process of deleting a library can take a considerable amount of time.
To delete a library, you must run the DLTLIB command. This command only requires one parameter: the name of the library you want to delete.
Rather than executing DLTLIB interactively, consider executing it in batch mode. Running DLTLIB in batch gives you better performance and doesn't lock up your display station:
SBMJOB CMD(DLTLIB LIB(MYLIB)) JOB(MYLIB)
If the library contains just a few objects (or is empty altogether), there is no harm in executing the DLTLIB command interactively:
Never, under any circumstances, delete an IBM library (name beginning in Q). If you want to delete a licensed product, use the Delete Licensed Program (DLTLICPGM) instead, or use the LICPGM menu, as shown in Figure 19.1:
Figure 19.1: Working with the licensed programs menu.
Select option 12 to delete licensed programs, as shown in Figure 19.2:
Figure 19.2: Deleting a licensed program.
Now you can enter an option 4 next to each licensed program that you want to delete. Deleting the licensed program will delete the associated library; for example, if you choose to delete RPG/400, the system will delete library QRPG. This process does not require a dedicated system.
QTEMP is not one library, but many. One QTEMP library exists per job on the system. Each time you sign on, the system creates one QTEMP library for your interactive job. When you submit a job to batch, the system creates another QTEMP library for the job you have just submitted. QTEMP'S existence ends when the job ends.
QTEMP is an ephemeral library. You can't create it or delete it using the standard CRTLIB or DLTLIB commands, but you can perform any of the other tasks related to libraries, including clearing it using the CLRLIB command.
Because a separate QTEMP library exists for each job, you cannot look at someone else's QTEMP library. If you run the DSPLIB command to display QTEMP, you will always see your own job's QTEMP. You can't manipulate another job's QTEMP library in any way.
i5/OS does not provide a way for one job to see another job's QTEMP library, but other companies license software products that provide this function.
Always remember that the objects in QTEMP, as well as the library itself, are of a temporary nature. If you sign on and create an object in QTEMP, the object and the library exist until you sign off. When you sign off, both the object and the library are automatically deleted from the system.
QTEMP is the ideal place to put objects that you need on a temporary basis only. Perhaps the best example is work files that need to gather information from several other files to prepare data to print a report. Once the report is printed, the work files are no longer needed.
If you create these work files in any other library, the files remain on the system until you delete them. In this case, you might forget, or the system might not have a chance to delete them if the program aborts due to an error condition.
Rather than risking the job's continued existence (which could affect other jobs coming after it), it is much safer to create temporary objects in QTEMP and let the system delete them when the job ends. The job will end sooner or later, and the objects go with it, even if the job ends abnormally.
Creating work files in QTEMP is especially helpful when more than one user might use the same program at the same time. Because each job has its own QTEMP library, each user has his own set of work files and users do not interfere with one another.
The Submit Job (SBMJOB) command starts a brand new job and places it in a job queue. Because the job created by SBMJOB is completely separate from the original job, it has a different QTEMP library.
Therefore, you can't create objects in your interactive job's QTEMP, submit a job to batch, and expect the batch job to use the objects you placed in QTEMP. It is the wrong QTEMP. The batch job's QTEMP is empty until that job, by itself, creates objects in it.
You must create objects in permanent libraries if you need to share those objects between two or more jobs.