Shared segment

GDDM V3R2 System Customization and Administration

Shared segment

GDDM V3R2 System Customization and Administration
SC33-0871-02

The largest potential performance improvement in a VM environment is obtained by putting GDDM into a saved segment. It has been observed that response times for the initial GDDM display in an application can be reduced by several seconds when a saved segment is used. This is discussed earlier in this topic.

There are several reasons why GDDM code in a saved segment might not be used, even if you intend it to be:

The name of the segment may be wrong. The names suggested as test names in the GDDM 3.2 ADMDCSS CONFIG file are:
GDDM-Base
ADMBA320
GDDM-PGF
ADMPG213
GDDM-IVU
ADMIV113
GDDM-GKS
ADMGK113
GDDM-IMD
ADMIM213
The test names can be changed.
The default names are:
GDDM-Base
ADMXSS00
GDDM-PGF
ADMPG000
GDDM-IVU
ADMIV000
GDDM-GKS
ADMGK000
GDDM-IMD
ADMIM000
GDDM-REXX
ERXRX000
The starting address of the segment may overlap with addresses in the user's virtual machine. This could well occur if virtual machine storage size gets increased for any reason.
Explicitly including the GDDM packaging stub ADMUX00V when loading the application overrides the use of most of the GDDM code in the saved segment.
This applies to 43xx Processors only.
When a saved segment is protected (the default) the VM Command Processor (CP) must scan through all pages of the segment each time a virtual machine using it stops being dispatched. This is done to check if the change bit is on in a page. You can avoid this by coding PROTECT=OFF on the NAMESYS.
You should use this technique only if your applications have all been thoroughly tested. If not, you may find that the shared segment gets corrupted by someone inadvertently storing data into shared virtual storage.

On 308x and 3090 machines, CP uses the segment-protect hardware rather than the scanning approach.

Notices | Terms of use | Support | Contact z/OS