Addressing OS/390 Web server performance. - IBM

IBM Global Services
Addressing OS/390
Web server performance.
Key Topics
Explains the importance of defining
meaningful performance reports
Helps you define your performance
objectives
Provides a standard approach to
performance management
Addresses changes to OS/390
in a Web environment
Uses a successful methodology
to analyze Web server performance
problems
Discusses the benefits of performance
analysis
Introduction
The benefits of high-availability and proven disaster-recovery capabilities make
OS/390 ® an attractive Web server choice. However, there are challenges in using an
OS/390 system as a Web server. There are additional complexities associated with providing
and maintaining acceptable performance levels for new functions, existing legacy
applications and batch processes. The Internet introduces exposure to unpredictable
workloads that may interfere with the performance of current production applications.
This paper describes a performance analysis process developed by IBM Performance
Management and Capacity Planning Services to analyze an OS/390 Web
server environment. Many analysts are overwhelmed by performance analysis due
to the complexity of, and difficulty in, using the available tools. However, without these
tools, there is no successful way to measure performance levels. Using a proven process
helps solve multiple information systems issues and can serve as input to the
information systems decision-making process. The process can provide valuable
information for capacity planning, systems planning and workload balancing, as well as
system tuning efforts. An evaluation of the impact of new hardware or software applications
provides more accurate cost projections, improving project feasibility assessments.
While the objectives of performance management may vary, most final reports
include the analysis of one or more of the following:
• Processor utilization by workload type
• Processor storage allocation by workload type
• I/O activity by workload type
• I/O subsystem response time analysis
• Information reflecting levels of resource contention.
The primary goal of a systems analysis is to identify latent demand, bottlenecks and
levels of resource contention.

2
Delivering meaningful performance reports
The first step in designing a performance management report is to understand the audience.
The performance report should contain only information required to answer the
business, capacity or performance questions. Often, excellent reports are never read
because the audience does not understand the content. To ensure that the audience
understands the issues, use appropriate terminology when describing the meaning of
charts and graphs. For example, capacity planners may view information from a more
technical perspective, whereas business planners might focus more on return on investment.
Multiple report types can be created from the same data to match the
understanding and focus of the audience members.
Often, performance management is initiated when problems are reported. We take a different
approach to performance management. Our methodology produces a report based
on system contention indicators that affect throughput and response times. Each resource
component of the system is displayed, showing the levels of capacity attained and contention
activity. There are no defined good or bad levels. Whether the capacity or contention is
excessive can only be determined by the impact on meeting business objectives.
The purpose of a performance management report should be to provide information
that will help analysts manage the information systems resources. An objective of this
methodology is to identify indicators that provide insight into how well a system is
running. An analysis of these indicators provides information on changes and available
options to improve performance or service.
Determining your objectives for OS/390 Web server performance
Experienced system managers recognize the following areas as essential for success:
• Resource monitoring—Resource utilization must be monitored so performance problems
can be easily detected either before they occur or immediately thereafter.
• Analysis and control—Once a performance problem is detected, the system manager
must select and use the appropriate tools to understand the nature of the problem and
take action.
• Capacity planning—Long-term capacity requirements must be analyzed so that sufficient
resources can be acquired on a just-in-time (JIT) basis for maximum cost and
utilization efficiencies.

As you begin to form your performance management strategy, determine your major
objective. Below are some common goals:
• Instantaneous response time for users
• Optimized performance without the purchase of additional hardware
• Batch jobs completed by specific times or within a specific time window.
Since performance management is an ongoing process, the initial goal should be as
simple, singular and measurable as possible. For example, making the system run
faster is too undefined. Making a batch job run in five minutes, or decreasing response
time from two seconds to less than one second are more appropriate goals. Performance
goals, especially if they are formulated by a group, may be in conflict or be
unreasonable. Following a tuning methodology helps to determine whether your goals
are attainable with available resources. In fact, the performance tuning process may
uncover a need for additional resources, or may point to something not immediately
tunable, such as software.
The monitoring method must fit the server’s place in your organization’s overall IT strategy.
For example:
• A noncritical server may only need occasional monitoring, using those tools that came
with the operating system or those available in the public domain.
• Servers critical to your enterprise that support key business functions may require
constant monitoring with a suite of sophisticated tools that generate realtime
statistical data.
Examples of factors that impact your monitoring method decision are:
• How quickly does performance degradation need to be addressed?
• Who on your staff is experienced and available?
• What is your budget?
3

