VLS source library becomes full

Products

• Ideal

Issue/Introduction

How to increase the size of your VLS file.

Environment

Ideal 

Resolution

 Below are specific actions to take when a library becomes full. You may regard these considerations as a hierarchy of corrective actions to implement.

1. Make sure that the VLS library does not contain extraneous members.
   It has been determined that some sites have run out of room in their VLS source library because there are orphaned members present as a result of the Data dictionary (DD) parameter "ENTY-HIST-VERS". When Data dictionary is installed, the value of this parameter is set to 3 for all DD entities. When a particular entity occurrence exceeds the value of this parameter, the oldest history version is deleted from the Data dictionary. Because this is a DD function and Data dictionary is not tied to the VLS source library used by Ideal, the VLS member is retained in the VLS library. Eventually, this can lead to a full source library that should really not have reached the limit.
   
   In many cases, deleting these orphaned members will free up a lot of space in the VLS library. The utility "IDUTILTY" will generate a report of all VLS members that do not have a corresponding DD entry. This report can be used to delete the orphans either using the Ideal DELETE command online or in batch or VLSUTIL DELETE. (The Ideal DELETE command will delete the entity from VLS even though no corresponding entry is found in Datadictionary.)
   
   NOTE: The IDUTILTY utility is documented in the Ideal Administration Guide.
   
   Sites should also consider deleting history status programs, panels, and reports that are no longer needed. It may also be a viable alternative to save history status entities that may be needed at a later time in external source transport format, so that the entities are still obtainable, but do not have to reside on the VLS library. (Note that history status programs do not have VLS object members. The VLS object is deleted by Ideal when the program goes to history status.)
   
   
2. Create a new set of VLS libraries for a subset of existing systems.
   If the VLS library contains more than one Ideal system, it is suggested that another set of VLS libraries be created. This new set of VLS libraries will be used to move the members associated with one or more of the systems from the original libraries.
   The most efficient way to do this, with the least impact on your programmers, is listed below:
   1. Take a backup of the existing source, panel, and object libraries.
   2. Create a new set of VLS libraries to contain source, panel, and object code.
   3. Decide which system or systems should be moved to the new set of libraries.
   4. Move all members associated with the system into the new libraries and delete these members from the existing library.
      This can be done using VLSUTIL SELREST and/or DELETE cards. See the February 1994 issue of Ideally Speaking, "A Program to Format VLSUTIL Members" for a sample program that automates the process of generating VLSUTIL control statements.
   5. Update the Ideal system definitions to point to the new libraries.
   6. Update the CICS JCL, batch JCL, FCT entries and IDSYSFT to reflect the new libraries.
      
      Using this method will have no impact on the existing programs. The programmers will be totally unaware of the change. Nothing needs to be edited or recompiled.
      
      
3. Separate programs into different systems.
   When a library that contains only 1 system becomes full, and there are no orphan members, and changing the blocksize will not be beneficial, the process becomes much more complicated. There is no alternative but to create new Ideal systems and move some programs to these systems.
   
   It is a good idea to break the programs up into applications. A path report from Datadictionary or the report generated from the DIS INDEX ALL PROGRAM RELATED TO PROGRAM command may help identify programs that belong to one application and common programs that are called by many applications.
   
   Once this division has been made, the new systems and libraries will have to be created and the programs that need to be moved will have to be exported from the existing system and imported into the new system using the source transport utility. Everything will be added in test status. Every program will have to be compiled and, if necessary, marked to prod. You will not be able to maintain the original dates of creation and compilation from the originating system.
   
   You will then want to delete all the moved programs, reports and panels (using Ideal DELETE) from the original system.
   
   
4. Increase the VLS library blocksize.
   Increasing the VLS library blocksize is only an efficient remedy in specific cases. Many sites try to increase the amount of members that can reside on a VLS source library without realizing that every VLS source member will always consist of 2 blocks. This means unless almost every member is more than 3 blocks, increasing the blocksize is only going to buy you a little more time before the library full problem resurfaces. Furthermore, you will be using a lot more DASD and more DSA.
   
   Normally, 1960 is the most efficient size for VLS source libraries, especially when you consider work, parm and report will usually not be extremely large.
   
   NOTE: Remember to modify the FCT entry blocksize associated with the library if the VLS library blocksize is changed. If the blocksizes do not match, errors will be encountered.