The SYSEAM file is used to store temporary data (access method EAM). SYSEAM can be created on any pubset.
Users access the SYSEAM file which resides on their user default pubset. If there is no SYSEAM file available on the user default pubset, the SYSEAM file of the home pubset is accessed.
The ideal size of SYSEAM can only be determined after observing the mean utilization over a sufficiently long period. For information on the initial setting, see section "EAMMEM, EAMMIN, EAMSEC, EAMSIZ".
Observation is carried out with the software product SPCCNTRL (Space Control). Heavy demands are placed on the SYSEAM file, especially in the case of interactive program development in interactive mode: frequent compilation runs have a considerable effect on both size and access frequency.
For monitoring access frequency, use of SM2 is recommended (file monitoring).
Location of SYSEAM
To avoid SYSEAM becoming a bottleneck when there is a large number of users in conjunction with powerful CPUs, it makes sense to distribute it across several pubsets.
If possible, no SYSEAM extents should be stored on volumes with paging areas.
Since all I/O requirements are subject to caching (write hit = 100%) in storage systems, it is not necessary to distribute the SYSEAM file across several volumes in a pubset.
Any increase in the size of the SYSEAM file workload is generally reflected by a corresponding increase in the size of the file. If this is the case, it is recommended that the volumes required are reserved exclusively for SYSEAM and that, with regard to the I/O rate, the upper workload limit of 30% is approached. In this case, a volume manages around 300 I/O operations per second.
SYSEAM peak loads
The main users of SYSEAM are the compilers, the software product LMS and the linkage editors (binders) BINDER and DBL.
Systems support should know the times when these program services are called. Then decisions can be made whether additional pubsets need to be created and when they should be imported.
If a high proportion of the workload consists of program services, the TSOS macro libraries, the user macro libraries and the MODLIB files should not be placed on volumes which also contain SYSEAM extents.
If sufficient main memory is available, it makes sense to place part of the SYSEAM area in class 4 memory (this applies only for the home pubset) using the system parameter EAMMEM (see section "EAMMEM, EAMMIN, EAMSEC, EAMSIZ"), thus saving on SYSEAM I/O operations. This permits compilation and binder runs to be accelerated correspondingly.
Measures which can be taken after SYSEAM secondary allocation:
When the console message is issued in a session:
DMS0852 (&00): (&01) PAM PAGES AND (&02) EXTENTS
(where &00 is the name of the SYSEAM file), the file size exceeds the value of EAMMIN or the pubset-specific entry for MINIMAL-SIZE in the MRSCAT.
This message, which is issued whenever the file is extended or shortened, should appear only during peak workloads. If it is issued frequently, it means that the value selected for the system parameter EAMMIN or for MINIMAL-SIZE in the MRSCAT entry is too small. In order to avoid secondary allocations, the size of EAMMIN must be adjusted and the file extended accordingly. After system initialization, the files can be erased and then newly created again. During this time, no users may access the SYSEAM files. A renewed startup is not necessary afterwards.
The SYSEAM files are reset to the size of the system parameter EAMMIN via a system cold start.