4
Implementing a standard approach to performance management
The following flowchart provides a generic approach to performance analysis and tuning
for OS/390, UNIX ® and Windows NT ® systems. The goal is to create a proactive process
where problems are identified before users start complaining.
The first function is to define business objectives and identify a way to measure those
objectives. If the objectives are not being met, actions are initiated to isolate and fix the
problem. Once the cause of the problem has been identified, decide whether it is a
tuning issue or the result of a lack of resources. If it is the result of a lack of resources,
decide whether to buy more or rebalance resources from an existing application.
Rebalancing system resources from one application and giving them to another is not
the same as tuning. After making any changes, always verify that the problem was
corrected. The process begins again with the next scheduled measurement.
Set
Workload
Objectives
Check
Objectives
OK?
NO
Identify
Resource
Causing
Problem
YES
Wait
Buy
Rebalance
Tune
Verify the
Solution

Understanding the changes to the OS/390 system as a Web server
To address the business and performance issues of decentralized horizontal growth
of Web environments, many businesses are porting their Web applications to OS/390
server platforms. This migration resulted in numerous OS/390 software and hardware
changes to accommodate the new protocols and OS/390 Web transaction application
requirements. When working in this environment, consider that:
• Exploiting the robust characteristics of the OS/390 software and hardware has
changed the complexity of managing system performance.
• Adding Web applications to the OS/390 legacy environments has increased the
difficulty of managing performance objectives.
• New skills are required to understand the relationship of Web activity and system resource
use.
• Not managing Web activity has a negative performance impact on legacy applications.
• Legacy applications must coexist with Web server applications.
• Managing the Web workloads requires changes to the workload manager service
policy or, for compatibility systems, the IEAIPSxx.
• There are new metrics, new bottlenecks and new performance requirements.
• The type of performance data and the tools used to process this data need to
be enhanced.
• If the OS/390 system is currently experiencing performance problems, the Web server
application will not perform well. CPU cycles, processor storage and I/O
capacity must be available before you install any new applications. There must be sufficient
system resources to support UNIX, TCP/IP and Web server requirements.
• System parameter tables need to be modified to properly reflect the new environment.
• OS/390 Version 2 Release 7 with SMS 1.5 HFS enhancement is the recommended
base level.
5

6
Even experienced performance analysts see new challenges for OS/390. These challenges
require changing existing processes to support a Web environment and include:
• The need for reliability, availability and manageability increases as more and more businesses
consolidate their decentralized, hard-to-manage Web server environments and
as critical applications are converted for Web access.
• Current performance tools and methodologies must be altered to include new types of
data analysis.
• Unlike legacy applications, new transactions arrive via a Web site server client, not VTAM
or NCP. TCP/IP is the main vehicle used for moving transactions between the application
and the client and plays an important performance role.
• New protocol information is used to identify data set characteristics, and a new HFS file
structure is used to support the data. OS/390 functions have been changed to recognize
this and must be considered when evaluating system performance.
• As a transaction passes through the system, multiple levels of interpretation occur.
However, when it reaches the online application, it looks like a standard transaction.
This indicates that performance methodologies for online applications will not have to
be changed.
• OS/390 UNIX system services are used to manage the reading and writing of user and
application data. UNIX system services are also used to support OS/390 Web server
functional requirements.

Updating the methodology to identify Web server resource and performance
problems
Beginning with OS/390 R2.7 and in conjunction with the IBM WebSphere strategy, the
IBM WebSphere application server pack is now part of OS/390. This was implemented
to support the innovative growth of OS/390 Web server applications. Because
legacy applications now coexist with Web applications, the type and the amount of performance
data is increasing. Methodologies for performance tuning are changing and
must include new processes.
To determine the new performance requirements for an OS/390 Web server environment,
we have examined the path length of a Web transaction through the OS/390 system
before reaching the application. When the transaction reaches the application, this methodology
is concluded. Using existing knowledge, and applying the new requirements for
Web server performance, we have created a successful methodology to analyze the
effectiveness of the installed Web server and OS/390 system. The objectives of the
methodology are to identify areas where resource contention exists and define what
additional system resources are required to improve performance bottlenecks.
The original RMF/SMF data must be analyzed to determine the contention levels of
system resources. Additional data and analysis skills must be included to support the
performance of the OS/390 Web server. The Web server uses critical underlying components
of OS/390 that must be tuned correctly for optimal throughput. To provide an
end-to-end review of Web server performance, we have included OS/390 UNIX System
services and TCP/IP data in the performance analysis process.
To validate the performance of online applications such as CICS ® , DB2 ® and IMS/ESA ® ,
capture application performance data. The methodology used to analyze this data
does not require any major changes.
7

