- Enable storage protection — Storage protection is enabled by specifying PROTECT in the SYSTEM statement at system generation. The benefits of using storage protection are as follows:
- CPU overhead is reduced because there are shorter chains for the system to walk.
- Resources are clustered.
To avoid SVC overhead, it is advisable to enable storage protection (that is, specify PROTECT) on the SYSTEM statement and to disable storage protection (that is, specify NOPROTECT) on the PROGRAM statement.
- Specify buffer sizes in multiples of 4084 bytes — The 4084-byte limit represents a multiple of 4K (4096 bytes) less the 12 bytes for pointer information and task ID address, as shown below:
If a 4K page were selected, storage would have to be taken from two contiguous pages. The benefits of placing a 4084-byte limit on the amount of storage acquired are as follows:
- Fragmentation of the storage pool is reduced when only one page is requested. Space is allocated in contiguous frames for a particular request. It is easier for the system to find one page rather than two contiguous pages.
- Less CPU overhead is required because partial pages do not have to be calculated or scanned. When the system finds a request for a multiple of 4K (less the pointer information), it will immediately scan the pool looking for entirely empty pages, thus saving overhead.
- Limit the size of subschemas — Subschemas should be specified to the requirements of the application. The size of the currency block is directly related to the storage requirements of the variable subschema storage block (VB50) used at runtime; the runtime system maintains currency tables for every record, set, and area accessed by the dialog. Therefore, it is worthwhile to make subschemas as streamlined as possible.
- Limit the number of dialog levels — The MAXIMUM LINKS parameter of the ADSO sysgen statement specifies the maximum number of dialog levels that can be established by each respective CA ADS application; keep this parameter low. A well designed application has as few levels as possible. The number of levels should be limited because, for each level established in the application, kept storage is acquired for the Variable Dialog Block (VDB) and the currency block. Storage established at a particular level is not released until control is passed upward.
To limit the number of levels established, use the TRANSFER command whenever possible; build the application horizontally (that is, pass control laterally) rather than vertically.
- Control the size of the application — The size of dialog premap and response processes, the number of data fields included in a map, the size of the subschemas, and the size of database, map, and work records affect the performance of the CA ADS runtime system. The actual number of I/Os required to load a complete program is dependent upon the size of a page in the DDLDCLOD area, the amount of overflow that will be encountered to load that record, and the size of the actual program being loaded. Therefore, the following benefits are realized by minimizing the size of programs:
- A reduction in the work required to load a small program as compared to a large program
- A reduction in time spent loading a particular program in the program pool or reentrant pool
- A reduction in time spent waiting for space in the program pool or reentrant pool
Under DC/UCF, the term program refers to CA ADS dialogs, tables, maps, subschemas, and online and batch programs.
- Make frequently called programs resident — A frequently called program (such as ADSOMAIN) is virtually a resident in the program pool or the reentrant pool. The program should be made resident because the operating system can page more rapidly than IDMS-DC/UCF can read in a page from the DDLDCLOD area. By making the program resident, the operating system, rather than DC/UCF, will be requested to bring the page in core. Additionally, the program and resident pool will be less fragmented when a frequently used program is made resident. A program can be specified as resident on the PROGRAM statement at system generation.
- Free the resources of an inactive terminal — The resource timeout facility can be activated on the SYSTEM statement at system generation, specifying the amount of time a terminal is permitted to be inactive (that is, have no task executing) before all resources owned by the terminal are deleted and control is returned to the system. Because longterm storage resources are associated with a terminal even though a program is not active, freeing those resources will free space for other users of the system. This is particularly important if longterm locks are being implemented.
