Optimizing Storage Management

This information is intended to help you understand and optimize storage management in your idcm regions. The following items are covered:
cadts
This information is intended to help you understand and optimize storage management in your
CA Ideal™ for CA Datacom®
regions. The following items are covered:
  • User application storage-how to decide what format, load modules or VLS format, is best for performance.
  • CICS storage use-how
    CA Ideal™ for CA Datacom®
    uses DSA, above-the-line storage, and temporary storage under CICS
  • Releasing session storage-how to effectively free up unneeded storage through coding practices and node error recovery procedures.
This page contains the following topics:
Enhancing User Storage Management
A
CA Ideal™ for CA Datacom®
program or panel produces the same results regardless of its format. This includes load module and VLS object, but performance (runtime, response time, memory required) varies depending on the format that is chosen.
Load Module Format
For optimal performance in a CICS production environment, convert
CA Ideal™ for CA Datacom®
user programs and panels to load module format. Load modules provide performance benefits and a means of monitoring and tuning your environment that VLS format does not.
For more information about load modules, see Module Format for Programs and Panels.
Programs in VLS Format
For CA Ideal programs that run as VLS objects in a CICS environment, each user concurrently running the program has a separate copy of the entire object program. The updateable part is written and accessed in the EDSA, CICS Extended Dynamic Storage Area. At the end of each transaction, the readonly portion of the program is written to CICS temporary storage. When the next transaction for that program is executed, the object program is reloaded from CICS temporary storage.
Panels in VLS Format
Under CICS, the panel buffer is always written to temporary storage at the end of the transaction and reloaded into DSA when the next transaction for that panel is executed. Each panel has one member in load module or VLS format. However, at runtime, when a panel is loaded, two portions of the panel are built:
  • The reentrant portion (non-updateable) that contains the Panel Control Block (PCB).
  • The non-reentrant portion (updateable) that contains the Panel Buffer (PBF). Under CICS, the panel buffer is always written to temporary storage at the end of the transaction and reloaded into DSA when the next transaction for that panel is executed.
Each user concurrently running the panel has a separate copy of the entire panel. The panel is written to CICS temporary storage at the end of each transaction. When the next transaction for that panel is executed, the panel is reloaded from CICS temporary storage
Recommendations
Programs and panels executing in a production runtime environment should be in load module format for optimal performance.
Performance Considerations
This section details the performance considerations.
Application Design
CA Ideal™ for CA Datacom®
will request EDSA whenever possible, but CICS above the line storage is not limitless. Programs that are no longer needed should free the storage they are no longer using. It is important to recognize, however, exactly what is meant by the term no longer needed. An example of a program that is no longer needed is an initialization program. This type of program is called at the beginning of a run and never called again. Another example is the leg of an application.
For instance, if you have a menu program that calls programs that are considered applications and if users spend a long period of time in one application before moving to another piece of the menu, you might consider using RELEASE PROGRAM statements on the programs belonging to the application. This type of application can also lend itself to setting up each leg of the application as its own transaction and using FINAL-ID to invoke the transaction. The invoked transaction can then invoke the menu transaction when it is complete. This frees up all resources because you ended the
CA Ideal™ for CA Datacom®
run.
Do not follow CALL program PDL statements with RELEASE PROGRAM statements as a general rule.
Tuning Storage
Depending on the requirement, you need more XA storage than recommended.
  • Unused storage
    CA Ideal™ for CA Datacom®
    applications should release programs that are no longer used, however, use care to not misuse the function. You do not want to sacrifice performance.
  • Timeouts and Line Drops
    Timeouts and line drops are probably the leading cause of unused
    CA Ideal™ for CA Datacom®
    storage.
    See information about timeouts, line drops, and VPE Node Error Program.
  • VLS object format
    In a production environment, if programs are running in VLS object format instead of load module format, more storage than necessary is being used. This storage most definitely is DSA and extended storage if auxiliary temporary storage is defined to main storage.
  • Unused load modules
    User load modules are loaded in extended storage. If CICS is brought up with PLTLOAD=YES, all modules are loaded and released at startup, regardless of whether they are ever used in the region. This includes all symbol table portions of every program load module, which are only referenced during error processing. Setting PLTLOAD=NO eliminates this additional processing.
If you are using storage efficiently and are still experiencing a storage shortage, you may need to increase the amount of EDSA in the region.
VSE GETVIS Considerations
When you run applications in a VSE environment, having enough space is critical.
CA Ideal™ for CA Datacom®
under VSE is no exception.
Try some of the following suggestions if you encounter space issues:
  • You might want to try decreasing the BUFSPACE parameter on your VSAM files. This degrades performance but it frees up GETVIS. It also requires that you redefine the file (you cannot change it dynamically).
  • If you have several regions accessing
    CA Ideal™ for CA Datacom®
    , you might consider putting heavily used
    CA Ideal™ for CA Datacom®
    modules in the SVA. The module @IAETINT is a good candidate for moving to the SVA. It is frequently used and is approximately 100 KB in size.
    If you allow both on-line and batch compiles, the compiler modules are also a good choice. Moving those modules can save you GETVIS and free up DSA in CICS if the space in SVA is available.
    To determine which
    CA Ideal™ for CA Datacom®
    modules are used for compiles, compile a program using the
    CA Ideal™ for CA Datacom®
    Trace facility:
    @I$TRACE TRACE ON LOCAL COMPILE pgmname @I$TRACE PRINT FUNC VPE STATISTICS
  • In batch, you might consider decreasing the size of your VPE file table (@IIDSYSF).
    One way to do this is to eliminate old and unused ROSFD entries for your VLS libraries. Another thing to look at is your ROSFD entries for sequential files. The blocksize parameter on those entries represents a maximum blocksize. The macro is expanded to include the space needed for that blocksize. For example, if you change the blocksize parameter on the ISLTAPE1 ROSFD entry from 4 KB to 10 KB, the size of @IIDSYSF increases by 6 KB. If you know that the largest blocksize you ever need is 4 KB, you have 6 KB of wasted space.
  • Another thing to look at is your partition size. There are instances where your partition simply is not large enough.
    For batch, make sure that your SIZE= parameter is correct for the type of function you are trying to perform. If you are trying to compile a program and you are getting insufficient GETVIS messages, check if you are producing a cross-reference. If you really do not need one, SET COM XREF=NO. This frees up more GETVIS for the compile.