8
Managing an OS/390 Web server environment
Understanding what is different in managing an OS/390 Web server environment is the
first challenge. Examining current reports created for OS/390 systems will not provide
sufficient information to determine whether there are performance problems. Instead,
create new performance reports that provide information incorporating utilization and
contention for the Web server environment. Skills need to be updated to understand the
new protocols, UNIX services, TCP/IP and Web server resource utilization.
The business importance of the Web workloads should be balanced with their impact on
existing applications. This is a critical requirement because system parameters will be set
based on these decisions.
To properly analyze and tune an OS/390 system serving as a Web server and hosting
legacy applications, identify the type and amount of data required and the gathering
requirements. When determining the proper OS/390 resource settings for UNIX, TCP/IP
and the Web server, do not compare the values from other environments, such as NT
servers. The level of resources to support these applications will not be the same in an
OS/390 environment.
The performance data collection process
Before choosing the types of data to collect, become familiar with the processes and
functions a Web transaction uses and system implications of implementing a Web server
environment. Awareness of new parmlib members, data logs and SMF records is critical
before you can design a performance methodology. Many of the performance tools
available seem to relate only to the specific function they are measuring and do not offer a
viewpoint of how well the total system is performing. Our methodology provides a system
level performance assessment by taking advantage of new data, tools and processes.
System measurement data is extracted from RMF type 70 through RMF type 77 records,
SMF type 30 subtypes 2 and 3 records, and cache analysis data, SMF type 74 subtype 5.
Data related to granularity and quality of performance is very important. Too much data
will slow the process and increase the complexity and cost without providing additional
benefit. Historical performance data is valid for about seven days before it loses its value.
Intervals for performance analysis are reported on an hourly basis. Seven days of performance
data is sufficient to ensure consistency and repeatability.
Two additional record types are used to analyze Web server performance: SMF type 92
UNIX HFS file system activity and SMF type 103 Web server configuration and performance
statistics. Changes to the SMF parmlib member must be made to include these
record types and additional application steps must be taken to initiate the creation of the
new 92 and 103 records. To collect information about HFS files, you must collect SMF type
92 records prior to the HFS mounts.

The IBM HTTP server has a number of functions that exploit OS/390 facilities, such as
the workload manager and the operator interface. You can request the HTTP server
to write this information data to SMF. Exploitation of SMF allows the Web server to be
managed in the same way as other OS/390 applications. If SMF is set up correctly
and the server has SMF logging enabled, performance information will be collected
periodically according to the SMF interval and saved as SMF record 103, subtype 2.
SMF Web server data (SMF type 103) and SMF application data (SMF type 30) can
be processed together to help determine if resource contention or bottlenecks are
occurring in your Web server applications. Based on the analysis of the data, you can
verify that proper values, options and setup parameters have been specified in the
parmlib members. You can identify the resources used and determine whether additional
resources are required.
Workload classification
Summarizing the data and facilitating a top-down approach requires two types of
data groupings: shift definitions and workload mappings. These are defined for each
unique system image.
• Shift definitions:
Each hour of the day is assigned a shift definition, based on the business characteristics
of a 24-hour cycle. Analysis may then be focused on resource utilization for an
hour, a shift or an entire day.
• Workload mappings:
Compatibility mode—Each performance group specified in the IEAIPSxx member of
SYS1.PARMLIB is assigned to a workload type definition. Normally, the number of
workload types is limited to less than ten, making it easy to view them on a graph. System
resource utilization is reviewed at the workload level. For selected workload
types, additional charts can be produced at the performance group level, offering
more granularity.
Goal mode—Each service class specified in the workload manager service policy is
assigned to its corresponding workload type as specified in the service policy.
To provide additional information about the data used to produce the charts and
graphs, a tabular summary table of the SMF/RMF data is included at the end of the
report. The technical analyst can use it as a checks-and-balances list.
9

