SMF record type 30 reports activity on a job and job step basis. Even though file system activity is included in the EXCP count for the address space, the process section in the record breaks down the EXCP count into the following categories:

This section also provides information about file system lookups, which can use significant resources on systems with hierarchical files.

You can monitor the file system activity of various classes of users by postprocessing SMF type 30 records. This type of monitoring might be helpful in forecasting DASD and other system resource requirements. If key jobs appear to be doing many lookups, your installation might be able to reduce this processing overload. To reduce the overload, reorganize the file system so that key files are closer to the root of the file system.

Applications can reduce lookup activity by using the chdir command to change the working directory and specifying only the file name when opening a file.

SMF records contain a program name field for job steps that are initiated by fork(), spawn(), or exec(). For interactive commands, this feature allows performance analysts to determine what resources were required to complete a particular command.

If a user runs the OMVS command with the SHAREAS option or sets the environment variable _BPX_SHAREAS to YES, two or more processes might be running in the same address space. In this case, SMF provides process identification only for the first process in the address space. However, resource consumption is accumulated for all processes that are running.

With an exec that follows a setuid(), the exec processing no longer creates a substep. Instead, the initiator stops the old job (ending type 30 record). Then a new job is started with the user ID that was established on the setuid().

The CPU time for each syscall is accumulated for the process and saved in field SMF30OST. The number of requested z/OS® UNIX syscalls is reported in field SMF30OSC. Data for SMF30OST and SMF30OSC is only collected when parmlib option SYSCALL_COUNTS is set to YES.

When SYSCALL_COUNTS is set to NO, the CPU time and the count of syscalls is not accumulated. If you always run with SYSCALL_COUNTS=NO, both SMF30OST and SMF30OSC are always reported with a value of zero.

If you switch between SYSCALL_COUNTS=YES and SYSCALL_COUNTS=NO while collecting SMF data for an address space, the SMF 30 record data will not be accurate.