10
OS/390 WebSphere performance analysis
An OS/390 WebSphere performance analysis will include a review of the SYS1.PARMLIB
member BPXPRMxx.
The RMF post processor provides a UNIX (OMVS) activity report. This report provides
information needed to tune parameters in the BPXPRMxx member of SYS1.PARMLIB.
The RMF OMVS activity report provides information on:
• System-wide use of callable services
• The number of callable services called
• The central processor time for callable services.
• Statistics that aid in the tuning of the following process activity parameters
• MAXPROCSYS—Maximum number of concurrent active processes on the system
• MAXPROCUSER—Maximum number of concurrent active processes
associated with any single user
• MAXUIDS—Maximum number of concurrent active users on the system
• MAXMAPAREA—Maximum number of pages that can be used for
memory mapping
• MAXSHREPAGES—Maximum number of pages of shared storage
concurrently in use as created by fork(), ptrace(), mmap() and shmat()
• IPCMSGNIDS—Maximum number of unique message queues on the system
• IPCSHMNIDS—Maximum number of unique shared memory segments on
the system
• IPCSHMSPAGES—Maximum number of pages for shared memory segments
on the system
• IPCSEMNIDS—Maximum number of unique semaphore sets on the system.

Example
In the table below, MAXPROCSYS is experiencing overruns. If there are system resources
available to support additional forked or spawned address spaces, you would increase the
MAXPROCSYS value (100) to a higher number. This would eliminate the overruns.
OMVS RMF KERNAL ACTIVITY REPORT
OMVS SYSTEM CALL ACTIVITY OS/390 SYSTEM ID DSP1 DATE 03/02/1999 PAGE 1
————————————————————————————————————————————————————————————————————————————————————————————————————————
MINIMUM AVERAGE MAXIMUM
————————————————————————————————————————————————————————————————————————————————————————————————————————
SYSCALLS (N/S) 102.0 261.9 1129
CPU TIME (H/S) 0.000 0.314 1.000
OMVS PROCESS ACTIVITY
————————————————————————————————————————————————————————————————————————————————————————————————————————
PROCESSES(MAXPROCSYS) USERS(MAXUIDS) PROCESSES PER USERS(MAXPROCUSER)
MAXIMUM (TOT) 100 600 50
————————————————————————————————————————————————————————————————————————————————————————————————————————
MINIMUM AVERAGE MAXIMUM MINIMUM AVERAGE MAXIMUM MINIMUM AVERAGE MAXIMUM
————————————————————————————————————————————————————————————————————————————————————————————————————————
CURRENT (TOT) 46 46.03 47 3 3.000 3
OVERRUNS (N/S) 0.000 10.40 21.30 0.000 0.000 0.000 0.000 0.000 0.000
OMVS INTER-PROCESS COMMUNICATION
————————————————————————————————————————————————————————————————————————————————————————————————————————
MSG QUE IDS(IPCMSGNIDS) SEMAPHORE IDS(IPCSEMNIDS) SHR MEM IDS(IPCSHMNIDS) SHR MEM PGS(IPCSHMPAGES)
MAXIMUM (TOT) 500 20000 500 2621K
————————————————————————————————————————————————————————————————————————————————————————————————————————
MIN AVG MAX MIN AVG MAX MIN AVG MAX MIN AVG MAX
CURRENT (TOT) 0.000 0.000 0.000 13.00 12.99 13.00 154.0 153.8 154.0 40238 40186 40238
OVERRUNS (N/S) 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
————————————————————————————————————————————————————————————————————————————————————————————————————————
MEM MAP STOR PAGES(MAXMMAPAREA) SHARED STORAGE PAGES(MAXSHAREPAGES)
MAXIMUM (TOT) 4096 32.8M
———————————————————————————————————————————————————————————————————————————————————————
MINIMUM AVERAGE MAXIMUM MINIMUM AVERAGE MAXIMUM
———————————————————————————————————————————————————————————————————————————————————————
CURRENT (TOT) 1295 1294 1295 684K 683K 684K
OVERRUNS (N/S) 0.000 0.000 0.000 0.000 0.000 0.000
OS/390 compatibility mode systems
OS/390 compatibility mode systems require a review of the IEAICSxx, IEAIPSxx,
IEAOPTxx parmlib members. Web servers can create many address spaces. Check the
IEAIPSxx parmlib member to ensure that proper values are set to handle this increase
(domain CNSTR values).
IEAICSxx and IEAIPSxx should be modified to ensure that workloads acting as servers
carry a higher dispatching priority than other workloads. The dispatching value should be
in line with your business requirements. If processor storage contention exists, you may
use storage isolation for the server address spaces. Review the IEAOPTxx parmlib member
to ensure that all values are set correctly for the new Web workloads.
11

12
OS/390 goal mode systems
OS/390 goal mode systems require a review of the service policy classification rules. Check
your service policy to ensure that proper service classes and objectives are specified to
manage the increase in the number of address spaces. Based on established business
requirements, workloads that act as servers should be at a higher dispatching priority and
importance than other applications.
TCP/IP provides the transport for all HTTP requests, so validating the parameters for TCP/IP
will ensure the settings support transaction activity. Several settings may require adjustment:
• Make the TCP/IP MVS dispatching priority and VTAM the same setting. Other TCP/IP
services can be set lower.
• For goal mode, TCP/IP should:
• Be in unique workload and service classes
• Have high importance and velocity
• Run SYSBMAS and BPXOINIT in SYSSTC.
• Set TCP/IP region size to REGION=0M. This allows TCP/IP to allocate the maximum virtual
storage above and below the 16MB line. Check IEFUSI exit for restrictions to specifying the
REGION parameter.
• Print a copy of the PROFILE and DATA members for the TCP/IP proc(s).
• Make buffer pools large enough to support traffic volumes. Use the TCP/IP shutdown statistics
to estimate and tune the number and size of buffers. Buffer pool parameters are
documented in the TCP/IP User Guide.
• Check the IBM TCP/IP Performance Tuning Guide—SC31-7188 and the MVS TCP/IP
User’s Guide—SC31-7136 for additional tuning tips.

Pinging
Ping is a simple test that can be done to check communication connections and response
times. It sends an echo to an IP host to determine if the host is accessible.
Example
ping newsite (length 80 count 4)
Results:
Ping CS V2R6: Pinging host NEWSITE (9.38.253.16). Use ATTN to interrupt
PING: Ping #1 response took 0.055 seconds. Successes so far 1.
PING: Ping #2 response took 0.055 seconds. Successes so far 2.
PING: Ping #3 response took 0.053 seconds. Successes so far 3.
PING: Ping #4 response took 0.066 seconds. Successes so far 4.
Trace route
Tracerte is similar to ping, except it reports the round trip time by intermediate host sites.
Example
Trace route to NEWSITE (9.38.253.16)
Results:
1 (9.82.1.103) 8 ms 5 ms 8 ms
2 (9.82.96.1) 8 ms 7 ms 9 ms
3 (9.32.74.141) 14 ms 14 ms 12 ms
4 (9.32.1.21) 24 ms 46 ms 22 ms
5 (9.32.184.102) 50 ms 78 ms 58 ms
6 (9.38.253.16) 58 ms 76 ms 72 ms
The OS/390 eNetwork Communication Server: IP User’s Guide and IP Configuration
Guide—SC31-8513 contains detailed information on other commands and how to interpret
their results.
13

14
Web server I/O performance
An analysis of the HFS file system performance using SMF type 92 and SMF type 30
records ensures that the application file system is configured properly and performing
as well as possible with the available system resources.
SMF Type 30 Data:
Key SMF type 30 subtype 2 & 3 record fields:
Common address space work activity section:
SMF30JBN—Job Name
SMF30EXN—Program name of UNIX service process
SMF30CPT—CPU time
SMF30CPS—SRB time
SMF30WST—Storage frames
SMF30PGI—Page-in activity
SMF30NSW—Swap activity
SMF30TEP—Total blocks transferred
UNIX application/job resource usage section:
SMF30OPI—UNIX process ID
SMF30OFR—HFS reads to regular files
SMF30OFW—HFS writes to regular files
SMF30ODR—HFS directory reads
SMF30OSC—Total service request

Using SMF type 30 records, you can create a table that displays by program name, system
resource and file activity. The SMF process ID (SMF30OPI) field can be used with
SMF type 92 records to identify HFS dataset names.
Sample Table:
DAY HOUR SCLASS JBN PROGRAM | PROCESS CPU CPU REQUEST
SMF30JBN *SMF30EXN | SMF30OPI %USED SECONDS SMF30OSC
**************************************|***********************************
19 9.75 WEBSRV HTTP11 server... | 16777244 1.0 9 6551
19 10.00 WEBSRV HTTP11 server... | 16777244 0.9 8 4909
19 10.25 WEBSRV HTTP11 server... | 16777244 0.9 8 6718
19 10.50 WEBSRV HTTP11 server... | 16777244 0.7 7 4747
19 10.75 WEBSRV HTTP11 server... | 16777244 0.8 8 6348
19 11.00 WEBSRV HTTP11 server... | 16777244 0.9 8 5410
19 11.25 WEBSRV HTTP11 server... | 16777244 0.6 6 4492
SMF type 92 records:
Open MVS File System Activity data describes the files defined in the BPXYMNTE macro
of the BPXPRMxx member of SYS1.PARMLIB.
The SMF92 record has multiple subtypes:
Subtype 1—Written when a file system is mounted**
Subtype 2—Written after the file system is quiesced
Subtype 4—Written after the file system is unquiesced
Subtype 5—Written when the file system is unmounted**
Subtype 6—Written when the file system is remounted
Subtype 10—Written when a file is opened
Subtype 11—Written when a file is closed**
**Key subtypes that have performance information. Subtype 11 is the most important
subtype for performance data.
15

16
SMF 92 HFS file information:
From the SMF type 30 record, use the SMF30OPI (16777244) value to identify the HFS file ID
(SMF92CIN) in the SMF type 92 records. You can also review file information for this job.
DAY HOUR SYSID JOB FILE DEVICE | PROCESS DIRBLKS RBLKS WBLKS
SMF92CIN SMF92CDN | SMF92PID SMF92CDI SMF92CIR SMF92CIW
***************************************|*************************************
19 10.00 SSP1 HTTP11 1138 10 | 16777244 18 52 3
19 10.00 SSP1 HTTP11 2130 9 | 16777244 27 2810 151
19 10.00 SSP1 HTTM11 2133 27 | 16777244 22 831 51
19 10.00 SSP1 HTTP11 2140 26 | 16777244 18 474 2
19 10.00 SSP1 HTTP11 3162 23 | 16777244 36 57 0
19 10.00 SSP1 HTTP11 3170 23 | 16777244 9 25 1
19 10.00 SSP1 HTTP11 5280 7 | 16777244 31 2011 61
19 10.00 SSP1 HTTP11 6338 8 | 16777244 30 1056 129
19 10.00 SSP1 HTTP11 6339 8 | 16777244 43 2271 156
19 10.00 SSP1 HTTP11 6348 8 | 16777244 18 96 3
19 10.00 SSP1 HTTP11 6349 8 | 16777244 9 32 2
You can find the dataset name by using the file ID (1138) and matching it to the file ID in
the UNIX file and directory list. The following UNIX command will produce a list of
dataset names. It is important to note that the base directory is a good place to start.
This list may be very long depending on how many datasets are in the HFS file.
Example:
(Ls - List file & directory names)
ls - R i l / > dataset.name
Results:
To save space, some results have been excluded. In an actual list, there will be a section
for each directory. The first line tells how many datasets are in the directory. The sixth field
is the file ID that you will match with the file ID from the SMF type 92 Records. You now
have the dataset name—srvrctrl.pid
etc/NC:
total 56
10 -rw-r—r— 1 OMVSKERN OMVSGRP 2130 Apr 20 08:56 BETA.conf confold
11 -rw-r—r— 1 OMVSKERN OMVSGRP 3162 Apr 19 15:48 BETA.confold
12 -rwxr-xr-x 1 OMVSKERN OMVSGRP 343 Apr 19 15:47 BETA.envvars
6 -rw-r—r— 1 OMVSKERN OMVSGRP 1138 May 7 10:56 srvrctrl.pid
7 -rw-r—r— 1 OMVSKERN OMVSGRP 6349 May 10 08:13 test.confdel
8 -rwxr—r— 1 OMVSKERN OMVSGRP 328 May 7 10:51 test.

HFS DASD Performance
Following are recommendations for improving HFS DASD performance:
• Use cached DASD devices.
• HFS writes all data to disk synchronously. SMS 1.5 HFS enhancement is the
recommended base level. With 1.5, the writes can also be asynchronous.
• DASD FAST write and dynamic cache management enhanced will give the
best I/O response times.
• Avoid multiple extents in HFS datasets by consolidating to one extent using DFSMSdss.
• Spread high activity HFS datasets across multiple volumes to keep user HFS datasets
separate from system HFS datasets.
• Fix HFS buffers for SMS in BPXPRMxx.
Example
FILESYSTYPE TYPE(HFS)
ENTRYPOINT(GFUAINIT)
PARM(‘SYNCHDEFAULT(xx),VilRTUAL(xx),FIXED(xx)’)
• Place UNIX files as close to the root directory as possible.
• HFS locks all the paths to the file.
• Try to minimize the number of directory levels.
• Avoid collecting unnecessary data. Be selective when collecting statistics and log data.
The HFS dataset is a standard OS/390 PDSE structure only in content. The PDSE
access method is only used to open the file. After it is opened, it is managed by
UNIX services. The DCB parameter is DSNTYPE=HFS.
17

18
Additional Information
• HFS datasets do not benefit from enhanced internal processing for PDSE searches.
• HFS datasets are not conventional PDSE files. DFSMS will not use expanded storage for
hiperspaces staging.
• HFS datasets must be allocated as system managed datasets.
• You must define at least one storage group and one data class. To specify performance
requirements, define a storage class.
Realizing the benefits of performance analysis
Usually a performance assessment is performed when applications are experiencing
performance problems or when analysts need to know if there is enough capacity to
support growth or new workloads. It is critical to weigh the cost of performing an assessment
(usually consisting of the costs associated with consultant fees and developing new
skills) with the financial impact of not obtaining the right level of system performance. If a system
is performing efficiently, productivity improves and business objectives are met. If a
system is not performing well, productivity decreases and your skilled analysts are
distracted from working on new business objectives. Conflicts resulting from the complex
process of trying to determine the problem without using a proven methodology often
leads to a decline in team moral within your IT organization. By far, the worst effect of poor
performance is unsatisfied clients; this has an extremely negative impact on the new
application’s success.
Establishing a standard method for performance analysis of your OS/390 Web servers
provides a consistent, effective process for monitoring and managing system resources.
Periodic analysis optimizes valuable systems and network resources, as well as the skills
of your analysts. Using an independent source for performance analysis offers you a
periodic validation of your processes and procedures.

For more information
To learn more about IBM Performance Management and Capacity Planning Services and
IBM Global Services, visit www.ibm.com/services or contact your IBM sales representative.
You can also contact us at 1 800 426-4682 in the U.S. and 1 919 301-4141 outside
of the U.S., or e-mail us at capacity@us.ibm.com.
Gary Hall is a certified IT specialist responsible for performance management on OS/390
software platforms for IBM Performance Management and Capacity Planning Services.
For more information about Web server performance, the following publications are
available:
UNIX System Services Planning—SC28-1890
UNIX Command Reference—SC28-1892
OS/390 RMF Report Analysis—SC28-1950
OS/390 MVS System Management Facilities—GC28-1783
IBM WebSphere Application Server 1.1—SG24-5604
IBM HTTP Server 5.1—SG24-5603
Hierachical File System Usage Guide—SG24-5482
IBM TCP/IP Performance Tuning Guide—SC31-7188
MVS TCP/IP User’s Guide—SC31-7136
OS/390 eNetwork Communication Server: IP User’s Guide and IP Configuration
Guide—SC31-8513
19

© Copyright IBM Corporation 2000
IBM Global Services
Route 100
Somers, NY 10589
Produced in the United States of America
04-00
All Rights Reserved
IBM, the e-business logo, CICS, DB2, IMS/ESA,
OS/390, and WebSphere are registered
trademarks or trademarks of International
Business Machines Corporation in the United
States, other countries or both.
Windows NT is a registered trademark of Microsoft
Corporation in the United States, other countries
or both.
UNIX is a registered trademark in the United States
and other countries licensed exclusively through
The Open Group.
Other company, product and service marks may be
trademarks or service marks of others.
References in this publication to IBM products or
services do not imply that IBM intends to make them
available in all countries in which IBM operates. IBM
reserves the right to change specifications or other
product information without notice.
This publication may include typographical errors
and technical inaccuracies and may be changed
or withdrawn at any time. The content is provided
as is, without warranties of any kind, either express
or implied, including the implied warranties of
merchantability and fitness for a particular purpose.
Some jurisdictions do not allow disclaimer of express
or implied warranties in certain transactions, therefore
this disclaimer may not apply to you.
G510-1183-00