S/390 Server Consolidation A Guide For It Managers: Michael Macisaac, Mike Duffy, Martin Söllig, Ampie Vos

S/390 Server Consolidation
A Guide for IT Managers
Michael MacIsaac, Mike Duffy, Martin Söllig, Ampie Vos
International Technical Support Organization
http://www.redbooks.ibm.com
SG24-5600-00
SG24-5600-00
International Technical Support Organization
S/390 Server Consolidation - A Guide for IT Managers
October 1999
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix B, “Special Notices” on page 133.
First Edition (October 1999)
This edition applies to all S/390 hardware up to G6, and releases up to Version 2, Release 8 of OS/390.
Comments may be addressed to:

IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
522 South Road
Poughkeepsie, NY 12601-5400
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1999. All rights reserved.

Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Chapter 1. Introduction to server consolidation .. . . . .. . . . . .. . . . . .1

1.1 What is server consolidation. . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .1
1.1.1 Centralization . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .2
1.1.2 Physical consolidation . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .3
1.1.3 Data integration . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .4
1.1.4 Application integration . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .5
1.2 Why consolidate servers . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . .6
1.2.1 The total cost of computing. . . . . . . . . . . . .. . . . .. . . . . .. . . . . .7
1.2.2 Manageability and availability . . . . . . . . . . .. . . . .. . . . . .. . . . . .7
1.2.3 Data access and protection . . . . . . . . . . . .. . . . .. . . . . .. . . . . .8
1.2.4 Leveraging existing investments . . . . . . . . .. . . . .. . . . . .. . . . . .8
1.2.5 Scalability and workload growth . . . . . . . . .. . . . .. . . . . .. . . . . .9
1.2.6 Reduced technical complexity . . . . . . . . . .. . . . .. . . . . .. . . . . .9
Chapter 2. What S/390 has to offer . . . . . . . . . . . . . . . . . . . . . . .. . . . . 11

2.1 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 11
2.2 S/390 CMOS design history . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 14
2.3 Availability and reliability of the S/390 architecture . . . . . . . . . .. . . . . 15
2.3.1 S/390 CMOS server continuous availability . . . . . . . . . . .. . . . . 16
2.3.2 ESCON continuous availability . . . . . . . . . . . . . . . . . . . . .. . . . . 18
2.3.3 DASD subsystems continuous availability. . . . . . . . . . . . .. . . . . 18
2.3.4 OS/390 continuous availability . . . . . . . . . . . . . . . . . . . . .. . . . . 19
2.3.5 OS/390 UNIX System Services continuous availability . . .. . . . . 19
2.3.6 Parallel Sysplex continuous availability. . . . . . . . . . . . . . .. . . . . 20
2.4 The approach of sharing everything . . . . . . . . . . . . . . . . . . . . .. . . . . 20
2.4.1 Different sharing approaches . . . . . . . . . . . . . . . . . . . . . .. . . . . 20
2.4.2 Multiple workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 26
2.4.3 Logical partitioning with PR/SM . . . . . . . . . . . . . . . . . . . .. . . . . 27
2.4.4 Parallel Sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 29
2.5 The hardware for S/390: CMOS processors available . . . . . . .. . . . . 32
2.5.1 The S/390 9672 servers . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 32
2.5.2 The S/390 Multiprise 2000 . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 33
2.5.3 The S/390 Integrated Server. . . . . . . . . . . . . . . . . . . . . . .. . . . . 35
2.6 The software for S/390: OS/390 and related products . . . . . . .. . . . . 36
2.6.1 OS/390 packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 38
2.6.2 Systems management . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 39
2.6.3 Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 40
© Copyright IBM Corp. 1999 iii

2.6.4 Security . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 43
2.6.5 Available databases solutions. . . . .. . . . . .. . . . .. . . . . .. . . . . 45
2.6.6 UNIX System Services . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 46
2.6.7 New workloads . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 48
2.7 Networking and connectivity . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 48
2.8 Future directions . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 48
2.8.1 Storage Area Network (SAN) . . . . .. . . . . .. . . . .. . . . . .. . . . . 49
2.8.2 FIber CONnection (FICON) . . . . . .. . . . . .. . . . .. . . . . .. . . . . 54
2.8.3 The Seascape architecture . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 55
Chapter 3. Networking and connectivity . . . . . . . . . . . . .. . . . . .. . . . . 59

3.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 60
3.2 ESCON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 60
3.3 FIbre CONnectivity (FICON) channel . . . . . . . . . . . . . .. . . . . .. . . . . 61
3.4 Open Systems Adapter (OSA) . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 63
3.4.1 OSA-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 63
3.4.2 OSA-2 configuration, management and control. . .. . . . . .. . . . . 65
3.4.3 OSA-Express Gigabit Ethernet . . . . . . . . . . . . . . .. . . . . .. . . . . 66
3.5 Cisco 7000 Channel Interface Processor (CIP) . . . . . .. . . . . .. . . . . 67
3.6 IBM 3745/3746 Communications Controller . . . . . . . . .. . . . . .. . . . . 68
3.7 IBM 2216 Multi-Access Connector . . . . . . . . . . . . . . . .. . . . . .. . . . . 68
3.8 IBM 3172-3 Interconnect Controller . . . . . . . . . . . . . . .. . . . . .. . . . . 69
3.9 Channel-attached RS/6000 . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 69
3.10 Direct channel connection for PC servers . . . . . . . . . .. . . . . .. . . . . 69
Chapter 4. Systems management . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 71

4.1 Systems management with OS/390 . . . . . . . . . . . . . . . . . . . . .. . . . . 71
4.1.1 System Automation for OS/390. . . . . . . . . . . . . . . . . . . . .. . . . . 71
4.1.2 OS/390 performance management . . . . . . . . . . . . . . . . . .. . . . . 72
4.1.3 OS/390 configuration management. . . . . . . . . . . . . . . . . .. . . . . 73
4.2 Enterprise systems management with Tivoli products. . . . . . . .. . . . . 73
4.2.1 Tivoli Enterprise architecture . . . . . . . . . . . . . . . . . . . . . .. . . . . 74
4.2.2 Tivoli Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 76
4.2.3 Tivoli’s three-tiered architecture . . . . . . . . . . . . . . . . . . . .. . . . . 77
4.3 Tivoli systems management products on OS/390 . . . . . . . . . . .. . . . . 77
4.3.1 Tivoli NetView for OS/390. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 77
4.3.2 Tivoli NetView Access Services (NVAS) . . . . . . . . . . . . . .. . . . . 78
4.3.3 Tivoli NetView Distribution Manager for MVS (DM/MVS) .. . . . . 78
4.3.4 Tivoli NetView Performance Monitor (NPM) . . . . . . . . . . .. . . . . 78
4.3.5 Tivoli NetView FTP for OS/390 . . . . . . . . . . . . . . . . . . . . .. . . . . 79
4.3.6 Tivoli Performance Reporter for OS/390 . . . . . . . . . . . . . .. . . . . 79
4.3.7 Tivoli Security Management . . . . . . . . . . . . . . . . . . . . . . .. . . . . 79
4.3.8 Tivoli Operations Planning and Control (OPC) . . . . . . . . .. . . . . 79
iv S/390 Server Consolidation - A Guide for IT Managers

4.3.9 Tivoli Service Desk for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.10 Tivoli Manager (TM) for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3.11 Tivoli Global Enterprise Manager (GEM). . . . . . . . . . . . . . . . . . 80
Chapter 5. Server consolidation on S/390 . . . . . . . . . . . . . . . . . . . . . . 85

5.1 S/390 server consolidation introduction . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.1 Rehosting work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.1.2 Interoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2 Porting applications to OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.1 Porting UNIX applications to OS/390 . . . . . . . . . . . . . . . . . . . . . 88
5.2.2 Porting UNIX applications summary . . . . . . . . . . . . . . . . . . . . . . 91
5.2.3 Porting NT applications to OS/390 . . . . . . . . . . . . . . . . . . . . . . . 92
5.3 Distributed business applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.1 Groupware applications: Lotus Domino . . . . . . . . . . . . . . . . . . . 93
5.3.2 Web serving: the OS/390 WebSphere Application Server . . . . . . 95
5.3.3 Enterprise Resource Planning: SAP R/3 . . . . . . . . . . . . . . . . . . . 99
5.3.4 Enterprise Resource Planning: BaanERP . . . . . . . . . . . . . . . . . 103
5.3.5 Enterprise Resource Planning: PeopleSoft . . . . . . . . . . . . . . . . 103
5.4 File and print interoperability in a heterogeneous environment . . . . . 104
5.4.1 Novell style file and print serving . . . . . . . . . . . . . . . . . . . . . . . 105
5.4.2 Windows Style file and print serving . . . . . . . . . . . . . . . . . . . . . 108
5.4.3 UNIX style file and print serving . . . . . . . . . . . . . . . . . . . . . . . . 111
5.4.4 Data backup and recovery - Tivoli ADSM . . . . . . . . . . . . . . . . . 114
5.5 Sizing servers - how many S/390 MIPS per server MHz . . . . . . . . . . 117
5.5.1 Using standard benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.5.2 Why Not Use MIPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.5.3 A suggested methodology to estimate relative capacity . . . . . . 121
5.6 S/390 Software pricing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6.1 Parallel Sysplex license charge . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6.2 S/390 Usage Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.6.3 Entry server S/390 one time charge . . . . . . . . . . . . . . . . . . . . . 124
5.6.4 Basic licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.6.5 Distributed Systems License Option (DSLO) . . . . . . . . . . . . . . 124
5.6.6 Multiple Operating System PR/SM (MOSP) . . . . . . . . . . . . . . . 124
5.6.7 Indexed Monthly License Charge (IMLC) . . . . . . . . . . . . . . . . . 124
5.6.8 Extended License Charge (ELC) . . . . . . . . . . . . . . . . . . . . . . . 125
Appendix A. Server consolidation case studies . . . . . . . . . . . . . . . . . . 127

A.1 Successful Domino on OS/390 consolidation . . . . . . . . . . . . . . . . . . . . . 127
A.1.1 Business need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.1.2 Description of solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.1.3 Value to customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.1.4 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
v
A.2 Successful OS/390 UNIX in-house port . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.2.1 Business need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.3 Successful OS/390 UNIX vendor port. . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.3.1 Business need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.3.3 Value to vendor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
A.4 Successful LAN data consolidation onto OS/390 . . . . . . . . . . . . . . . . . . 130
A.4.1 Business need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.5 Java port to OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.5.1 Business need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Appendix B. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Appendix C. Related Publications. . . . . . . . . . . . . . . . . . . . . . . ...... . 137

C.1 International Technical Support Organization Publications . . . ...... . 137
C.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... . 138
C.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... . 138
How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

IBM Redbook Fax Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
vi S/390 Server Consolidation - A Guide for IT Managers

Preface
This redbook was written for Information Technology (IT) managers who want
to improve their understanding of how IBM S/390 servers can integrate with
other systems, and how S/390 servers can run new applications such as
Lotus Domino, SAP R/3 and Internet solutions. S/390’s scalability and ability
to run multiple workloads enables you to consolidate or reduce the number of
servers you may have.
The redbook provides an introduction to S/390 capabilities in these areas. It

is not intended to deliver detailed technical descriptions, but offers an
overview of the range of technical solutions available today on S/390 servers,
and points to sources of further information.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization Poughkeepsie
Center.
Michael MacIsaac is a team leader for S/390 redbooks and workshops at the
ITSO Poughkeepsie Center. He writes about, and teaches IBM classes on,
S/390 Server Consolidation. Michael has worked at IBM for 12 years, mainly
as a UNIX programmer. He has written redbooks on NT porting to OS/390,
S/390 file serving capabilities, and was the main author of the redbook
Networked Applications on OS/390 UNIX.
Mike Duffy is a Senior Instructor with IBM Learning Services in the UK where
he teaches and develops courses in the S/390 curriculum area. In his 25
years with IBM he has worked in a wide range of areas, including specialist
support on most of the items covered in this redbook. He has produced many
presentations, white papers and technical booklets dealing with LAN and
S/390 integration, ADSM, OSA-2, TCP/IP, and e-Business.
Mike was not part of the residency that created the redbook; however, it was
based on a white paper he wrote in 1997.
Martin Söllig is a High End Systems Engineer in Germany. He has nine

years of experience in the S/390 field. He holds a degree in mathematics from
the University of Hamburg. His areas of expertise include S/390 hardware
and major software products on OS/390.
© Copyright IBM Corp. 1999 vii

Ampie Vos is a National MVS and VM team leader for IBM Strategic
Outsourcing in New Zealand. He has 12 years of experience in the IT field,
mostly as an MVS or OS/390 Systems Programmer. He holds a BSc
Computer Science and a BSc Honns degree from Potchefstroom University of
South Africa. His areas of expertise include S/390 hardware and OS/390.
Thanks to the following people for their contributions to this project:
Terry Barthel, Dotti Still, Ken Trowell, Stephen Turner

International Technical Support Organization, Poughkeepsie Center
Max Bidle, Bill Marchetti, Alan Martens, Joe Temple

IBM Poughkeepsie
Martin Ferrier
IBM UK
Hans Dieter Mertiens

IBM Germany
Alfred Trompeta
MOSAIC Software AG
Budi Darmawan
IBM Austin
Comments welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your

comments about this or other redbooks in one of the following ways:
• Fax the evaluation form found in “ITSO Redbook Evaluation” on page 147
to the fax number shown on the form.
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Send your comments in an internet note to redbook@us.ibm.com
viii S/390 Server Consolidation - A Guide for IT Managers

Chapter 1. Introduction to server consolidation
A decade ago, business professionals and department heads grew weary of

the “wait” time associated with application development and the centralized
control and management of all information technology (IT) within an
enterprise. Moreover, as mainframe and associated peripheral and software
costs were on the increase, they were often passed on to the respective
information systems users. It became evident that this would eventually lead
to decentralization.
Distributed, client/server computing provided the autonomy that departments

and other entities were looking for, while seemingly providing IT organizations
with a more cost-effective computing alternative.
Now IT agendas are changing again. Priorities are moving from business
units, divisions and departments to large-scale organizational systems.
Infrastructures are being put in place to support new goals of business
integration, transparency of information and electronic business (e-business)
across the entire enterprise.
The proliferation of servers resulting from the move to distributed computing

often created fragmentation and inefficiency. These obstacles must be
removed before new challenges can be met. The new, integrated systems
are too large to run on small servers, and are too critical to entrust to their
instabilities. The focus of enterprise application deployment must move to
larger-scale, more stable platforms. Consolidation is the solution.
1.1 What is server consolidation

Server consolidation is the trend to centralize business computing workloads
to reduce cost, complexity, network traffic, management overhead and, in
general, to optimize and simplify the existing IT infrastructure and provide a
foundation for new solution investment and implementation.
There have been many studies of the total cost of distributed client/server
computing, but all analysts agree on one thing: in a “pure” client/server
implementation across a large enterprise, the hidden costs are staggering.
The components are already familiar: high maintenance and support
demands; reduced end-user productivity; increased training costs;
multiple-site software licensing costs; poor security; increased downtime and
lost data.
Server consolidation can be categorized into the following types:
© Copyright IBM Corp. 1999 1

• Centralization
• Physical consolidation
• Data integration
• Application integration
Figure 1 shows the four categories grouped into two consolidation phases,
physical (centralization and physical consolidation) and logical.
System Integration
Logical
Application
Integration
Data
Integration
Physical
Physical
Consolidation
Centralization
Figure 1. Four categories of server consolidation
1.1.1 Centralization
Server consolidation means different things to different people. As shown in
Figure 2 on page 3, in its simplest form, servers are physically moved to a
common location. Because this simplifies access for the IT staff, it helps
reduce operations support costs, improve security, and ensure uniform
systems management. This is an important predecessor to future
consolidation activities.
2 S/390 Server Consolidation - A Guide for IT Managers

NY CT
NY
GA CA
CA
NJ MN
Figure 2. Centralization
Virtual centralization or remote management

You can begin centralization in small steps. With virtual centralization or
remote management, physically dispersed servers or storage systems are
logically centralized and controlled through the network. Hardware remains
physically distributed, but is brought under a common umbrella of systems
management and network management tools. Operations costs can therefore
be reduced, and system availability can be improved. For further discussion
on the topic see 4.2, “Enterprise systems management with Tivoli products”
on page 73.
1.1.2 Physical consolidation

Physical consolidation can be divided into two sub-categories, namely server
consolidation and storage consolidation; see Figure 3.
a a
Figure 3. Physical Consolidation
Introduction to server consolidation 3

Server consolidation is the practice of replacing small servers with larger
servers of the same breed. This consolidation has advantages: it improves
availability because there are fewer points of failure; it can reduce the cost
and complexity of system communications; it simplifies operations.
The ability to physically consolidate is fed by Moore’s law - the fact that the
number of transistors which can be put on a chip doubles approximately every
18 to 24 months. The “law”, which shows no sign of coming to an end soon,
means that more powerful servers are always available.
Storage consolidation is combining data from different sources (same or

disparate types) into a single repository and format. This means that storage
is viewed as an enterprise resource, where centralized disk space is used to
supply the storage for the servers of the enterprise.
1.1.3 Data integration

As shown in Figure 4, data integration is the process of taking information
from several disparate sources and merging it into a single repository and a
common format.
a
a a
a
Figure 4. Data integration
Enterprise servers are a logical safe haven for data that is now scattered in
Local Area Networks (LANs) throughout the enterprise. When all corporate
data resides on the same robust system, the efficiencies can deliver
immediate payback to end users. Data sharing throughout the enterprise is
vastly simplified. Consolidation allows high levels of security and data
integrity that are nearly impossible to achieve in a distributed environment.

In many client/server infrastructures, centralizing LAN data can bring
dramatic improvements in data transfer speed. New enhancements in
communications hardware will expand the high-speed connectivity options to
server platforms of all types.
1.1.4 Application integration

Figure 5 shows an example of application integration. The two categories of
application integration are:
• Combining multiple similar applications (like Web servers) onto one
consolidated server
• Combining different application workload types within a single architecture
a b a b
d e d e
Figure 5. Application integration
When a single server is able to run multiple workloads, multiple servers which
are dedicated to run individual workloads can be consolidated. When the
distributed servers and the consolidation server run the same applications
and operating system, the migration is relatively straightforward.
Based on the consolidation platform, this migration can take different forms:
• The migration may just be the relocation of the application on the server.
• The migration may imply that application programs have to be recompiled
in order to run on the new platform.
• It may also imply that application programs have to be redesigned and
rewritten in order to run on the consolidation platform.

1.2 Why consolidate servers
The benefits that fueled the movement to decentralization and distributed
computing were often costly to achieve or did not materialize at all. Since
1990, many IT organizations have done a 180 degree turn in moving from a
decentralized architectural structure to moving towards a more centralized
environment. The relative importance of this shift is that it tends to validate
the needs and benefits of server integration.
Analysts and IT professionals say proliferation of systems is driving the

movement to rein in servers. Other enterprise players have also launched
their own consolidation strategies, such as Sun Microsystems' Data Center
Server Consolidation Program and Hewlett-Packard's Server Farm. What is
driving consolidation are the changes in business practices, making it logical
for users to collect their applications, LANs, and data-center functions.
Figure 6 shows why IT organizations move toward server consolidation. The

graph shows the percent of those responding who answered positively.
Reduce/control growth in IT costs

Improve manageability/availability
Improve data access/protection
Leverage existing investments
Reduce technical complexity
Scalability/workload growth
Change in business strategy
Previous failures
Other
0% 20% 40% 60% 80%
Figure 6. Reasons for consolidation

Source: International Technology Group (ITG) Management Brief Business
Value of Consolidation, 1998
1.2.1 The total cost of computing

As Figure 7 shows, using the analogy of an iceberg floating in the water, int
that most distributed systems’ costs are not visible, whereas data center
costs are fully visible. Consistently, studies have shown that in comparing
total costs of a multiple server environment versus those of a more
centralized solution, costs are less in the latter case.
Figure 7. True total cost of computing
Furthermore, economies of scale are obtained from the integration of many

servers onto one platform.
1.2.2 Manageability and availability

Server consolidation can help you improve manageability and availability of
IT systems in the following ways:
• Enterprise Management - Integrated operations allows for consistent
management of all facilities and IT services.

• Continuous Operations - 24 x 7 operations have become the norm. Most
systems and applications can provide business benefits from continuous
operations.
• Consistent performance - Providing consistent response time at peak load
periods is very important. Workload Manager in OS/390 provides for more
consistent response times even with utilization in the 90 percent range.
• Dependability - Commonly cited problems of distributed environments
include frequency of outages and excessive requirements for manual
intervention by IT staff.
• Floor space constraints - Limited floor space may seriously constrain
growth. While a single small server may not take up a lot of space,
enterprises find that suitable floor space is hard to find for proliferating
small servers.
1.2.3 Data access and protection

Server consolidation can help you improve data access and protection in the
following ways:
• Network technology - The growth of networking and network speeds is
enabling the centralization of IT networks today and will continue and
expand into the future.
• Fragmentation and duplication of data - This is a core issue in most
organizations with large numbers of distributed servers.
• Enterprise security - Capitalizing on a “classic” strength, S/390 and
OS/390 provide industry-leading security. Distributed operations can
benefit from this platform security by integration on S/390.
• Physical security - Consolidation of servers in a central data center can
restrict unwanted access and ensure a more secure environment.
• Integrity, local backup and recovery - Enterprises are concerned about
dangers of business disruption, customer lawsuits and regulatory action in
the event of severe data loss, and they need to implement effective
disaster recovery procedures.
1.2.4 Leveraging existing investments

Server consolidation can help you leverage existing investments in the
following ways:
• Expand existing servers - Add new capabilities to the existing installation
rather than to deploy new dedicated servers.

• Optimization of capacity utilization - In order to manage performance and
have a level of acceptable, consistent response times, enterprises
typically run at 50 to 60 percent utilization. Excess or underutilized
capacity on one server cannot be shared with workloads of other servers
in a distributed environment.
• Optimization of skilled resources - Under the distributed alternative,
systems management responsibilities are often only part-time, extra duty
assignments such that a critical skill level is rarely achieved. Furthermore,
since other departments may employ disparate architectures and
applications, there is little opportunity to benefit from the experience of
others.
A consolidated server site with standardized hardware and software can
readily justify dedicated experts with the in-depth training to quickly
resolve problems.
1.2.5 Scalability and workload growth

Server consolidation can help you handle scalability and workload growth
issues in the following ways:
• True scalability - Server consolidation provides the ability to deal with
peak usage without crashing or seriously degrading performance. It also
provides an upgrade path without degradation in response, excessively
complex forms of database partitioning or other problems.
• Granular upgrades - Server consolidation provides the ability to quickly
grow the number of users, the number of applications or the size of an
application when needed, without major disruptions to the current
production environment.
1.2.6 Reduced technical complexity

Three-tier logical architectures tend, in practice, to become five-tier
architectures (client, local server, central server, gateway, enterprise server).
Server consolidation can simplify technical complexities by eliminating the
true number of tiers in a purported three-tier architecture by reducing or
eliminating central servers and gateways.

Chapter 2. What S/390 has to offer
The S/390 Enterprise Server has been the main platform for enterprise data
processing operations for many years. The unique strengths of the IBM S/390
platform – its ability to run multiple workload types with exceptionally high
reliability, throughput, security and manageability – have been imitated but
never matched by other server platforms.
In more recent times, S/390 has built on these “traditional” strengths by

incorporating a number of open interfaces which allow it to interoperate and
integrate in an open, heterogeneous computing environment. Key among
these are the UNIX System Services which are part of OS/390, and
OpenEdition, which is part of VM. These services allow S/390 to run
applications which were originally developed for the UNIX environment,
including SAP R/3 and many other Enterprise Resource Planning (ERP)
applications, together with Lotus Domino, and many applications for business
intelligence and e-business.
As the trend to server consolidation grows, the role of S/390 servers is again
being redefined. This chapter highlights the design principles of S/390 and
their implementation, which make S/390 a powerful, reliable and manageable
platform for running commercial applications. Special focus is put on the
ability of S/390 to perform as a server in a client/server environment.
2.1 Business requirements

As a starting point for server consolidation, the business requirements for the
IT infrastructure have to be considered. Figure 8 on page 12 shows the three
primary types of server platforms available today, each of them having
different characteristics to meet different-sized requirements.

Large
Systems
Size/Capacity Mid-range
PC
File...Print...Communication...Database...Application Processing
Figure 8. Three types of servers
These three classes of servers are:

• PC servers, based on operating systems such as Windows NT, Novell
NetWare and OS/2
• Mid-range servers - examples are the IBM AS/400 and various UNIX
servers such as the IBM RS/6000
• Large system servers - such as the IBM S/390
Historically, all these servers had their own field of applications, strictly
separated from the others. While the smaller PC and UNIX servers were
originally designed and optimized for processor-intensive work, the AS/400
and the large-scale servers come from a commercial background, where the
key requirements are to process and store vast amounts of data.
In recent years, the differences between the three classes of servers have
been decreasing, while applications have become portable or even
interoperable among the different platforms. While OS/390 servers embraced
open systems, midrange UNIX servers and even PC servers have been
equipped with powerful processors and huge storage subsystems. IBM's

S/390 server family has successfully made the migration from being
“traditional mainframes” to being very powerful servers.
Since the IT manager is able to choose between different platforms for

running the same applications, the decision criteria for selecting the most
suitable server should be the following:
• Application design
• Data resources needed
• Performance requirements
• Scalability of the platform
• Service availability requirements
• Systems management capabilities
• Cost
If a small server with little manageability and no critical availability

requirement is needed, then a PC server can meet the requirements. If there
is no existing mainframe infrastructure, the smaller platforms are likely to be
more cost efficient, since there is no need for all the functions of a large
server. As the business grows, the application usage grows, and the server
platform requirements may change. Additional demands for the quality of the
selected server platform begin to arise.
The most frequently articulated requirement of most organizations is the need

for continuous data availability with integrity. S/390 reliability and availability
is unsurpassed. A typical S/390 is demonstrated to be 99.9 per cent
available, which equates to nine hours of unscheduled outage per year; a
typical S/390 Parallel Sysplex system is estimated to be 99.999 per cent
available, which equates to five minutes of unscheduled outage per year.
More importantly, Parallel Sysplex avoids scheduled outages as it allows
changes to be made within the sysplex concurrent with normal operations.
S/390 is IBM's proven scalable platform for commercial computing whose
individual systems support many thousands of users.
Small computers play a vital and growing role in today's computing world. But
time has shown that costs are higher and availability is lower when the job of
a large server is done with a group of small computers. An analogy is that
“you can move a pile of sand with one bulldozer or a thousand shovels”.
S/390 is acknowledged by consultants, such as IDC, Gartner Group, Xephon,
ITG, and others as having one of the lowest overall costs of ownership when
calculated over many years.
What S/390 has to offer 13

2.2 S/390 CMOS design history
The transformation of S/390 Enterprise Servers began with the introduction of
the Complementary Metal-Oxide Semiconductor (CMOS) technology, which
replaced the previous water-cooled bipolar technology. This critical
technology change has cut the physical size of S/390 hardware by up to 90
percent, and has resulted in major reductions in power consumption and
maintenance. The Generation-3 (G3) and Generation-4 (G4) S/390 Servers
extended CMOS processor performance into a range that allows them to
replace much larger bipolar machines. The Generation-5 (G5) and
Generation-6 (G6) uniprocessors went far beyond the performance of the
largest 9021 IBM bipolar uniprocessor.
The performance of the IBM uniprocessor on bipolar systems typically

doubled every five years. Compared to this, the CMOS technology is on a
much more rapid performance curve, doubling the engine performance every
18 to 24 months. Figure 9 shows the performance evolution of S/390 CMOS
uniprocessors, beginning with the R1 from 1994, up to the currently available
G6 server.
Uni-processor Comparison: Bipolar – CMOS

G6 Server
Relative G5 Server
Performance
9021-711 G4 Server
3090 9021-520 G3 Server

3090 3090 S
B E
3090 9672-R2/R3
J 9672-R1
Up to 3.2
85 94 95 96 97 98 99 times
Up to 2.4
G4
times
G4
0.2 times 0.3 times 0.7 times G6
G4 G4 G4 G5
R1 R2/3 G3 G4
Figure 9. S/390 CMOS capacity and performance

There are 24 G6 models which range from an entry-level server with one
engine up to 12-way systems. There are plans to use CMOS technology well
into the next century. In addition to performance improvements, CMOS
technology will continue to enhance system value through further reductions
in floor space, power consumption and cooling requirements. At the same
time, I/O and memory bandwidth will be increased and additional
architectural enhancements will be made. Figure 10 shows the function
enhancements that have been added to IBM CMOS servers since 1994. Most
of these enhancements are discussed in the following chapters.
R1/2/3 G3 G4 G5/G6
1994/95 1996 1997 1998 1999

Parallel Sysplex Internal Coupling Enhanced Processor Integrated Cluster Bus Non-Disruptive Growth
Coupling Facility (CF) Facility Design Internal Coupling (IC) Concurrent
Coupling Links HiPerLinks Dual I/E Units channel Conditioning
Integrated Coupling Dynamic CF Spare Processor 128 bit TOD Clock Capacity Upgrade on
Migration Facility Dispatching Unit Spare Processor Unit Demand
Coupling Facility Dynamic CF Dynamic CP Transparent CP/ICF Capacity BackUp
Control Code Expansion Sparing Sparing CBU Auto Activation
Sysplex Timer Dual Cryptographic Business Continuance Dedicated or Shared
Open Systems Coprocessor Function ICFs
Adapter Open Systems Partial I/O Enhanced Dynamic ICF
Adapter 2 (OSA-2) Half of a PU cluster Expansion
Enhanced Application Crypto NIST FIPS
Preservation Certification
Enhanced Storage FICON Channel Card
Recovery OSA Express
Enhanced Memory
Granularity
IEEE FP
Figure 10. S/390 architecture and function enhancements
An alternative option for small- and medium-sized businesses is the S/390

Multiprise 2000 described in 2.5.2, “The S/390 Multiprise 2000” on page 33.
This family of servers is available with packaged software and services that
allow businesses to get them up and productive quickly - without the need of
a large IT staff. All models can support an optional internal disk storage
devices and can run VSE/ESA, VM/ESA and OS/390. Another alternative for
small organizations is the S/390 Integrated Server family, described in 2.5.3,
“The S/390 Integrated Server” on page 35.
2.3 Availability and reliability of the S/390 architecture

When looking at the concepts of system availability, usually three terms are
distinguished:

High availability This is the ability of a system to provide service to
its users during defined service periods, at an
acceptable or agreed level. This implies that
unscheduled outages of the system have to be
avoided. Scheduled outages may be acceptable,
depending on the service level agreements.
Continuous operations This is the ability of a system to provide service to
its users at all times, day and night, without
scheduled outages to perform system and data
maintenance activities. However, nothing is said
about the avoidance of unscheduled outages.
Continuous availability This is the property of a system that provides both
high availability and continuous operation at the
same time. The system must be designed so
users experience neither scheduled nor
unscheduled outages.
The goal of continuous availability seems difficult to achieve, as hardware and

software components are usually not error-free, often require maintenance,
and frequently undergo component additions and changes. The solution is to
employ hardware components, software, and operational procedures that
mask outages from the user. This solution usually requires that recovery from
an outage must be performed so quickly that the user does not perceive it as
an outage. It also frequently requires the use of redundant components, so
that an alternate component can be used in case of a permanent component
failure, or while the component is in maintenance.
IBM S/390 servers have been designed for such continuous availability. All
the components of the S/390 architecture focus on reliability and
serviceability. This book will briefly summarize these features.
For a detailed discussion of these topics, see the redbooks Continuous

Availability Systems Design Guide, SG24-2085 and Continuous Availability
S/390 Technology Guide, SG24-2086.
2.3.1 S/390 CMOS server continuous availability

A fault-tolerant design allows hardware recovery to be performed
transparently in most cases and eliminates or defers the need for a repair
action. The S/390 processor design contains dual instruction/execution units,
which operate simultaneously, virtually eliminating Central Processor (CP)
failures due to soft errors. In the event of a CP or a System Assist Processor
(SAP) failure, and when a spare Processing Unit (PU) is available, the system

in most cases will dynamically initialize a spare PU to take over as a CP or
SAP. An application running on a failing CP will be enabled to continue
execution on another CP by the Processor Availability Facility (PAF).
Memory error checking and correction code is able to detect and correct up to
four bit errors in a single memory chip, reducing the possibility of an outage
due to a memory chip failure. In the event of cache and directory errors, the
affected areas will be removed from the configuration, while processing will
continue. The processor storage cards are equipped with spare memory
chips, and dynamic storage reconfiguration of both central and expanded
storage is available. Storage background scrubbing provides continuous
monitoring of storage for the correction of detected faults before the storage
is used. In the event of a memory card failure, Partial Memory Restart
enables the system to be restarted with half of the original memory.
Subsystem Storage Protection prevents applications which are running in the

subsystem’s address space from overwriting the subsystem code, control
blocks, and the subsystem data.
Hot-plugging of channels with Enterprise System CONnection (ESCON) and

parallel, coupling links and Open System Adapter-2 (OSA-2) allow
configuration changes non-disruptively during system operation. Dynamic I/O
Reconfiguration Management (DRM) allows modification of the hardware and
software I/O configuration. In the event of a failure of one of the two memory
bus adapters, Partial I/O Restart enables the system to be restarted with half
the I/O connections available.
The power system offers dual primary (AC) power feeds, each electrically
isolated and enabling redundant power paths to each server. The power
subsystems are designed with N+1 redundancy, which ensures that a failure
of a power thermal component does not cause a system outage, while
concurrent replacement of the failed component results in avoidance of a
planned outage. The Internal Battery Feature (IBF) further enhances the
robustness of IBM CMOS power design, increasing power line disturbance
immunity.
Concurrent hardware maintenance allows the replacement of a failing unit

without powering off the system. Concurrent maintenance capability exists on
ESCON channels, parallel channels, coupling links, OSA-2, power elements,
thermal elements, support element and hardware management console. Also
most Licensed Internal Code (LIC) patches can be activated dynamically.
The reliability of this processor and server design is unsurpassed in the

industry.

2.3.2 ESCON continuous availability
The Enterprise System CONnection (ESCON) architecture allows longer
distance connections with data transfer at a higher speed than the old parallel
architecture, which enhances the possibilities for disaster recovery.
Connectivity standards as ESCon Director (ESCD) and Escon Multi-Image

Facility (EMIF) allow sharing and a redundant design of complex I/O
configurations, with the ability to switch dynamically the physical connection
paths.
Fault-tolerant features of the ESCD are available, such as a spare Token Ring
card, power supply, control processor, matrix controller and switch.
Non-disruptive upgrades and dynamic reconfiguration of I/O devices and

ESCD are provided.
2.3.3 DASD subsystems continuous availability

Today S/390 Direct Access Storage Devices (DASD) subsystems usually
have various Redundant Array of Independent Disks (RAID) implementations.
A RAID is any disk subsystem architecture that combines two or more
physical disk storage devices into a single logical device to achieve data
redundancy. RAID types were originally categorized into five levels: RAID-1
through -5. (RAID-2 and RAID-4 have limited practical value because they
store redundancy information less efficiently.) It has become popular to refer
to a non-redundant array of disk drives as a RAID-0 array. In addition, a new
RAID-6 implementation which uses dual redundancy with floating parity is
now commonly used. RAID implementations reduce DASD outages and loss
of data in the event of hard drive failures.
For example, the internal disks of the Multiprise 2000, the Dual Copy
functionality of the 3990 and 9394, and the two forms of Remote Copy;
Peer-to-Peer Remote Copy (PPRC) and eXtended Remote Copy (XRC) in the
3390-6 and the RAMAC Virtual Array (RVA) are RAID-1 implementations.
This means the disks are mirrored to duplicate the data. The 9392 and 9395
RAMAC drawers and the RAMAC Scalable Array (RSA) contain RAID-5
implementations, where data is stored on multiple disk drives, with a portion
of each drive used to maintain parity information for the other drives. The RVA
is a RAID-6 implementation. The Enterprise Storage Server (see 2.8.3, “The
Seascape architecture” on page 55) is usually a RAID-5 implementation, but
additionally it allows individual groups of disks to be configured as non-RAID
(RAID-0) devices.

To avoid scheduled outages for backing up data, the RVA supports SnapShot
Copy, whereas the 3990-6 is able to use Concurrent Copy. Another way to
obtain an instantaneous image of a volume is to use the contents of a remote
secondary volume, while the application keeps working with the primary
volume.
Depending on the DASD subsystem type, many additional features are

provided to avoid scheduled and unscheduled outages. Examples are the
ability to perform a concurrent microcode update, a non-disruptive DASD
installation and remote service connectivity.
2.3.4 OS/390 continuous availability

The flagship operating system of S/390 servers is OS/390. It is designed for
continuous availability, exploiting the features provided by the hardware.
OS/390 delivers an integrated set of MVS, UNIX, LAN, distributed computing,

and application enablement services through its base elements. Its release
schedule is regular and predictable. It is delivered in a pre-tested package,
ready to be installed quickly.
The S/390 Parallel Sysplex architecture (described in 2.4.4, “Parallel Sysplex”

on page 29) provides the basis for OS/390 availability improvements,
providing more integration, more function, and more synergy between
applications and the operating system. The long-term OS/390 trend is to
continue to provide functional consistency, extensive pre-testing, and
continued integration of products and features. Migration to new versions and
releases will continue to require less time, and provide a more stable and
available environment.
OS/390 is a growing platform. It offers continuous availability, with capacity

that virtually cannot be outgrown, and at low incremental costs. The S/390
strategic initiatives ensure that the business goals are directly supported by
the installed technology.
2.3.5 OS/390 UNIX System Services continuous availability

OS/390 UNIX System Services (OS/390 UNIX) offer a true UNIX
environment, making it possible to develop and port applications to OS/390.
Having achieved XPG4 UNIX 95 certification, OS/390 now provides
customers with full UNIX capabilities built directly into the operating system.
This is a critical differentiator between OS/390 and competing systems
because only OS/390 can provide UNIX facilities in tandem with the S/390
classic strengths that businesses have come to rely on.

2.3.6 Parallel Sysplex continuous availability
S/390 Parallel Sysplex is the current step in the evolution of IBM’s
multiprocessing mainframe architecture, presenting an advanced commercial
processing clustered system. It creates a processing facility where data can
be shared, with full integrity, among members of the sysplex. It also allows
the workload to be dynamically routed and balanced among these same
members. With this data sharing and dynamic workload balancing, high
availability and continuous operation can each be greatly improved when
compared with other systems.
2.4 The approach of sharing everything

When there is just one application running on a server, every resource of the
server is dedicated to this workload. Difficulties arise with the demand to run
several workloads in parallel. The server’s processors, memory, disk storage
and other resources are needed by more than one application and have to be
shared. From the counter point of view, the workload has to be distributed
across the available resources, and the access to shared data has to be
controlled.
The S/390 architecture shares every resource to every workload. This is

implemented in several steps, starting from a single system image on a single
server up to a cluster of tightly coupled systems.
The sections that follow discuss the ability of S/390 to share resources
among applications within:
• A system image (see 2.4.2, “Multiple workloads” on page 26)
• A S/390 server Central Electronic Complex (CEC) (see 2.4.3, “Logical
partitioning with PR/SM” on page 27)
• A Parallel Sysplex cluster (see 2.4.4, “Parallel Sysplex” on page 29)
An overview of the basic concepts and the consequences of the different

approaches of sharing resources will be provided. It turns out that clearly the
shared approach has many advantages.
2.4.1 Different sharing approaches

There are three basic workload distribution and data access system
structures that are used in the industry for parallel implementations. They are
distributed data, partitioned data and shared data, as illustrated in Figure 11
on page 21.

Distributed Partitioned Shared
Servers
Data
Coupling
Technology
Figure 11. Types of parallel processing
The distributed data implementation, shown on the left side of the figure,
does not lend itself to high performance OnLine Transaction Processing
(OLTP) due to slow intersystem network communications. It was, therefore,
not considered as a solution for IBM's Parallel Sysplex.
In a partitioned data implementation, the database is divided among the

various servers (processors) in the parallel system, and the workload is
distributed based on what data it needs to access. Each part of the data is
accessed and updated by only one server. This eliminates any possibility of
causing data integrity problems due to having more than one processor
updating the same data. This is the approach that most vendors in the
industry have used to implement parallel processing, including IBM's
RS/6000 SP.
With the shared approach, shown on the right side of the figure, all servers in
the cluster have equal access to all data. This allows the workload to be
distributed based on processor load rather than by data location. With the
shared data approach, workload and processor changes do not require a
reorganization of the data. IBM has used shared data in coupling S/390
processors and continues to use both shared data and partitioned data. The
new development emphasis for S/390 parallelism is on shared data.

2.4.1.1 Application availability
Now we will have a look at the application availability aspect. Figure 12
illustrates the consequences of a failing unit in a partitioned and in a shared
environment.
Partitioned Shared
Coupling
Technology
Figure 12. Availability in partitioned and shared environment
In a partitioned environment, if a server fails, another server must take over

the entire workload of the failed server. This is usually done by activating a
backup data path to the failed server's data. Users of the failed server and the
backup server may experience greater response times as one server tries to
do the work of two. Alternatively, workload policy decisions can be made to
“shed” work that is less important, sacrificing continuous availability for some
work for systems cost. This approach comes at the cost of greater complexity.
Configuring a system with redundant backup paths can be complicated, and it

requires that either the backup servers be large enough to handle their
current work plus the workload of a failed server, or there needs to be a
backup server that is not utilized except during a server failure. Additional
compute capacity must be purchased “just in case”. The resulting complexity
is considerable and costs are high.
In a shared environment, if a server fails, there is minimal impact to the

application in that all remaining servers still have access to all of the data.

The workload that would have been handled by the failed server will be
balanced automatically across the other servers. Management costs are
lower since each system has n-1 backups and only one set of recovery
procedures exists. This means that the reserve capacity to back up a server
can be spread over all of the remaining systems. Therefore, each server can
run at a higher utilization than in a partitioned environment. With this model,
additional compute capacity can be purchased “just in time”. Also, since the
workload from the failed server is distributed across all the remaining servers,
the effect of the outage is minimized.
2.4.1.2 Workload balancing

Figure 13 illustrates how different workloads are balanced across servers.
Tuned Benchmark Real Workload

Partitioned Shared Partitioned Shared
Coupling
Technology
Figure 13. Workload balancing in partitioned and shared environment
In a partitioned system, care must be taken to divide the data based on

workload activity. It is important to run work on the system which has access
to the data that work will reference. To the extent this can be done, good
performance can result. However, “hot spots” can occur where servers get
overutilized, and at the same time other servers may be underutilized. This
means that the workload must be closely monitored, and the partitioning of
the data must be altered frequently. This is a labor-intensive operation and is
costly and disruptive to users.
In the shared data environment, the workload can run on any server because
each has identical access to the data. Therefore, intelligent scheduling can

be used to allow dynamic workload balancing. This also results in more
consistent and potentially shorter response times for the end users. Since the
servers are managed as a single image, costs are reduced. Because the
shared data environment does not have to be continually tuned to handle hot
spots, the servers can be sized closer to the average workload across the
system than a partitioned server. In addition, administration costs are lower,
and disruption of service to reconfigure is not necessary.
Comparing a tuned benchmark to a real workload, one can see that the
utilization of the CEC/server and the processors within the CECs are
different. The shared system is better able to manage variations in workload
due to the shared data structure and workload balancing.
Partitioned organization is less flexible if the business needs to add a new

service (application) that requires data from multiple partitions. It causes
overhead to be incurred or it requires data to be reorganized. As we know,
time to market is an important business need today. In view of this, the
shared approach is more flexible and accommodating.
2.4.1.3 Adding servers and DASD

A major customer requirement for many years has been the ability for small
incremental growth of systems. Incremental growth scenarios are illustrated
in Figure 14 on page 25.

Partitioned Shared
Coupling Technology
Figure 14. Incremental growth in partitioned and shared environment
In a partitioned environment, when additional servers or DASD need to be

added, the data has to be redistributed across the databases and all work
requests rebalanced. This requires analysis of the workload to determine the
appropriate division. It also means that the data is likely to be unavailable
while the data reorganization is being done.
In a shared environment, additional servers and storage can be added to the

Parallel Sysplex. The benefit is immediately realized once the workload
manager knows about the additional resource. The processor or storage
resource can be utilized without having to unload and reload the entire
database. The workload is automatically rebalanced to use the new
resources, and no lengthy analysis needs to be done to split the workload. By
using capabilities such as ESCON, dynamic re-configuration and sysplex, the
S/390 implementation will be able to add servers and disk storage without
any interruption of service on the configuration undergoing growth.
Clearly the shared approach has many advantages.

2.4.2 Multiple workloads
The workload and resource scheduling components of OS/390 enable the
efficient running of many concurrent applications. Large batch suites, large
print runs, online interactive access and database transaction systems are
commonly found together on a single S/390 platform. This is illustrated in
Figure 15.
Domain 4 - Web Serving
Domain 3 -
Business Intelligence /Data Mining
Percent CPU Utilization
Domain 2 - Batch 200
Percent CPU Utilization

150
100
Domain 1 - OLTP
50
0
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
24:00
00:00
01:00
02:00
03:00
04:00
05:00
06:00
07:00
08:00
09:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
24:00
Figure 15. Running multiple Workloads in one system image
Batch processing is an often overlooked requirement in today’s client/server

designs. The lack of sophisticated workload management in UNIX frequently
precludes concurrent batch and online systems. The result is often the need
for an outage to online service, or the inability to run batch at all.
There are many resources to be found in any computing system, including

processor cycles, processor memory, virtual memory, I/O paths, intersystem
connections, disk space and so on. As the size and number of resources has
increased during the evolution of S/390, it has been necessary to modify and
improve the resource management algorithms. Each new frontier in
processor performance, memory size, addressing capability, disk I/O
performance and disk size resulted in changes to the task dispatchers and
resource managers in OS/390. UNIX is still early in this evolution process.

As a result of these improvements, S/390 has the capability of supporting the
largest configurations found in commercial data processing.
• S/390 can achieve processor utilizations for online systems of close to 100
percent, while still achieving sub-second response times. Many UNIX
systems can only achieve 50 to 60 percent utilization with 2 to 3 second
response times.
• Real and virtual memory management results in S/390 systems with up to
10 GB of processor memory without the need for addressing greater than
32 bit. The architecture supports up to 16,000 GB, although no user has
yet needed this. UNIX systems are being driven to 64-bit address ability
because of poorer memory management. Effective use of 64-bit
addressing will require changes to both UNIX and application packages
such as database management systems.
• Disk configurations of several terabytes can be efficiently managed with
disk space utilizations of 80 to 90 percent. UNIX systems are reported to
peak at between 300 GB and 400 GB per server.
A S/390 server can easily support large online transaction systems with
consistent subsecond response times, concurrently with large batch jobs,
print jobs and other workloads. This can be done based on business priorities
for each workload using the OS/390 Workload Manager - a performance
specialist working at processor speed.
2.4.3 Logical partitioning with PR/SM

Although S/390 operating systems (OS/390, VM/ESA and VSE/ESA) are
designed to run with multiple workloads, there are cases where it is more
appropriate to keep certain workloads separate. In this case one approach
might be to use multiple physical machines. Another option on S/390 is to
logically partition the workloads on a single machine.
The Processor Resource/System Manager (PR/SM) hardware feature, which

is standard on all but the very oldest S/390 systems, provides such a
function. LPAR mode (which stands for Logical PARtitioning and pronounced
“elpar”) has been available for many years and is taken for granted by S/390
users. However, the facilities, performance and flexible modes of operation it
offers are unrivaled by partitioning features on other systems.
Partitioning on other platforms generally involves dedicating specific

resources to each partition. For example, on a system with two processors,
one is dedicated to partition A and the other to partition B. By dedicating
resources in this manner, one partition cannot make use of any spare
capacity which might exist on another partition. Apart from the fact that both

workloads are running in a single physical box, this mode of operation is no
better than having discrete servers for each workload.
LPAR can work in this way if desired, but it is normally configured to work
with shared processors. To explain this concept, consider the example
illustrated in Figure 16.
4 LPs Dedicated or shared

I/O devices
PROD
3 LPs
DEV
4 real
processors 2 LPs
TEST
Figure 16. Example for sharing resources
Here we have a S/390 which has four processors (engines). There are three
logical partitions: PROD for production, DEV for development and TEST for
system programmer use. PROD is set up with four logical processors (LPs),
DEV with three, and TEST with two.
The LPAR microcode maps the work dispatched on each logical processor to
any one of the real processors using the priorities defined in the LPAR
configuration. For example, the relative priorities might be 70 percent for
PROD, 25 percent for DEV and 5 percent for TEST.
With this configuration, if all partitions have sufficient work to drive the S/390
to full capacity, then the processor resource would be shared in the above
ratios. However, should the PROD partition only need 50 percent, then other
partitions can use the spare capacity and extend beyond their nominal share.
When the higher priority partition needs more resource, LPAR once again
reallocates processing power as appropriate. This allocation is performed on

a sub-second basis such that good response times are maintained and so
that peaks in one workload are accommodated by troughs in another.
Because LPAR does not waste, or fence off processing power when running
partitioned workloads, S/390 can process more real work than other systems
of equivalent power when running partitioned.
Processor storage is normally allocated in specific “chunks” to each partition

and cannot be shared in quite the same way as processing power. However,
variable chunks of processor storage can be switched from one LPAR to
another by use of operator commands. For example, during the day one LPAR
might need large amounts of processor storage but might not need it
overnight. During this time, a portion of it could be allocated to another LPAR
to assist large background processing work, for example, and then be
switched back before the start of the prime shift.
I/O devices such as disks, tape, network controllers and so on can be

dedicated or shared across LPARs using single ESCON channel connections
or multiple older-style parallel channels. In this way the best use is made of
all resources and so avoids extra costs associated with installing multiple
footprints, each with its own I/O capability.
Each LPAR is a totally protected environment such that work running in one
LPAR cannot affect work in another LPAR. Two years ago IBM completed an
evaluation in the UK under the European certifications scheme (ITSEC) at the
E4 level, which was the highest level of assurance achieved for an IT product
in the UK. Consequently, LPAR is an ideal way to introduce new work onto
the S/390 platform, knowing that it will not compromise existing production
and other business-critical applications.
For example, most S/390 installations run at least one test partition in order to
install and test new systems software. Companies wishing to try out
Web/Internet services, or installing Lotus Domino for S/390, might install
these in separate LPARs until such time as they were better understood or a
strategy for them had been decided upon. Current S/390 CMOS processors
support up to fifteen LPARs on a single machine.
2.4.4 Parallel Sysplex

S/390 Parallel Sysplex is an innovative clustering architecture for continuous
computing that has already established a leadership position. It uses the
shared everything approach thoroughly described in earlier sections. Parallel
Sysplex is usually driven by the need for very high system availability – to
eliminate both planned and unplanned downtime. Yet in many IT

organizations, it has also become the cornerstone of a strategy to reduce
computing costs.
Scalability and flexibility are the center of that strategy. The scalability of
Parallel Sysplex is virtually without limit, providing an infrastructure that is
responsive to growth demands. The flexibility of Parallel Sysplex allocates
processing power dynamically, in real time, to the points in the system where
demand is greatest. Workload balancing allows IT managers to optimize the
use of existing capacity, and allows upgrades to be purchased on a “just in
time” rather than a “just in case” basis.
The challenge in designing clusters is in presenting a single systems image –

making separate systems work and appear as one. Typically with UNIX and
other clusters, the single image is compromised because data is partitioned
among the individual nodes, meaning that each data partition can be
accessed and updated only by the node to which it is connected. The
partitioned approach creates significant difficulties in capacity planning.
What separates S/390 Parallel Sysplex from other cluster implementations is

its unique data sharing architecture and the OS/390 WorkLoad Manager
(WLM).
S/390 parallel data sharing technology allows direct, concurrent read/write

access to shared data from all the processing nodes in the configuration –
with full data integrity and optimum performance. Given that all the data can
be shared, workload is allocated to the nodes, or servers, based on load
rather than on location of data, as in UNIX clusters previously described. This
workload distribution is managed by WLM which self-manages the Parallel
Sysplex configuration by dynamically adjusting workload priorities based on
customer-defined service level agreements. All of the functions of a Parallel
Sysplex require software support in the subsystems (for example CICS, IMS,
DB2) and may require support in applications to fully achieve the benefits
described.
Figure 12 on page 22 demonstrates the concept of S/390 Parallel Sysplex.

Coupling Technology
Sysplex Timer
ESCON/FICON
Shared data
Figure 17. S/390 Parallel Sysplex
From a hardware perspective, the heart of Parallel Sysplex is the coupling

facility, which is a high-performance, high-capacity shared memory device. It
enables data sharing and dynamic workload balancing.
In a Parallel Sysplex, up to 32 servers can be clustered, and each of these

servers has high-speed coupling links to one or more coupling facilities. Each
server is also connected to one or more Sysplex Timers, which provide time
synchronization among all servers in the sysplex.
For continuous availability, the coupling facility, the Sysplex Timer and all the
connections to the servers are usually duplicated. In the case of a failure,
alternative resources are ready to take over the tasks of the failing ones. If
any disruptive maintenance is necessary, the tasks can be shifted.
The coupling facilities can be standalone or an LPAR in a S/390 server. In the

latter case, the connection to the OS/390-driven LPARs in the same S/390
server can be internal storage connections, without the need to use external
links. Coupling connections between separate CECs can be Coupling Links,
Hiperlinks or Integrated Cluster Buses (ICB).

2.5 The hardware for S/390: CMOS processors available
S/390 CMOS processor technology has been implemented in three available
server platforms:
• 9672 servers
• Multiprise 2000
• S/390 Integrated Server
2.5.1 The S/390 9672 servers

This evolution and the features of this platform are described in 2.2, “S/390
CMOS design history” on page 14 and 2.3, “Availability and reliability of the
S/390 architecture” on page 15. Here, an overview of the currently available
server models are given in Figure 18 on page 32.
G5 G6 XZ7
ZZ7
ZY7
XY7
YX6 ZX7
XX7
Y96 Z97
X97
Y86 Z87
X87
Y76 Z77
RX6 X77
R96 Y66 X67 Z67
R86 Y56 X57 Z57
R76 Y46 X47 Z47
R66 Y36 X37 Z37
RD6 R56
RC6 R46 Y26 Z27
X27
R26 R36 Y16 Z17
X17
R16
G6 "Turbo" Models
T26 Glass Ceramic Glass Ceramic
RB6 G5 "Turbo" Models
T16 Substrate Substrate
RA6 Glass Ceramic MCU (Modular MCU (Modular
Substrate Cooling Unit) Cooling Unit)
Glass Ceramic MCU (Modular Cooling 14 PUs 14 PUs
Substrate Unit) Up to 12 CPs Up to 12 CPs
Alumina Ceramic 8/12 PUs 12 PUs 2 SAPs Standard 2 SAPs Standard
Substrate Up to 10 CPs Up to 10 CPs 5 - 32 GB Memory 5 - 32 GB Memory
6 PUs 8 - 24 GB Memory 1.8 ns Cycle time 1.57 ns Cycle time
2 - 24 GB Memory
Up to 4 CPs 2.0 ns Cycle time X17, X27 CBU only
2.4 ns Cycle time Z17- Z67 CBU only
1 - 12 GB Memory Y16, Y26 CBU only
2.6 ns Cycle time T16, T26 CBU only
Figure 18. IBM S/390 9672 G5/G6 Servers
There are 26 models of G5 and 24 models of G6 servers available. Together

with G5, there are 50 G5/G6 server models ranging from the RA6 with close
to 90 Million Instructions Per Second (MIPS) to the ZZ7 with more than 1600
MIPS. The server models are grouped in “towers” in which the models are
based on processors of the same cycle time. Upgrades within towers can
utilize the Capacity Upgrade on Demand feature for a non-disruptive
upgrades, but the models must take an outage to be upgraded to the next

tower. The entry models of each tower are available for Capacity BackUp
(CBU) only. There are no functional differences between G5 and G6, only
some feature variations. For example, a G6 has a standard alternate support
element, which is an optional feature on G5.
2.5.2 The S/390 Multiprise 2000

The S/390 Multiprise 2000 is a general purpose processor family for the
medium-sized S/390 enterprise. The system will run all the current S/390
operating systems in a standalone system environment. It is made with
CMOS technology which provides for outstanding environmental factors;
namely, reduced floor space, power consumption and cooling. Within the
processor frame, the customer can elect to purchase the Internal Disk feature
which puts advanced disk technology into a very compact processing
package. The Multiprise 2000 can run entirely with Internal Disk, entirely with
external DASD, or a mixture of the two, providing a very flexible solution.
There are 16 S/390 Multiprise 2000 models in the family. The 16 models
consist of eight uniprocessor models, three 2-way models, two 3-way models,
two 4-way models and a 5-way model. The models offer up to a 45-fold
growth from the Model 202 (about 4 MIPS) through the Model 257 (160
MIPS).
All S/390 Multiprise 2000 Models offer a wide range of features that allow the
system to operate in many different processing environments (see Figure 19
on page 34).

OSA-2 Reduced Cost of Computing
Internal Disk
Standard function Internal Disk
Ethernet, Token Ring, Environmentals Mirrored, cost-effective storage
FDDI, ATM Innovative Functions Space, energy, maintenance
Simplifies networking Packaged Offerings savings
Fast reads and writes
7 logical volume options
PR/SM
Up to 10 partitions Cyptographic Coprocessor Feature
Shared Channels,
network and disk storage
Enhanced Dynamic Hardware data security
Enhanced capabilities
Storage Reconfiguration Secure electronic
commerce
IT Without Boundaries
ESCON
Enables Year 2000
continuity Access to local/remote
Supports current and I/O devices
new applications Configuration flexibility
Up to 17 MB/second
Hardware Data Compression

Availability Internal Battery Feature
Up to 70% DASD storage
savings
Up to 70% communications Designed for HIGH 20 to 90 minutes full
availability holdup power
line utilization savings Redundant Power and Exploitation by Internal
cooling Disk Fast Write function
Concurrent maintenance
for critical parts
Figure 19. The S/390 Multiprise 2000
The OSA-2 attachment allows direct attachment of Ethernet, Token Ring,

Fiber Distributed Data Interface (FDDI) and Asynchronous Transfer Mode
(ATM) networks to the processor without external network interface
hardware/software. The Cryptographic Coprocessor feature allows security
function to be accomplished at hardware speeds in a very secure
environment, ideal for e-commerce over the Internet. The Internal Battery
Feature offers a backup processor power source in case of a utility power
failure. The Internal Battery Feature provides power for both the processor
and the Internal Disk. This feature is a requirement for using the Internal Disk
Fast Write function. To further enhance availability, numerous error detection,
retry/correction facilities and component redundancy have been designed into
the Multiprise systems to provide a high level of fault tolerance. Concurrent
maintenance is also provided for many components for which redundancy
exists (such as power supply and cooling elements, channels, and so on)
where the system can be repaired without affecting the end user's
productivity.
S/390 Multiprise 2000 is available in most countries via packaged offerings,

such as the highly popular Enterprise Server Offering (ESO). This offering
provides customers with their choice of hardware, software, services and

financing. This offering will encourage customers to easily upgrade their
operating systems and take advantage of new networking capabilities.
2.5.3 The S/390 Integrated Server

The S/390 Integrated Server is a low-cost offering that will be of particular
interest for customers running VM and VSE, but also supports MVS and
OS/390. This platform is ideal as a replacement for old S/370 and S/390
hardware such as all 9370s, 9221-170 models and below, most 43xx models,
and some 308x models. S/390 Integrated Server will be most useful if the I/O
bandwidth or speed of a S/390 Multiprise 2000 is not required.
The S/390 Integrated Server offers a wide variety of possibilities to serve

business needs, as shown in Figure 20.
Connectivity Reduced Cost of Computing Internal Disk

Industry standard I/O connections Entry Support License (ESL) 255 GB available
PCI and ISA I/O ports software pricing RAID 5
ESCON Channels Integrated Communications FBA, CKD, ECKD DASD
Access to local/remote I/O devices Emulation
Integrated I/O
Up to two channels
Up to 17 MB/sec Environmentals Concurrent maintenance
S/390 Parallel Channels Packaged Offerings Space, Energy,

Maintenance Savings
Attach tape, printer, terminals
Up to four channels
Local Area Network
Token ring and Fast Ethernet
SNA
Device Emulation
FBA, CKD, ECKD DASD
Tape and Printer
Network
Channels Environment
Standard Single Phase Power Available
IT without Boundaries
Redundant Power Generally available on
Year 2000 Ready November 12, 1998
Supports current and new Internal Battery Feature
applications Early Support shipments
N+1 Power in September, 1998
Application Isolation
Easy Installation 2X performance increase
256 MB Main Memory
Low Environmental Cost in 1999
Figure 20. The S/390 Integrated Server
The IBM S/390 Integrated Server contains a processor card with 256 MB of
integrated S/390 memory, internal SSA RAID-5 DASD, and the S/390
Licensed Internal Code that runs the full S/390 instruction set. Up to 13 PCI
I/O ports and 3 ISA slots can be used, and if more than the initially installed
36 GB of usable DASD is needed, the amount of SSA storage may be
increased up to 255 GB within the system unit. In addition to the SSA DASD,

S/390 ESCON and parallel channel adapters and a backup battery unit are
offered as features. For most workloads, this server provides performance
comparable to the 9221 Model 170.
Savings can be achieved in lower IBM maintenance costs on both the

processor and DASD, lower energy costs, lower connectivity costs, and lower
environmental costs. These potential benefits are derived from the integrated
disk characteristics with their high-reliability, low-power requirements, LAN
connectivity, and CMOS technologies.
2.6 The software for S/390: OS/390 and related products

In 1995, the development of OS/390 Version 1 began the transformation of
the world's most reliable operating system into an open server environment.
Through its family of releases, Version 1 reduced the complexity of
installation and management, simplified application development, and
lowered computing costs.
OS/390 Version 2 is an operating system with refinements in every area. It

integrates over 70 leading-edge elements and features, and continues to
evolve to provide industry-leading support for the applications demanded by
modern enterprises (see Figure 21 on page 37).

Batch
Job
UNIX Windows Web
VTAM TCP/IP
Transaction Manager
Batch
CICS TSO IMS TM
Appl Appl Appl Appl Appl ... Appl
IMS DB DB2 VSAM

Data Manager
Workload JES2/3 RACF DFSMS/ UNIX

Manager MVS Services
OS/390
S/390 Processor
Figure 21. OS/390, an integrated system
Its open environment and connectivity are fundamental. OS/390 Version 1

Release 2 was the first release to be UNIX branded in September 1996. The
OS/390 V2 operating system delivers full UNIX95 branding and functionality,
which means it can take advantage of the huge portfolio of existing UNIX
applications.The many engineers trained in a UNIX environment are now able
to write applications for OS/390 without retraining; the UNIX “look-and-feel” is
preserved at their workstations. In this environment, UNIX applications take
on a new strength, becoming much more robust and scalable than would be
possible in a distributed system.
A range of leading software technologies extends OS/390’s reach into

alternative environments. Windows NT applications can ported to OS/390
through the Wind/U tool from Bristol Technologies. Java holds great promise
for reducing development costs since it is independent of operating systems.
Java for OS/390 allows Internet or business applications to be written once
and distributed to many different platforms. Application development is also
streamlined with object-oriented programming tools using the Common
Object Request Broker Architecture (CORBA) interfaces. Component Broker

provides a new, business-oriented object programming model that reduces
the drudgery of repetitive programming tasks. OS/390 allows fast, easy
exploitation of the industry’s hottest enterprise-wide software applications,
including Oracle Applications, JD Edwards One World, People-Soft, Baan,
SAP R/3 and Lotus Domino. With Lotus Domino, up to 10,000 users can be
supported in the leading solution for groupware and collaborative computing.
Domino is also logical for building Internet-based applications using the
corporate database.
OS/390 Version 2 is an ideal platform for the integration and consolidation of

alternate server platforms under one umbrella. With the growing complexity
of multivendor, multiplatform, distributed client/server LANs, systems
management has become a serious drain on the resources of most IT
organizations. The integration of the Tivoli Framework, which will replace
SystemView, contributes a strategic, distributed management solution for
network computing. In addition, a broad spectrum of features facilitate server
consolidation while at the same time improving data access from client
desktops.
OS/390 handles more work than any other commercial operating system. In
its current iteration, it delivers a level of flexibility never before available to
large computing systems.
2.6.1 OS/390 packaging

OS/390 is a major advance in S/390 operating system packaging. It
completely replaces the base MVS operating system, which itself evolved
over a 20-year period. OS/390 delivers a set of integrated functions that
includes more than 70 base elements and features that were formerly offered
as separate products. This reduces the complexity associated with planning
and installing the operating system, and allows IBM to perform more
integrated testing of the complete system before delivery to the customer.
OS/390 continues the MVS tradition of S/390 hardware exploitation, provides
software support for Parallel Sysplex, Open Systems Adapter, and the
Cryptographic Coprocessor.
Version 2 of OS/390 represents a new base for electronic commerce and

enterprise computing. It continues the evolution of the S/390 Enterprise
Server operating system into the next decade. Some highlights of each
release are shown in Figure 22 on page 39, culminating in OS/390 V2.7,
which has been available since March 1999.

R7
Version 2
Software Technology Leadership R6
R5
Version 1 Systems Mgmt with
R4 Novell NDS* Tivoli
DFS Enhanced Support eNetwork CS
R3 DCE Enhancements Enhancements
WebSphere Application
R2 eNetwork Server
R1 DFSMS 1.5
BookServer Communications Server for OS/390
UNIX RAS &
DCE Application Firewall Technologies OS/390 NFS with Sun Ease-of-Use
Integration Support NFS V3
WLM DNS for Domino DFS RAS &
Security Server Domino Go Go Webserver for eNetwork Performance
Webserver for OS/390 OS/390 Communications Server
ServerPac Changes TCP/IP & UNIX
eNetwork Parallel Sysplex Enh Performance
ITAA Certified as Year Communications TCP/IP & UNIX
Security Server LDAP Security
2000 Ready starting Server Performance
with R2 Encina Toolkit UNIX Function and Cryptography
Security & Cryptography
Executive Performance enhancements
UNIX 95 enabled Component Broker*
ICSF OS/390 Print Server Parallel Sysplex
Parallel Sysplex Enh Parallel Sysplex Enhancements
JES2 & JES3 OSA/SF Enhancements
Enhancements
Object Technology Service Update Facility RMF, HCM Enhanced
Parallel Sysplex Enh OSA2 Enhancements
OS/390 Application Security Server OS/390 DFS
Enabling RMF, WLM, HCD
Simplified Planning, Enhancements
Enhanced
Secure Network Install, Test and Native ATM TCP/IP
Computing Maintenance Support
Native SNA ATM UNIX Function and
Performance
support
WLM Batch Mgmt.
Communications
Server
Figure 22. OS/390 continuing evolution
2.6.2 Systems management

All the S/390 technology solutions described in the preceding sections supply
important facilities to help achieve continuous availability, but it can be argued
that systems management is the most important factor in achieving this goal.
Systems management is a set of applications required to run a computer

complex. They represent the manual processes and procedures that have
gradually been moved online to be self-managed by the IT environment. If
there are weaknesses in this area, continuous availability will not be achieved
by purchasing new technology alone. Systems management underpins all
efforts to meet availability targets.
The foundation for good systems management is designed into OS/390 and
its optional elements. OS/390 contains several key components that provide
facilities for the additional systems management products to connect to and
interact with. Chapter 4., “Systems management” on page 71 provides a
detailed discussion of the system management components on S/390.

2.6.3 Backup and recovery
Any professional IT organization is only too aware of the need to take
backups and store copies off site. Facilities must be in place to cater for such
things as:
• Data loss due to hardware failure
• Data corruption due to hardware, software, application or end-user errors
• Malicious damage
• A disaster such as fire, flood or explosion
Backup copies of the data are usually produced at night when all applications
using this data are stopped. This usually results in an application outage. If
the data is corrupted, this corruption can be passed to the backup copies.
With increasing volumes of data and demands to provide 24-hour a day,
365-day a year service, new approaches to backup and recovery are
required.
The S/390 platform is renowned for its continuous availability features. In this
section the capabilities of S/390 regarding backup and recovery are
discussed.
2.6.3.1 Remote Copy and Geographical Dispersed Parallel Sysplex

As described in 2.3, “Availability and reliability of the S/390 architecture” on
page 15, today’s DASD subsystems are based on RAID implementations
which reduce the possibility of data corruption due to hard drive failure. The
RAMAC Virtual Array (RVA) additionally has a unique feature called
SnapShot. SnapShot allows a virtually instantaneous copy of data sets or
volumes to be made by copying pointer tables within the RVA which avoids
real data movement. The time taken to perform backup and copy functions is
drastically reduced. A second, not so obvious benefit is that the copy takes
up no real space on the RVA. SnapShot creates independent views of the
data. It can be used to take a point-in-time copy which can be dumped to tape
at an appropriate time, while the original is used for normal business
processing. Using SnapShot in this way provides an immediate business
benefit by reducing the batch window.
Another significant S/390 facility for disk storage is Peer-to-Peer Remote

Copy (PPRC). This function allows multiple identical copies of selected
volumes or data sets to be held behind different disk control units. The
copying and synchronization is performed by the disk control unit and so
avoids any extra processing on the S/390 server. In the event of a failure,
switching from one volume to the other is totally transparent to the system.

This remote copy function can be extended across locations. This function is
of special significance when a Parallel Sysplex is extended across two
geographic locations. Such a configuration is termed a Geographically
Dispersed Parallel Sysplex (GDPS). As shown in Figure 23, the coupling
facility, Sysplex Timer and dual copy links are cross-connected to provide a
single systems image with full disaster recovery capability.
Site A Site B
Local copy and remote copy Local copy and remote copy
Figure 23. Geographically Dispersed Parallel Sysplex (GDPS)
Naturally the implementation of PPRC and GDPS prevents only the

destruction of data in case of a disaster or a hardware failure. If the data is
logically damaged, for example by an application malfunction or a user error,
the remote copy will also be corrupted. Therefore, additionally logical
backups of the data are required, which have been taken before the data has
been corrupted. In addition, procedures to reproduce the changes to this data
since the last backup are necessary.
2.6.3.2 DFSMS
The simplest way to get a logical backup copy of data is to run a job that just
copies the data to tape. However, in a complex enterprise computing
environment, it is impossible to implement backup procedures based on this
methodology. The packaging of OS/390 contains a product that enables the
automation and centralization of storage management. The Data Facility
Storage Management Subsystem (DFSMS) is the key to system managed
storage in an OS/390 environment.

One component of DFSMS is the DFSMS Hierarchical Storage Manager
(DFSMShsm). One of its functions is to back up the data, automatically or by
command, to ensure availability in the event of accidental loss of data sets or
physical loss of volumes. DFSMShsm also allows the storage administrator to
copy backup and migration tapes, and to specify that copies be made in
parallel with the original. The copies can be stored on site as protection from
media damage, or off site as protection from site damage. Disaster backup
and recovery is also provided for user-defined groups of data sets, so that
critical applications can be restored at the same location or at an off-site
location.
2.6.3.3 Database subsystems backup and recovery

Database subsystems such as IMS, DB2 and native VSAM databases,
usually have ongoing demands to backup and recover their data. From the
DFSMS point of view, a database just is a file or set of files from which a
backup copy can be produced. Since some databases are huge, copying the
entire database is not practical.
Many database applications depend on their data being open for update over
a long period of time. Normally a backup of the data cannot be made while it
is open, so the application has to be closed during the backup process.
To prevent the applications from scheduled outages due to frequent backups,

database subsystems offer capabilities to copy the data while it is open.
These backups are complemented with logs which contain updates since the
last backup copy was made. The recovery procedures require the use of the
latest backup and the log data.
CICS supports the Backup-While-Open (BWO) facility, which together with

other system facilities and products, allows you to take a backup copy of a
VSAM data set while it remains open for update. Then, only the updates that
have been made since the last backup copy was taken need to be recovered.
This could considerably reduce the amount of forward recovery that is
needed.
The backup and recovery mechanisms of IMS depend on the production of

checkpoints, in which it records the current status of the system. These are
points at which the work done by the application is assumed to be complete,
and which function as a setup point for recovery activities. The image copies
of the database can be produced concurrently, and every transaction is
recorded in an Online Log Data Set (OLDS). Recovery can be performed as
forward recovery, where the database is reconstructed from an image copy
and the logs, and as backward recovery, where the system tries to remove
incorrect or unwanted changes from information. The IMS Database

Recovery Control (DBRC) facility allows an easier recovery of IMS
databases.
The copy utility of DB2 can be used to produce a copy of the data, while the
applications continue to read and write the data. Also DB2 provides a
common log to record data changes for all activities running in the DB2
subsystem. Recovery is done with an image copy, complemented by log
records.
2.6.3.4 Tivoli ADSM

The concept of system managed storage can be enhanced to distributed data
by ADSM, which is described in more detail in 5.4.4, “Data backup and
recovery - Tivoli ADSM” on page 114. ADSM supports a wide variety of IBM
and non-IBM platforms for both small and large systems, providing data
backup and recovery, archival and space management functions.
Leaving the protection of critical data to individual users does not necessarily
guarantee that data will be consistently backed up or that backup versions will
be stored in a safe place. The truth of the matter is that end users often view
backing up their data as a nonproductive task that frequently gets put off for
another day. What is more, if users do back up their own data, recovering it
can be more labor intensive and time-consuming than they would prefer.
When data is lost, the impact can be severe and sometimes devastating.
Under these circumstances, users should not have to spend unnecessary
time searching through diskettes and tapes trying to locate the correct
version of data they need to recover. With some backup solutions, users may
find the recovery process more difficult and labor intensive than the actual
backup process itself. Tivoli ADSM addresses these issues.
2.6.4 Security
Security is a classic strength of IBM S/390. It includes an integrated suite of
security functions that provide centralized management, enhanced
performance and greater safeguards for network, system and transaction
security.
2.6.4.1 Network security

Network security provides a line of defense against unauthorized users who
try to gain access to information or even control machines on a private
network. A common form of protection in this case is called a “firewall,” which
allows communications between private and public networks to be monitored
and secured. OS/390 has native firewall technology that is simpler and less
expensive to manage than a standalone firewall server. It permits S/390 to be

linked securely to the Internet, and also permits companies to use the
Internet as a Virtual Private Network (VPN), a secure link in the corporate
network or extranet.
2.6.4.2 System security

System security is used to control access to files, programs, data - anything
that resides on a server or back-end system. Access to these resources is
controlled by User IDs and passwords. System security starts with the
integrity of the operating system. One of the critical designs points for OS/390
is security. There are Statements of System Integrity for MVS which have
been extended to OS/390.
Under OS/390, “jobs” or “tasks” cannot be started unless properly

authenticated. In addition, OS/390 protects each application task from others
such that one program cannot corrupt another program’s private storage or
data. Resource protection managers like Resource Access Control Facility
(RACF), a feature of OS/390’s Security Server, are used to protect the system
authorization libraries from unauthorized access. OS/390 Security Server
makes S/390 and OS/390 one of the most secure environments from which to
conduct electronic commerce.
2.6.4.3 Transaction security

Transaction security is fundamental to e-business. Transaction security refers
to the ability of two entities on the Internet (or intranet/extranet) to conduct a
transaction privately and with authentication. If required, certain transactions
can be secured with digital signatures.
To perform secure electronic commerce, messages containing sensitive

information or requiring client/server authentication will require the use of
public-key cryptography algorithms. This could have an impact on processor
performance because, in most servers, encryption and decryption is done in
software. S/390 CMOS servers address this issue by performing the
cryptographic functions using an exclusive specialized hardware assisted
feature called the Cryptographic Coprocessor, where public-key algorithms
are executed. As a result the main processors are freed to concentrate on
other application functions.
Using the Cryptographic Coprocessor feature coupled with OS/390 Security

Server provides a significantly higher level of security when validating that
users and applications have legitimate access to cryptographic services and
keys. This higher level of security is required for standard services such as
the Triple DES used by banks and other financial institutions, and the

Visa/MasterCard Secure Electronic Transaction (SET) payment gateway for
electronic commerce.
2.6.5 Available databases solutions

Traditional applications on large scale servers are usually based on the large
OS/390 database management systems IMS DB, DB2 or native VSAM and
the corresponding transaction management systems IMS TM and CICS.
Since they are OS/390 subsystems running on a S/390 server, these
applications are able to exploit all the advantages the design of the S/390
architecture offers, as described in the preceding sections. Even ongoing
capabilities to use the continuous availability features of S/390 have been
implemented into the database and transaction management systems.
Examples are the ability of producing backup copies of databases while they
are open for update (as described in 2.6.3.3, “Database subsystems backup
and recovery” on page 42), and the various features of DB2, IMS and CICS to
exploit the Parallel Sysplex infrastructure, in order to balance workload and
share databases.
These very mature database and transaction management subsystems,

tightly integrated into the S/390 architecture and participating in all the
advantages of this technology, make S/390 the most superior platform for
managing database applications. In fact, most of the huge databases of large
customers are already residing on S/390, feeding their vital applications for
many years. New applications such as data warehousing require reliable
databases and transaction management systems with the ability to handle
huge workloads and data.
A logical question that arises with the combination of S/390 and a UNIX
environment is: How can I use my superior S/390 databases with new
Web-based applications, developed in object-oriented languages and UNIX
tools? The answer has already been provided by OS/390, which contains a
convenient set of interfaces, connectors and gateways for Web-based
applications. These connectors and gateways are shown in Figure 24 on
page 46.

Net.Data
for OS/390
CICS Connectors
for S/390
IMS Connectors
for S/390
Internet MQSeries
Internet Gateway
AIF
Internet Gateway
JAVA
Internet Gateway
Domino
Connectors
Figure 24. e-business connectors and gateways for OS/390
Furthermore, the traditional UNIX database systems like Oracle have been,
or are able to be, ported to OS/390 UNIX, but these applications do not have
as powerful continuous availability features as the mature S/390 database
and transaction management systems.
2.6.6 UNIX System Services

Beginning with MVS/ESA Version 4.3, UNIX System Services were added to
the MVS platform. The definitions are known by the name POSIX, which
stands for Portable Operating System Interfaces – UNIX. They include both a
C programming API and an interactive environment that is referred to as the
shell . POSIX was taken further by The Open Group, now the brand owners of
the term UNIX.
The Open Group's standards are published in X/Open Portability Guides

(XPG). All these definitions describe what to implement, not how to
implement. The MVS designers took these standards and modeled UNIX
System Services after them. OpenEdition was previously the name given to
the MVS implementation and is made in such a way that UNIX functions

coexist with traditional MVS functions. What was called OpenEdition is now
referred to by the more meaningful title of UNIX System Services for OS/390.
For brevity, it will be referred to as OS/390 UNIX. These functions and many
others are packaged together in the base OS/390 system which also includes
TCP/IP, the prime network communications protocol; see Figure 25.
Full UNIX
branding
MVS Datasets
hierarchical databases
files
Std
rlogin UNIX*
telnet S/390
nfs
TCP/IP
ftp and
tn3270 SNA
Figure 25. OS/390 full UNIX branding
UNIX applications rely on the existence of a Hierarchical File System (HFS)

which is described in the section that follows. An example of an UNIX
services application is the OS/390 Web server, the WepSphere Application
Server. The UNIX file system structure is unlike MVS where most data is held
in record format and where applications access specific records rather than
offsets in a byte stream. Conventional S/390 file structures are not
hierarchical. Access to a data set in MVS is done via a catalog entry and
there is no concept of a directory in the PC or UNIX sense.
HFS file systems are implemented in OS/390 like any other data structure
using the DFP component of DFSMS/MVS. The HFS is made up from
multiple MVS data sets, of type=HFS, and are allocated in the standard
manner. During OS/390 UNIX initialization, these datasets are linked together
in a logical hierarchy. Each HFS is a mountable file system. The root file
system is the first file system mounted. Subsequent file systems can be
mounted on any directory within the root file system or on a directory within
any mounted file system.

2.6.7 New workloads
OS/390 UNIX offers the advantages of the mature S/390 architecture to all
the applications developed to run on UNIX servers. The evolution of OS/390
is steadily improving the architecture and the application development
features of OS/390 UNIX. Some examples of major improvements to OS/390
UNIX are the implementation and increased performance of TCP/IP and the
HFS. Also the ability to measure, report on, and manage the OS/390 UNIX
workload have been enhanced. Finally, the functionality of the WebSphere
Application Server has been expanded.
With this in mind, new applications should be developed in a

platform-independent way, in order to choose the platform most appropriate
to the business requirements. If the size and the importance of the application
is growing beyond certain limits, S/390 will be a natural target platform.
Applications that have been developed especially for UNIX or NT can be

ported to OS/390 UNIX. Various tools and services available are described in
5.2, “Porting applications to OS/390” on page 87.
The most interesting applications running on OS/390 surely are professional

business applications, because this species has a determined need for
continuous availability. Some of them have been developed as multitier
applications, so they historically used to reside on non-S/390 platforms. Now
that OS/390 has become a UNIX server, the vendors ported the central parts
of these applications onto OS/390. Examples are SAP R/3 and Lotus
Domino. These applications and their implementation into OS/390 are
covered in 5.3, “Distributed business applications” on page 92.
2.7 Networking and connectivity

S/390 offers a wide range of network connectivity solutions, embracing the
traditional System Network Architecture (SNA) as well as leading the way in
the new technology areas like TCP/IP Gigabit Ethernet and Fibre Channel
architecture.
These topics and more are discussed in more detail Chapter 3, “Networking
and connectivity” on page 59.
2.8 Future directions

Today’s IT world is rapidly evolving and discussions of future trends and
directions are common. Open source software like LINUX has entered the
marketplace and is expected to gain significantly. Applications tend to be

developed in an object-oriented and component-based way, being
platform-independent and designed for a distributed computing environment.
The amount of data being stored, processed and moved over networks has
multiplied rapidly, challenging the whole IT infrastructure.
The key of all this developments in the coming years is the way in which all
the applications, all the data and all the technologies in the enterprise work
together. The hardware has to be connected and managed, while the
applications should be able to exploit all the resources.
In the following sections, the IBM strategy for Storage Area Networks (SAN)
and the related technologies and already available products is discussed.
2.8.1 Storage Area Network (SAN)

As the Storage Networking Industry Association (SNIA) has defined, a
Storage Area Network is “a dedicated high-speed network of directly
connected storage elements designed to move large amounts of data
between host independent, distributed storage devices”. SANs are based on
a “fabric” of Fibre Channel (FC) hubs, switches and gateways connecting
storage devices and servers on a many-to-many basis. Application and
transaction servers are attached to both the SAN and to Local Area Networks
(LANs) or Wide Area Networks (WANs), creating what appears to be a
massive pool of data. This is illustrated in Figure 26 on page 50.

Local Area Network
Storage Area Network
Figure 26. Interrelationship of LAN and Storage Area Network (SAN)
SANs can be configured to provide servers in different locations with direct

access to huge amounts of shared storage resources. A SAN also can enable
direct storage-to-storage connectivity, for example between multiple disk
arrays or between a disk array and a tape library, allowing management
activities such as backups and archiving to take place independent of any
server.
Inherent in the promise of SANs are two compelling advantages. The first is
the creation of a true information utility. By eliminating the one-to-one
relationship between individual servers and critical business data to create a
corporate information “bank”, a SAN can make that information readily
available across the enterprise. The second advantage is that a SAN can
provide a faster, more effective way to deal with rapidly increasing volumes of
information. With a separate information management network, additional
capacity can be “plugged in” as needed with minimal impact on the
performance of application or transaction servers, LANs or WANs.
SANs promise more responsive and robust systems, as well. For example, by
reducing the amount of traffic that must travel along corporate networks,
installing a SAN has the effect of increasing available bandwidth. The result

are response times that are well-matched to the requirements of e-business.
Performance is further enhanced by improved backup and recovery
capabilities. With a SAN, backup and recovery can take place without
involving either the existing LAN or WAN or individual application or
transaction servers. In addition, with information no longer tied to any one
server in particular, failure of a single server is less likely to degrade
information availability. SANs will support advanced multiserver clustering
solutions for new levels of information availability and business continuity.
And SANs permit near-real-time updates of remote disaster recovery sites for
higher levels of disaster tolerance. Management also is greatly simplified. A
SAN permits the use of a common set of tools and a single point of control to
manage a centralized pool of information.
SANs have been available in the S/390 world for years. In fact, IBM has been
in the SAN game since 1991 when it introduced the first generation storage
network, ESCON, a serial, fiber optical, point-to-point switched network
connecting disk, tape, and printing devices to MVS hosts. Although its initial
entry into the market was as a high-end solution, ESCON has responded to
customer demands for open connectivity and has matured to become truly
heterogeneous, supporting either native ESCON attachment or ESCON
attachment via converters or gateways to multiple systems, including UNIX
servers from IBM, HP, Sun, DEC and Sequent as well as Windows NT
platforms. Today, IBM is aggressively working with the industry to use its
years of experience and expertise in first generation SAN technology and
SAN management in the S/390 world to deliver the second generation SAN,
enabling all the benefits of a switched network topology in today’s open
environment.
IBM believes that SAN technology will evolve over three major phases (see
Figure 27 on page 52):
• Phase 1: SAN-attached storage. The focus will be on connectivity.
• Phase 2: SAN optimized storage. This phase will begin to exploit the SAN
characteristics and deliver early SAN solutions.
• Phase 3: SAN optimized systems. The maturity of the technology will be
used and system-wide solutions will be delivered.

SAN Optimized Systems
Shared file systems
SAN Optimized Storage SAN based storage management
Advanced SAN solutions, Benefits include:
SAN-Attached Storage including disk/tape pooling, high Transparent data access
availability clustering and so on Heterogenous true date sharing
No functional change in storage
subsystems Storage-to-storage data copy and Challenges include:
Advanced Functions
movement for remote copy, Interoperability
FC attachment via gateways and instant copy, data migration,
native adapters Heterogenous operating
LAN-less backup systems, RDMS standards
Box-level SAN management and
Extended fabric management Application software to exploit
reporting
Benefits include: potential
Simple SAN solutions
Improved data movement Security issues
Hubs and switches
performance
All building blocks functional
Storage servers exploit Fibre
Benefits include: Channel connectivity
Fewer adapters and cables Reduced server processing
Extended adressing and workload for storage
distance Standardization of storage
Greatest benefits in area of processing
SCSI replacement
service offerings: multi-vendor, best-of-breed solutions

consulting .. planning .. design .. integration .. testing .. qualification
time
Figure 27. IBM Storage Area Network roadmap
Understanding that every business has unique requirements, and recognizing

that investment protection and minimization of operational disruption and risk
are key factors influencing an organization’s purchase decision, IBM has
defined a strategy that:
• Uses current investments in hardware, software, and people skills
• Enables the integration of new technologies as they emerge, mature, and
become more affordable by deploying a building block infrastructure
• Applies experience and lessons learned from the mainframe arena, like
systems managed storage concepts and switched fabric management, to
the open systems environment
• Supports multiplatform, multivendor interoperability
• Minimizes the risks of unproven technology by providing a business the
ultimate “mix and match” freedom of choice to deploy what makes most
sense for its unique environment

IBM’s SAN strategy is intended to deliver technology, support, consulting
services and education throughout the entire SAN solution life cycle. Five
basic initiatives form the cornerstones of this strategy:
Hardware To get the fullest benefit from SANs, the hardware base has
to be SAN-aware and provide SAN-enabled, native
attachment. IBM plans to provide a full range of
SAN-enabled hardware as well as “bridges” that will permit
organizations to leverage existing hardware as they move
toward SAN implementation.
Connectivity Because few businesses can afford to implement a
complete replacement strategy, IBM has taken investment
protection and seamless migration as essential SAN design
points. Therefore, IBM intends to complement its current
storage, server, network and software product lines with a
full set of SAN-enabled products to meet specific business
needs, from fabric components like gateways, hubs and
switches to native Fibre Channel attached disk and tape
storage devices.
Management In the same way, a SAN management infrastructure must be
able to accommodate both existing and evolving systems
incorporating products from IBM and other storage vendors
such as EMC and Hitachi Data systems.
Exploitation The true value of SAN is not the specific set of technologies,
but rather the software functions that use the technologies
and provide business value. In its role as solution provider,
IBM will exploit SAN technology to deliver a set of business
solutions that address today's most pressing IT problems,
like tape and disk pooling, copy services, and high
availability clustering.
Support SAN's promise of any-to-any connectivity and the
complexity it introduces highlight the critical nature of both
system integration and service in any SAN strategy. As one
of the industry's leading service providers, IBM Global
Services can provide the support, services and education
required to support end-to-end SAN solutions.
Many SAN-enabled solutions have already been announced or are available,

while other available products have been enhanced according to this
strategy. The implementation of the Fibre Channel technology into the S/390
architecture is FICON (discussed in 2.8.2, “FIber CONnection (FICON)” on
page 54), the new IBM storage products are based on the Seascape

Architecture (see 2.8.3, “The Seascape architecture” on page 55), and
various connectivity products like SAN FC switches, gateways and routers
are available. Tivoli ADSM has announced support and exploitation of SAN
technology. Another critical component is StorWatch, a growing software
family that enables administrators to efficiently manage storage and fabric
devices from any location within the enterprise.
The role of the S/390 servers in this SAN architecture is quite obvious: it
should be the heart of the SAN. S/390 offers the most secure, reliable,
manageable and scalable platform in a SAN, so it is logical choice to run
mission-critical business applications. The classical strength of S/390 can be
used to manage the data flow in the SAN in the most effective way. The
enhanced connectivity and interoperability offered by a SAN enhances the
importance of S/390 acting as an open server.
2.8.2 FIber CONnection (FICON)

Although Fibre Channel is the clear SAN technology of choice, there are
storage networks in production today that use available, non-FC
technologies, such as ESCON. They deliver many of the benefits of a SAN
deployment using proven, mature technology, and provide a migration path to
Fibre Channel as it evolves. In addition, bridges and gateways are being
delivered to the market that allow connection of existing resources to a SAN
FC fabric, providing customers FC migration paths.
The S/390 G5 and G6 systems now have a new high bandwidth channel type
based on FC technology, called FICON (FIber CONnection), as described in
3.3, “FIbre CONnectivity (FICON) channel” on page 61. FICON uses a new
mapping protocol that is intended to take full advantage of the unique
characteristics of the Fibre Channel standard, and to insure a seamless level
of compatibility with the existing Fibre Channel component infrastructure.
The new FICON channels allow ore efficient and faster data transfer, while at
the same time allowing customers to use their currently installed single mode
and multimode fiber cables. The FICON attachment will be implemented in
three phases, as illustrated in Figure 28 on page 55. In the first phase, the
9032 Model 005 Director supports FICON through the use of a FICON bridge
card and is intended to provide investment protection for currently installed
ESCON control units, which are enabled to exploit the FICON channel
without any changes.

FICON Bridge Connections:
ESCON
FICON CU
S/390 9032-5
Channel
with ESCON Exploit FICON Channel with
G5/G6 FICON CU
Servers Bridge existing ESCON Control Units
ESCON
CU
Native FICON Direct Attachment: Statement of Direction

S/390 FICON
Channel
G5/G6 FICON
CU
Native FICON Control Units
Servers
Native FICON Switched Connectivity: Statement of Direction
FICON
CU
S/390
G5/G6 FICON Full Dynamic Switching of FICON
Switch
Servers Control Units
FICON
CU
Figure 28. FICON attachment
The next implementation is a native FICON direct attachment whereby the

FICON channel will be plugged directly into a native FICON control unit. In
July 1999, this attachment was announced as a preview both to the Magstar
3590 tape control unit and to the Enterprise Storage Server. Other storage
control units, IBM as well as non-IBM, are expected to follow soon.
The next Statement Of Direction (SOD) is for FICON switch connectivity. IBM
will provide a new FICON Switch that will enable full dynamic switching of a
FICON control unit between multiple channels, as well as between multiple
FICON control units connected to a single channel.
2.8.3 The Seascape architecture

The Seascape architecture is the key to the development of IBM’s SAN
enabled storage products. Seascape allows IBM to take the best of the
technologies developed by the IBM laboratories and integrate them to
produce flexible and upgradable storage solutions, technologies such as the
PowerPC, the Magstar Tape drives and the Ultrastar disk drives. Seascape
offers the ability to exploit new technologies quickly, such as Fibre Channel
and S/390 FICON.

IBM has already delivered Seascape solutions with the Virtual Tape Server,
the Network Storage Manager and the Web Cache Manager. The Versatile
Storage Server (VSS) was the first of the Seascape disk servers. In July
1999, the Enterprise Storage Server (ESS) was announced. It provides all the
functions of the VSS, now complemented with S/390 attachment, and takes
advantage of the Seascape architecture’s flexibility to upgrade and replace
components easily and quickly.
A serial interconnect technology, the Serial Storage Architecture (SSA), is

used within the Seascape architecture to connect the processors and internal
disks to ensure high performance and availability. This is shown in Figure 29.
SSA Device
Adapter
Figure 29. Serial Storage Architecture
SSA is a high-performance, serial connection technology for disk drives. It is

based on a full-duplex loop, with two physical read paths and two physical
write paths to every disk attached to the loop. Data is sent from the adapter
card to the first disk on the loop and then passed around the loop by the disks
until it arrives at the target disk. Unlike bus-based designs, which reserve the
whole bus for data transfer, SSA only uses the part of the loop between
adjacent disks for data transfer. As a consequence, many simultaneous data
transfers can take place on an SSA loop. This is one of the main reasons that
SSA performs so much better than SCSI. In the SSA160 implementation, for
example used in the ESS, the read or write path on the loop operates at 40
MB/s, providing a total loop bandwidth of 160 MB/s.
If the loop breaks for any reason, then the adapter card will automatically
reconfigure the loop into two single loops. In the ESS, the most likely
scenario for a broken loop is if the actual disk drive interface electronics
should fail. If this should happen, the adapter card will dynamically
reconfigure the loop into two single loops, effectively isolating the failed disk.
If the disk were part of a RAID array, the adapter card would automatically
regenerate the missing disk using the remaining data and parity disks to the

spare disk. Once the failed disk has been replaced, the loop will automatically
be re configured into full duplex operation, and the replaced disk will become
a new spare.
SSA does not change disk technology, it changes the storage paradigm. In
essence, it changes the communications infrastructure of disk subsystems,
allowing them to transfer more information to and from hosts in a substantially
more efficient manner, at lower cost, over wider distances, with greater
configuration flexibility than ever before.

Chapter 3. Networking and connectivity
S/390 has been recognized as the leading System Network Architecture

(SNA) network provider for many years. However, in the past, IBM has not
been seen as a major player in the multi-protocol areas, especially TCP/IP.
This situation is now changing with eNetwork Communications Server for
OS/390 adding dramatic improvements to the TCP/IP stack and associated
clients and servers. The availability of much improved multi-protocol host
gateway products, such as OSA-2 and OSA Express, the 3746-9x0 and the
2216 is also improving IBM’s offerings.
IBM has a range of products for all areas of networking such as IP routing
with the IBM 2210s, LAN switching with IBM 827xs and an expanding range
of ATM products.
IBM networking and communications software and hardware provide the

infrastructure necessary for secure, reliable corporate intranets and
extranets; see Figure 30.
TCP/IP comms
OSA (integrated adapter)
3746 (communications
controller)
3172 (interconnect controller)
2216 (channel attached router)
RS/6000 (channel attached)
Direct Channel
FICON (Fibre
Connections)
ESCON
MMC (MCA ESCON) card
SNA comms
OSA (integrated adapter)
PCI-ESCON
3745/6 (communications
Parallel
controller)
3172 (interconnect controller)
2216 (channel attached router)
RS/6000 (channel attached)
3174 (cluster controller)
Figure 30. S/390 Server connectivity options

In this chapter we look into some of the more recent developments and
enhancements.
3.1 TCP/IP
TCP/IP is a communications protocol specifically designed for the Internet.
What can confuse people is that most providers of TCP/IP (UNIX, NetWare,
Windows NT, OS/2, OS/390, VM and others) also include a standard set of
TCP/IP applications. When people talk about TCP/IP, it generally includes the
protocol and these standard applications. The applications generally include
both client and server components. Some of the more well-known
applications are as follows:
• Domain Naming System (DNS) allows the use of names rather than dotted
decimal IP addresses.
• File Transfer Program/Protocol (FTP) is a facility to transfer files between
TCP/IP systems.
• Telnet allows a user to login and work on a remote system. A common
variant of Telnet when connecting to S/390 systems is TN3270 which
provides a full screen 3270 session, although it can also connect as a
line-mode terminal.
• Network File System (NFS) -allows transparent access to files on a remote
system.
• X-Windows is a windowing system that provides simultaneous views of
several executing programs or processes on bit-mapped displays.
The original version of TCP/IP for MVS was ported from a VM

implementation. However, IBM's TCP/IP for OS/390 has been completely
rewritten and now offers significant improvements in performance and
function. TCP/IP is a part of Communications Server for OS/390 which is the
combination of VTAM, TCP/IP and AnyNet and is shipped as part of OS/390.
Native TCP/IP support is also available for VM/ESA, and more recently for
VSE/ESA.
3.2 ESCON
ESCON, also called serial I/O interface, is a type of channel path that allows
attachment of one or more control units to an S/390 channel subsystem by
using optical fiber links and provides protocols required for information
transfer over that channel path. See Figure 31 on page 61.

It provides bidirectional serial bit transmission, in which the communication
protocol is implemented through sequences of special characters and
through formatted frames of characters.
CU
ESCON Channels
10 MB/sec --> 17 MB/sec Data CU
transfer Rate ESCON CU

3 km maximum without re-drive
26 km/16.2 miles maximum CU
distance Parallel
(requires 2 Directors with XDF CU
Features)
CU
43 km/26.7 miles with 9729
Wavelength Division Multiplexer CU
Switched Point-to-Point Topology -
Connectivity CU
ESCON Multiple Image Facility

(EMIF) Parallel Channels
2 Paths per CPC per CU 1.5 MB/sec --> 4.5
System Automation for OS/390 MB/sec
0.12 km/400 ft maximum
distance
2 Paths per image per
CU
Disruptive Change
Management
Limited connectivity
Figure 31. ESCON and Parallel architecture
Parallel channels use copper-based cable and are not easy to work with due
to their size and weight. The future is moving towards fiber-based technology
and the phasing out of the use of parallel channels.
3.3 FIbre CONnectivity (FICON) channel

When compared to ESCON channels, the new FICON channels can provide
customers with significant improved I/O capacity by efficiently combining a
new, high performance architecture with faster physical link rates; see Figure
32 on page 62.
Networking and connectivity 61

Up to 24 FICON channels
17 MB/s ESCON
Bandwidth increased Link CU
100 MB/s
FICON 100 MB/s vs. 17 MB/s Full Duplex
..
on ESCON ESCD
.
Link
FICON 9032 ESCON
Model
1 FICON equivalent up to FICON
5 CU
...
8 ESCON channels Bridge
Card
ESCON
Patchcable for existing ESCON CU
infrastructure FICON
Reduced cabling complexity

FICON control units and FICON director (SOD)
Figure 32. Fibre CONnectivity channel I/O Architecture
Over the last decade ESCON has been delivering to S/390 customers
increased distance, reduced cable bulk, disk and tape pooling, clustering and
data sharing, while providing sophisticated management. Numerous other
vendor systems also support ESCON, which was adopted as a national
standard in 1996 by NCITS. FICON is based on NCITS Fibre Channel
standards and therefore S/390 is positioned for full participation in
heterogeneous fiber channel-based SANs in the future.
FICON can coexist with current channels in any model G5, G6 or follow-on
server. It is designed to support 100 MB/s bi-directional data transfer rates
compared to ESCON's 17 MB/s unidirectional throughput at distances of up
to 20 kilometers over fiber-optic cables.
The initial FICON implementation attaches existing ESCON devices, via the
FICON Bridge, with each FICON channel supporting up to eight ESCON
channels. Native FICON devices permitting direct attachment to servers will
follow.
In addition to enhanced performance and channel limitation relief, the move

to FICON will reduce complexity by simplifying cabling requirements and will
therefore also increase ease of use.

3.4 Open Systems Adapter (OSA)
The first generation of OSA adapters was announced in November of 1994,
and started rolling out in the first quarter of 1995. The goal of OSA is to
provide an open, industry-standard Local Area Network (LAN) interface,
creating a common package that could be used in the bipolar processors
(9021-711 and 9121-511) as well as the first generation of CMOS, 9672 R1
models.
The OSA is a fully integrated, S/390 hardware feature which is now available
on the entire IBM 9672 R2 and R3 range up to the IBM G6 and Multiprise
2000 CMOS processors see Figure 33.
ES/9000 511/711 9672/R2-R5

9672-G5+
9672-R1 G5 (R6)
OSA OSA
OSA-1 OSA-2 Express Express
Future ?
1Q 1995 10-95 Token-Ring 06-99 GA 4/16/100 TR
Token-Ring 10-95 Ethernet Gigabit Ethernet 622 ATM
Ethernet 10-95 FDDI SOD:
FDDI 09-96 155 ATM Fast Ethernet
09-96 OSA-2 Standard 155 ATM
97 ATM Enhancements
97 SNA Enhancements
97 VSE support
04-98 Fast Ethernet
Figure 33. OSA evolution
3.4.1 OSA-2
Current LAN-to-host gateway boxes consist of a control unit function (engine)
with one or more LAN adapters and one or more channel adapters. The LAN
adapters may be Token-Ring, Ethernet or FDDI. The channel adapters may
support either parallel or ESCON channel links.

Each OSA-2 feature is a unique type of I/O channel which is equivalent to an
ESCON channel and a gateway control unit with one or more LAN adapters.
As it is attached directly to the processor channel bus (channel subsystem),
the OSA offers high performance together with the high availability and
maintenance characteristics of the S/390 platform.
3.4.1.1 Types of OSA-2 cards

Five different OSA-2 cards are currently available: an FDDI card; an ENTR
card which supports both Token-Ring and Ethernet; an ATM card for
single-mode fiber; an ATM card for multimode fiber; a Fast Ethernet 10/100
Mbps card.
Each OSA-2 option is a single card. This card plugs into an I/O channel slot
and takes on the first channel number associated with that slot. The
Multiprise 2000 can take up to six OSA-2 cards and all other supported
processors can take up to 12. The OSA-2 cards can be of any mix of the five
types; see Figure 34 on page 65.
FDDI The FDDI card has one LAN port that can be attached to a
100 Mbps FDDI LAN. The LAN must conform to either the
ANSI X3T9.5 specification or the ISO 9314 specification. The
FDDI card has three connectors; two are for the primary and
secondary LAN connections; the third is for an optical bypass
switch.
ENTR An ENTR card has two ports, which is equivalent to having
two LAN adapters. On the OSA-2 card, the two ports are one
below the other. Each port has three connectors which can
attach to a 10 Mb/s Ethernet LAN or a 4 or 16 Mb/s
Token-Ring LAN. So, with a single ENTR OSA-2 channel, two
Token-Ring, two Ethernet or one Token-Ring and one Ethernet
LAN can be linked.
ATM An ATM card has a single physical port but when set up for
ATM LAN emulation, it can be configured as two logical ports.
One logical port is for emulating a Token-Ring LAN, the other
for emulating an Ethernet LAN. The ATM OSA-2 supports both
TCP/IP and SNA in LAN emulation mode and can additionally
support SNA in native ATM mode. (The OSA-2 ATM offers
Forum Compliant LAN emulation).
Fast ethernet A Fast ethernet card increases the speed from 10 to 100
Mb/s, increases connectivity bandwidth, and delivers ease of
use. Additionally it preserves the frame format, wiring
structure, and management of 10 Mb/s Ethernet. The Fast

Ethernet adapter feature supports both 10 and 100 Mb/s
operations, enabling a gradual upgrade of networks.
ATM,
Frame Relay
TCP/IP Network
SDLC
SNA Switch X.25
APPN Switch
V.35
HPR
ATM
Network
ATM
FDDI
Token-Ring
155 ATM
FDDI
Token-Ring
10/100 Ethernet
Ethernet
Figure 34. OSA-2 possible configurations
3.4.1.2 OSA-2 modes of operation

The OSA-2 can act as a host-to-LAN gateway for both the TCP/IP and SNA
protocols. Each OSA-2 can be configured to operate with just TCP/IP, or just
SNA, or a combination of both (apart from an OSA-2 operating in native ATM
mode with SNA). Use of the OSA-2 across multiple LPARs is totally flexible.
Each individual OSA-2 port can be configured to be shared by the maximum
number of LPARs (15).
3.4.2 OSA-2 configuration, management and control

The OSA-2, as part of the S/390 complex, is maintained via the S/390
process controller and the hardware maintenance console. This includes the
RSF “call home” for parts replacement in the event of a problem. The
hardware console interface can also be used to change OSA-2 parameters
such as the local MAC address of the LAN ports.

The FDDI and ENTR OSA-2 cards come pre-loaded with default unit
addresses and TCP/IP host-to-LAN gateway code. The only configuration
necessary is to HCD and TCP/IP. To set up modes of operation other than the
default, a configuration utility, OSA Systems Facility (OSA/SF), is required.
This is a licensed program that runs as an application in MVS/ESA, VM/ESA
and VSE/ESA environments. OSA/SF is included as standard with OS/390
and on appropriate levels of VM/ESA and VSE/ESA.
3.4.3 OSA-Express Gigabit Ethernet

In February of 1999, the OSA-Express Gigabit Ethernet (GbE) was
announced; see Figure 35. This is the first in a new generation of network
adapters attaching directly to the S/390 Parallel Enterprise Server - from G5
onwards.
Gigabit Ethernet exploits G5/G6 Bandwidth
Intranet Gigabit Ethernet (GbE)

Gigabit Directly to G5/G6 memory
Internet Ethernet Utilizes high bandwidth data pipes
Extranet
Up to 8x throughput versus
Fast Ethernet
Jumbo Frames
Requires OS/390 R7
S/390 Architecture enhanced

OSA-2 New instruction for TCP/IP
exploited by SAP R/3
OSA
Express
Connectivity
Memory
To High Speed Digital Networks
Figure 35. OSA Express Gigabit Ethernet (GbE)
Gigabit Ethernet is ten times faster than today's Fast Ethernet standard at
1000 Mb/sec. This significant scalability benefit can only be realized through
integrated S/390 communications adapters becoming more tightly bound to
the IBM S/390 Enterprise Server with OSA-Express GbE.

With OSA-Express GbE comes a new design - a new channel type and a new
S/390 instruction. It is only available on the G5 Server upwards, requires
OS/390 version 2.7, and is for TCP/IP use exclusively.
The use of the integrated OSA-Express GbE feature provides S/390

customers with other significant advantages. OSA-Express GbE eliminates
the need for channel-attach external products that perform the same function
at a much higher cost. Also, in this scenario, one OSA-Express GbE channel
can be used to consolidate approximately five ESCON channels.
OSA-Express GbE is managed as an integral part of the S/390 system; in
contrast, the external boxes require additional skills. As a result,
OSA-Express GbE provides simplicity and price/performance benefits in a
networking environment.
Gigabit Ethernet installed on S/390 will enhance the performance necessary

for Internet and e-business image and video databases.
IBM has also taken steps to ensure that customers can move to these new
I/O standards as required. G5 and G6 servers provide the ability to remove
older I/O cards non-disruptively and replace them with higher performance
cards supporting FICON channels, OSA-Express Gigabit Ethernet and other
evolving technologies that will meet the bandwidth demands of e-transaction
processing. For further discussions on the topic see the redbook S/390
OSA-Express Gigabit Ethernet Implementation Guide, SG24-5443.
3.5 Cisco 7000 Channel Interface Processor (CIP)

Cisco Systems' Cisco 7000 and 7010 routers can be directly attached to
S/390 servers using an interface processor card called the Channel Interface
Processor (CIP). This is another alternative for high-speed network access to
S/390 servers. Combining the power and redundancy of the Cisco 7000 with
a direct S/390 channel attachment (17 MB/s ESCON).
Each CIP takes up a single slot in a Cisco 7000 or 7010 router and can
support up to two channel connections. Channel connections can be a
mixture of Parallel or ESCON or can be two of the same kind. This solution
supports speeds ranging from low-speed serial links, to moderate-speed
Ethernet and Token Ring LANs, to high-speed ATM and FDDI networks.
Cisco CIP offers the following features:

• It has high-performance TCP/IP and SNA networking for S/390 servers.
• It eliminates the need to manage multiple dedicated channel controllers.

• It offers a high mix of WAN and LAN interfaces.
• It supports multiple LPAR connections to the mainframe using ESCON
Multiple Image Facility (EMIF).
• It supports TCP/IP off load which provides the capability to reduce the
amount of overhead processing a S/390 server must do when handling
TCP/IP packets.
3.6 IBM 3745/3746 Communications Controller

It is assumed that most IBM S/390 sites will be familiar with the 3745
Communications Controller, which has been an industry leader since its
introduction. While the 3745 is an excellent solution for traditional SNA
connectivity, customer requirements have pushed for more processing
capacity and multi-protocol support. To meet these needs, IBM introduced the
3746 model 900. The 3746-900 is a non-blocking matrix switch with attached
processors which control LANs, lines and ESCON channels. The addition of
the 3746-900 allows the 3745 to handle two to five times the volume of traffic.
Network Node capability can be added to the 3746-900 which allows it to take
over NCP functions from the 3745, and allows it to become a TCP/IP
host-to-LAN gateway.
The 3746-950 is a standalone version of the 3746-900 and is used when

base 3745 connectivity and NCP functionality is no longer required. In this
form the 3746-9x0 has a dual role. It provides a very powerful APPN network
node routing function within a company network, and it also provides a very
powerful IP router capability, together with multi-protocol sharing of physical
interfaces.
IP routing capabilities are provided over ESCON channels, Token-Ring and

Ethernet LANs and leased lines. The 3746-900 and 3746-950 have recently
been enhanced by the optional addition of the Multi-Access Enclosure (MAE).
This uses the same technology as the IBM 2216 and provides additional
connectivity at lower incremental cost, together with new types of attachment,
often at much higher speeds. It also enables the 3746-9x0 to handle
significantly higher traffic loads.
3.7 IBM 2216 Multi-Access Connector

The new IBM 2216 Multi-Access Connector provides very cost-effective and
high performance IP, SNA, or APPN access to S/390 via ESCON. Using the
same common code as the smaller, well-established IBM 2210 router, one of
the primary uses of the 2216 is providing a channel interface to the

mainframe. It can equally well fulfill the role of a large concentrator node in a
router network or a high performance WAN gateway for a large LAN site. As
previously described, the 2216 uses the same technology as the 3746 MAE,
including a PowerPC processor for routing code execution. There are eight
slots for adapter cards which can be a mix of ESCON, Token-Ring, Ethernet,
Fast Ethernet, ATM, FDDI, V24, V35, X21, ISDN PRI and HSSI/E3. For
further information refer to the redbook IBM 2216 and Network Utility Host
Channel Connections, SG24-5303.
3.8 IBM 3172-3 Interconnect Controller

The 3172-3 Interconnect provides up to two parallel or ESCON channels and
up to four LANs to a S/390 supporting either TCP/IP and/or SNA. The 3172-3
has been superseded by the IBM 2216 described in the 3.7, “IBM 2216
Multi-Access Connector” on page 68.
3.9 Channel-attached RS/6000

Another LAN-to-host gateway option is a channel-attached RS/6000. This
would not normally be cost-justified as a dedicated LAN-to-host gateway, but
might be used as part of a larger project. A channel-attached RS/6000 can be
used as either a TCP/IP router/gateway or an SNA gateway.
3.10 Direct channel connection for PC servers

The original direct channel connection for PC Servers was the Micro
Channel-to-Mainframe Connection (MMC) card. This is only available as a
Micro Channel option and hence requires an IBM PS/2 Micro Channel
architecture machine. The connection is to a standard parallel channel (up to
4.5 Mb/sec.) and consists of the MMC card itself and special cables to link to
standard bus and tag parallel cables. This has been superseded by a PCI
version which attaches to an ESCON channel. The driver support for these
cards is only provided with the LANRES and LAN server for S/390 products.

Chapter 4. Systems management
This chapter focuses on the systems management capabilities of OS/390.
Management for OS/390 is highly automated, including workload scheduling,

resource allocating, and responding to potential and major errors. This is
accomplished via a suite of products including OS/390 products, Tivoli legacy
products and Tivoli enterprise (Framework-based) products.
In 4.1, “Systems management with OS/390” on page 71 describes those

system management products already included in the OS/390 packaging, or
very close to OS/390. In 4.2, “Enterprise systems management with Tivoli
products” on page 73, the growing family of Tivoli products is introduced.
4.1 Systems management with OS/390

The management of a system starts with the allocation of the system
resources to the workloads. As described in 2.4, “The approach of sharing
everything” on page 20, this is done in a S/390 environment by microcode of
the 9672 server and the base components of OS/390. To trigger the
preferences the S/390 architecture is to meet in managing these resources,
the system administrator has various tools and methodologies for monitoring
the system’s behavior and influencing the results.
4.1.1 System Automation for OS/390

If the power and reliability of S/390 servers and Parallel Sysplexes is required
to run critical applications, then operational tools that support OS/390 and
key OS/390 applications are needed. Multiple systems, within Parallel
Sysplexes and outside them, need a combination of local and focal point
automation and monitoring. If the multiple systems are spread remotely, then
remote operations support is a necessity. If consolidation and integration are
key strategies, then tools built on a common base that extend from network
management to systems management are necessary. Likewise, if automation
is essential, then tools that make it easy for operations to implement
automation are a must.
System Automation for OS/390 (SA OS/390) offers this broad scope and
power to cover monitoring, automation, and manual control of the full
operational life cycle of S/390 systems. SA OS/390 is a Tivoli product with a
prerequisite of NetView. It delivers the functions to combine and integrate
what were previously three separate products (however, the last two can be
run natively on OS/390):

• Automated Operations Control/MVS (AOC/MVS)
• ESCON Manager
• Target System Control Facility (TSCF)
SA OS/390 provides a wealth of information on S/390 resources, a rich set of

control functions, and the means to access all those functions through
end-user interfaces as well as via automation. The following functions can be
performed with the product's function set:
• Reconfigure a processor's physical or logical partitions
• Perform power-on reset of processors
• IPL operation systems
• Investigate and respond to I/O configuration errors
• Start subsystems and applications
• Monitor performance based on thresholds
• Restart applications
• Shutdown resources
The workstation-based user interface of SA OS/390 is ideal for creating a

single virtual image. It allows a transition from text-based interaction with
individual systems to graphical depictions of the resources of multiple
systems. The product's new functions and enhancements will primarily be
delivered for this type of user interface in the future.
The user interface is based on the NetView Graphic Monitor Facility, which
SA OS/390 exploits to present graphic images of systems, subsystems and
applications, and volumes. The status of the resource is updated dynamically
based on system events. Thus NetView itself, its Multisystem Manager, and
System Automation for OS/390 all provide function on a foundation that helps
organizations to bridge system and network operations. For example,
operators can monitor LAN resources (through Tivoli NetView) or OS/390
applications, Parallel Sysplex resources, or DASD volumes all using the same
user interface. SA for OS/390 provides host, as well as workstation, user
interfaces, and provides programming interfaces suitable for customer-related
automation.
4.1.2 OS/390 performance management

In large systems, performance management is key to optimizing end-user
support and satisfaction, to improving system availability and to gaining
acceptance of new applications in a business environment. Resource
Measurement Facility (RMF) is one of the most widely used performance
management tools in OS/390 installations, providing support for both single
systems and Parallel Sysplex environments. RMF has added many features
in recent years. In addition to its traditional functions, it offers such facilities

as the RMF spreadsheet reporter which allows PC spreadsheets to use RMF
data. Another item of interest is Performance Monitoring of OS/390 (PM of
OS/390). This is a PC-based function which uses RMF data to help manage
the enterprise. It is integrated into the performance monitoring common
framework and through its integration enables access to performance data
from other applications, for example, performance monitoring of SNA.
The OS/390 Workload Manager (WLM) adopts a business goal approach to

the management of workload tasks. Users can specify business-oriented
targets for each piece of work such as the following:
• Transaction response time ranges for different online applications
• Performance criteria for interactive program developers
• Run times for critical batch systems.
Different workload types can have very different objectives in response time
or batch turnaround time. WLM will then manage dispatching priorities, use of
memory, and other resources to try to achieve the objectives for all of the
workloads. This is done automatically by the system on a second-by-second
basis. There is no need for the user to work out the right dispatching priorities
and memory usage for each application, and no need to monitor and change
the system as the workload mix changes.
This requires detailed monitoring capabilities and sophisticated algorithms in

the operating system. These algorithms have been improved and optimized
over the years to handle the workload being run on larger and larger SMPs.
4.1.3 OS/390 configuration management

The hardware configuration solution for OS/390 consists of two elements: the
Hardware Configuration Definition (HCD) component of OS/390 and the
Hardware Configuration Manager (HCM), an optional priced feature of
OS/390. Both products work closely together to provide the full range of
configuration activities, such as planning, definition, activation and
documentation.
4.2 Enterprise systems management with Tivoli products

The continuing deployment of applications that span both the OS/390 and
distributed platforms, the introduction of new technologies, the continuing
changing business needs and the availability of skilled people has highlighted
the challenge of managing a complex environment end to end.
Systems management 73
The topic previously discussed concerned systems management on the
S/390 platform itself. S/390 is now also playing a wider role in the systems
management of the enterprise. This involves being managed by or managing
distributed environments with Tivoli’s help.
The system management functions based on S/390 have been extended to

support the management of applications across the OS/390, UNIX and PC
environments. For example, NetView added its Multi System Manager
component and Operations Planning and Control (OPC) added trackers to
manage workload on many other platforms. These developments in Tivoli’s
architecture opened the way for OS/390 to operate in three different system
management roles, with the installation choosing which to use:
• OS/390 as the enterprise manager (the OS/390 server manages the
enterprise end to end)
• OS/390 as a managed server (the ability for systems management
function on other platforms to manage activities on OS/390)
• OS/390 as a peer manager (in which it cooperates with systems
management functions running on other platforms)
4.2.1 Tivoli Enterprise architecture

Tivoli Enterprise provides a consistent management interface to different
operating systems and services. It allows administrators to manage users,
systems, databases, networks and applications from one desktop and
provides a streamlined way to automate and delegate routine,
time-consuming tasks. An overview of this architecture is shown in Figure 36
on page 75.

Integration Tivoli Global Enterprise Manager
ADSM Tivoli Manager for ….. Domino/
Application MQ Series SAP R/3 Database Notes
Tivoli
Deployment Availability Security Operations
Value
Software Distributed Security Workload Remote
Distribution Monitoring Management Management Control
Infrastructure
Inventory Enterprise User
Netview Storage Service
Management Console Administration
Management Desk
Tivoli Framework (3.6)

Systems
Systems Networks
Networks Databases
Databases Applications
Applications Internet
Internet
Figure 36. Tivoli Enterprise architecture
The foundation of Tivoli Enterprise Architecture is the distributed object

oriented software called Tivoli Framework which was developed by Tivoli to
manage distributed systems across multiple platforms (OS/390, UNIX, NT,
NetWare, OS/2 and so on). The Tivoli Framework forms the base set of
common services for all management products. Most of the applications of
the Tivoli Enterprise suite use the services included in the framework. It also
serves as a single point of integration for the growing set of Tivoli and third
party applications.
The infrastructure layer shown in Figure 36 is comprised of a suite of

management products in the following disciplines:
• Deployment - enables global configuration change management (Tivoli
Inventory, Tivoli Software Distribution)
• Availability management - collects and routes information for proactive
management (Tivoli Distributed Monitoring, Tivoli NetView, Tivoli
Enterprise Console, Tivoli Decision Support)
• Security management and user administration - ensures proper access
while protecting corporate assets (Tivoli User Administration, Tivoli
Security Management)
• Operations and administration - automates activities to ensure service
levels and streamlined tasks (Tivoli Remote Control, Tivoli Workload
Scheduler, Tivoli Output Manager, Tivoli Service Desk)
The Tivoli Management Modules run on top of the Tivoli Enterprise

applications. They provide an integrated way to manage critical applications
in a consistent manner. Tivoli has the following management modules:
• Databases such as DB2, Oracle, Sybase, Informix and MSQL
• SAP/R3 and MQ Series
• Messaging systems such as Domino/Notes and Microsoft Exchange
• Internet servers such as Microsoft Commercial Internet System servers
and Netscape Suitespot servers
To bring it all together, Tivoli Global Enterprise Manager (GEM) unifies the
management of cross-platform business applications. GEM extends the
capabilities of Tivoli to provide a new paradigm for applications management
called business systems management. Business systems management
allows customers to manage groups of related applications that underpin and
enable critical business functions, such as catalog and order processing
systems, enterprise resource planning (ERP), or enterprise-wide e-mail.
The Tivoli Framework-based products will provide integration with the

distributed world, in the sense that it can be the manager of a distributed
heterogeneous environment.
4.2.2 Tivoli Framework

The Tivoli Framework provides the basic system management services, such
as communications, presentation, security and so on that most of the Tivoli
management applications use, thus ensuring consistency and integration. At
its core, Framework provides the facilities to transfer files and execute
commands on remote systems with built in security and authorization roles.
Most Tivoli systems management tasks, regardless of the application or

component that is to be managed, may be performed by using the Tivoli
desktop which provides a user interface consistent throughout management
applications. However, many jobs and tasks can also be executed by using
the command line interface.
The Tivoli Framework separates administrators using a systems management

application from the variety and complexity of the environment they need to
manage. Applications provided by Tivoli and its partners fit on top of the
Framework, accessed by a common, productive user interface.

For example, Tivoli's User Administration application allows an administrator,
with a single action, to add new users to all the platforms where a registration
is needed, even though this might involve OS/390 and various types of UNIX
and Intel implementations. Such an administrator does not need to know how
many platforms are involved, where they are, what they are, or what
registration command each requires – the services of the Framework deal
with this complexity. This is a double productivity gain – one action instead of
one per server, and no need for expensive, platform-specific skills.
4.2.3 Tivoli’s three-tiered architecture

Tivoli’s three-tiered architecture is made up of the Tivoli management agent
(also called an endpoint ), the Tivoli management gateway and the Tivoli
management server.
The Tivoli management agent is installed on a machine that needs to be

managed, now called an endpoint. The endpoint is the target of some
systems management activity and does not imply size of the system. An
endpoint can be a server, mainframe, or laptop. Tivoli management agents
reduce the impact and cost of deploying and maintaining systems
management tools because they are small, data-less and self-configuring.
The Tivoli management gateway controls all communications with agents, as

well as all operations on agents. Agents communicate only with gateways,
which, in turn, communicate with a Tivoli management server.
The Tivoli management server controls and configures gateways and agents,
assigns agents to gateways, and keeps track of every agent in a Tivoli
Management Region (TMR).
4.3 Tivoli systems management products on OS/390

The ever-growing Tivoli products, described in the following section, can help
with network management, change management, problem management,
security management, operations management and storage management.
4.3.1 Tivoli NetView for OS/390

Tivoli NetView for OS/390 (NetView, for short) is Tivoli's foundation for the
management of the OS/390 platform. It works with other products, from Tivoli
and from Tivoli's partners, to perform the following:
• Comprehensive end-to-end network management
• Centralized system and network management
• System and network automation
• System and network monitoring and operation
• Network problem determination and diagnosis
Used with Tivoli GEM, it supports the management of applications that extend
across multiple platforms. These two, working together, unify the
management of OS/390 and distributed environments.
NetView combines what were previously three separately chargeable items –

NetView itself, Multi System Manager and Automated Operations
Network/MVS (AON/MVS). It provides some vital functions for management
of, or from, the OS/390 platform. Its varied functions provide major support for
service availability, and its wide range, and highly productive interfaces,
provide major support for reducing the staff levels needed to manage network
computing environments.
4.3.2 Tivoli NetView Access Services (NVAS)

NetView Access Services (NVAS) is a session management tool. It is a
communication product that acts as a mediator between a mainframe user
and multiple applications sessions that are assigned to the user. It provides a
single consistent user interface to access one or more VTAM applications in
the network from a single 3270 or compatible device.
4.3.3 Tivoli NetView Distribution Manager for MVS (DM/MVS)

NetView DM/MVS provides the centralized management capabilities needed
by large customers utilizing the OS/390 system as the primary management
system. With NetView DM/MVS, customers can automate the distribution of
software and data to a large number of remote targets, providing centralized
tracking, automated error recovery, and efficient utilization of their network
during the distribution process, as well as providing a history of the
distribution process.
4.3.4 Tivoli NetView Performance Monitor (NPM)

Tivoli NetView Performance Monitor (NPM) provides powerful support for
monitoring and managing performance. It captures data for the enterprise
LAN, Novell NetWare, SNA, X.25 and Frame Relay networks, and for VTAM
and network hardware, including the new NCP-less models of 3746.
It integrates closely with NetView Graphic Monitor Facility to give

administrators easy, graphical access to the performance information that
they need. With its Desk/2 function, it provides the capability to graph data, to
create table reports, or to export data to spreadsheet or business graphics
programs. These functions enable an enterprise's support staff quickly and

productively to identify and address performance problems, with significant
impact on service quality.
4.3.5 Tivoli NetView FTP for OS/390

NetView FTP provides efficient and reliable data exchange between OS/390
and OS/2, AIX or OS/400 systems. Its efficiency is based upon direct fetch
and store capability, peer-to-peer support versus master-slave relationships,
effective data compression, checkpoint/restart support, and file type
conversion support such as disk-to-tape or sequential file-to-PDS member.
4.3.6 Tivoli Performance Reporter for OS/390

Performance Reporter for OS/390 provides a central repository for easy
access to historical enterprise-wide IT utilization and service-level statistics
that are valuable in performance reporting, capacity management,
service-level management and accounting. Performance Reporter for OS/390
collects standard systems management data, organizes it, stores it in a
standard DB2 database, and presents it in graphical or tabular reports. The
reports can be used as is or customized. Performance Reporter consists of
the Performance Reporter base and several components including: CICS
Performance, IMS Performance, System Performance, Network Performance,
AS/400 Performance, Workstation Performance (UNIX and NT), and the
Accounting option.
4.3.7 Tivoli Security Management

Tivoli Security Manager is the industry’s first enterprise security solution
allowing the consistent definition, implementation and enforcement of security
policy across the entire network computing environment - from the data
center to the desktop. It incorporates, integrates and extends the most
efficient and powerful aspects and functionality of existing system- and
application-specific security products.
4.3.8 Tivoli Operations Planning and Control (OPC)

Tivoli Operations Planning and Control (OPC) can manage a workload that
extends across multiple platforms. The schedule can include workload
elements on Windows NT, AIX, OS/2, OS/400, HP-UX, SunOS, Sun Solaris
and other platforms. It can manage interdependencies between these; for
example, you can specify “Only run this job on HP-UX if this one on Windows
NT and this one on OS/390 have completed successfully”. It can track such a
workload, and handle recovery actions when things go wrong – all
cross-platform. Because it provides automation, Tivoli OPC can have a major
impact on availability and productivity. Because its actions can be
cross-platform these benefits can be much greater.
4.3.9 Tivoli Service Desk for OS/390

The Tivoli Service Desk for OS/390 consists of an integrated set of tools and
services for customizing and automating:
• Help desks or call centers
• Problem management
• Change management
• Configuration management
Tivoli Service Desk provides support for problem management, change

management and inventory management. Problem management, especially,
can involve large amounts of data, and plays to the strengths of S/390 as a
massive data server. The user interface is supported through many platforms,
including access via the Internet, using a Web browser. The data that it holds
can be created or updated automatically by NetView, and it can work
cooperatively with a help desk application running in the distributed
environment, using Tivoli GEM, as discussed in 4.3.11.1, “Tivoli Enterprise
Console (TEC)” on page 82.
The Tivoli Service Desk repository is capable of storing up to 400 gigabytes

of data on an OS/390 server. Users can get to this data from the platform of
their choice, using the Web connector interface. Information can be recorded
on problems and changes as they occur, using tailored formats and data.
Integration is provided with products such as Tivoli NetView, Tivoli Operations
Planning and Control, Tivoli Global Enterprise Manager, Tivoli Enterprise
Console, and Tivoli Software Distribution.
4.3.10 Tivoli Manager (TM) for OS/390

Tivoli Manager for OS/390 (TM) delivers the capability to view S/390
environments and existing applications from a business view perspective. TM
for OS/390 collects and correlates information within the OS/390 environment
from a variety of sources. This information displays graphically and notifies
the user whether tasks are running as scheduled, if the current state of a
resource has changed, or if performance thresholds are being exceeded.
4.3.11 Tivoli Global Enterprise Manager (GEM)

OS/390 can already act as a systems management server working in
cooperation with Tivoli management applications. This is achieved using
Tivoli Global Enterprise Manager (GEM). GEM provides the ability to manage

applications that extend across OS/390 and other platforms. This is a
significant advance over previous approaches, which have required staff to
manage each part of an application separately. Instead of managing the
OS/390 part of an application as one entity, the UNIX parts as a second entity
and any PC parts as a third, this approach enables the support team to use
one highly productive, graphical user interface to manage all the parts of the
application, on the various platforms.
From the Tivoli GEM console shown in Figure 37 on page 82, the Credit
Check application’s components, spanning various server platforms including
MQ Series queues, can be controlled from one management console.
This “management by application” builds on the GEM services which link the
management of the OS/390 and distributed environments. It is available now,
as the application policy manager component of GEM, and does not depend
on Tivoli Framework being implemented on OS/390. For example, Tivoli GEM
supports a bidirectional flow of events and commands. Events occurring in
the environment being managed by Tivoli's distributed products can be
reported to NetView on OS/390. Commands can be sent back in response to
these events, either automatically or entered via NetView. Conversely,
messages and alerts visible to NetView can be passed to the TEC, running in
the distributed environment. If necessary, commands can be sent back to
NetView, OS/390, JES, TSO, and so on.
Figure 37. Tivoli GEM console in Control mode
Tivoli GEM's main benefit, allowing support staff to manage by application,

across platforms, is best illustrated by an example. An e-mail service made
up of OfficeVision, Notes and Microsoft Exchange, running on S/390 plus
various UNIX and Intel platforms, and involving a variety of other hardware
and software components, could be managed as a complete application by
the administrators. They would do this using the graphical functions in the
Java client provided by the Application Policy Manager component of GEM.
For further information and demos, visit the Tivoli Web site at:
http://www.tivoli.com
4.3.11.1 Tivoli Enterprise Console (TEC)

Tivoli Enterprise Console (TEC) provides a centralized point of control for an
entire distributed environment, and is a powerful event manager and
automation application. The TEC processes can respond to the thousands of
events and alarms that occur daily from network devices, hardware systems,

relational database management systems and Tivoli partner and customer
applications.
The TEC has three primary features:

• Comprehensive event integration
• Powerful event processing and correlation
• Secure, automated event response and notification
These features combine to allow a centralized point of control.
Chapter 5. Server consolidation on S/390
Many organizations recognize the total cost and complexity of their

distributed computing environment, and they are looking to consolidate onto
a small number of powerful servers such as S/390.
5.1 S/390 server consolidation introduction

As the number of distributed UNIX and PC systems has grown over the
years, the problems of systems management, data consistency and user
support have escalated. The impact on IT support costs has been
considerable. Many organizations are moving to server consolidation in an
effort to simplify IT operations and reduce overall costs.
In many organizations, the S/390 server is the ideal platform to consolidate

onto. The strengths of S/390 are now combined with low total costs of
ownership and open interfaces. Since much enterprise data often exists on
S/390, it is the ideal hub around which to integrate the enterprise. There are a
range of tried and tested solutions and options for customers wanting to use
S/390 as the basis of a consolidation or interoperability strategy.
As shown in Figure 38 on page 86, S/390 server consolidation can be

classified into two main areas which are:
• Rehosting work to S/390 to achieve consolidation of servers and
workloads
• Interoperating with other IBM, UNIX and NT platforms
Organization have many different applications so each should be examined

to see in which area the more appropriate consolidation solution lies.

File servers
Print servers Database servers Re-host work
Lotus Notes servers Application servers
or interoperate
Web servers Mail servers
etc; servers
Figure 38. Server consolidation on S/390
5.1.1 Rehosting work

This section describes many of the options for rehosting work onto a S/390
platform:
• You can migrate to a new application (vendor product or written inhouse)
designed for or supported on S/390. One example is moving from a PC or
UNIX-based mail system, offering minimal extra function, to Lotus Domino
for OS/390, which includes comprehensive groupware and workflow
capabilities.
• You can migrate from a vendor application running on a UNIX or PC
system to the S/390 version of the same product. There are an
ever-increasing number of applications, such as those from J.D. Edwards,
PeopleSoft, Oracle, Beyond Software, and SAP AG that offer such options.
• You can request a vendor to port existing UNIX or PC applications to
S/390. Many vendor applications can be easily ported to the OS/390
platform.
• You can port C and C++ programs, written to Windows NT interfaces, to
OS/390 utilizing Bristol Technology's Wind/U product.
• Move Web applications to S/390. For more generic applications, such as
Web-serving applications, simply move the data from the UNIX or PC
platform onto S/390 and perform the Web serving from there. See 5.3.2,
“Web serving: the OS/390 WebSphere Application Server” on page 95 for
the broad list of options available on S/390.

• You can use S/390 and DB2 to create a data warehouse for data mining
and large-scale business intelligence (BI) operations.
• You can contain the proliferation of UNIX and PC servers. Adopt a
strategy which states that before any new application choice is made, all
options available on S/390 must be explored.
5.1.2 Interoperation
In cases where rehosting work to S/390 is not possible or is inappropriate,
then interoperation should be considered. This can cover many options,
some of which are described as follows:
• Improve data transfer links between UNIX, PC and S/390 servers.
• Use S/390 as a data repository and make it appear as if data is still on the
UNIX or PC server (for example, use LANRES, NFS, DFS/SMB).
• Create a single computing environment in which data can be held and
accessed on UNIX, PC and S/390 servers in a seamless way (for example,
use DCE/DFS).
• Use S/390 as a database while keeping the application on the UNIX or PC
server (for example, use an SAP R/3 database server). Alternatively,
maintain copies of data on OS/390 for distributed DB2 UNIX or PC
servers, including occasionally-connected systems (laptops), using Data
Propagator, in a fully automated way.
• For applications that are platform-independent, use the S/390 as the
primary server where, for possible geographic reasons, there are multiple
distributed servers on UNIX or PCs (for example, Lotus Domino).
• Use the S/390 as the primary management hub for network management,
data distribution and LAN data backup (for example, Tivoli Framework and
Tivoli ADSM).
• Use bridging software to link different applications on a whole variety of
different platforms (for example, IBM MQSeries).
5.2 Porting applications to OS/390

With the addition of UNIX System Services to OS/390, many modern
applications can be candidates for being ported to OS/390. There are other
families of applications besides those created in a conventional UNIX
environment which may be considered (such as CORBA-based applications,
Java, and so on). Not all of those families of applications are addressed in
this section, but UNIX applications in C/C++ and Windows NT applications
are addressed.
Server consolidation on S/390 87

5.2.1 Porting UNIX applications to OS/390
In September 1996, OS/390 Version 1.2 was formally branded by The Open
Group as XPG4 UNIX Profile (UNIX95) compliant. This branding has been
achieved by integrating UNIX capability into OS/390. Specifically, OS/390
provides UNIX APIs, a UNIX shell environment, and a hierarchical file system
(commonly referred to as “the HFS”). The aggregate of these functions is
called OS/390 UNIX Systems Services.
Conventional OS/390 (MVS) applications continue to run unchanged and are

unaffected by the new capabilities. UNIX applications can now run on the
same OS/390 system and benefit from the reliability, availability, security and
other industrial strength characteristics of the S/390 platform. In addition,
data in MVS datasets and in HFS files are usually easily shared.
There are many ways to interactively access these two aspects of OS/390.
MVS system administrators and programmers will continue to use TSO. To
access UNIX System Services, there is an OMVS command which brings the
TSO user into a UNIX shell session, and an ISPF shell (often referred to as
“the ishell” or simply “ish”). From OMVS, the ISPF editor can be used, but the
vi editor cannot, since the 3270 data stream is used for communications.
UNIX system administrators and programmers will want to access OS/390
UNIX using the conventional interactive login tools of telnet or rlogin. When
users are “telnetted” or “rlogged” in to OS/390 UNIX, the conventional UNIX
editor, vi, works fine, but OEDIT does not.
5.2.1.1 The porting process

Porting is defined as the process of getting an application to run correctly on
the target platform, in our case S/390. If an application adheres to standards,
then theoretically the process is just a re-compile on the target platform. In
practice, porting often requires more effort and needs a properly managed
project. Essentially, the process of porting consists of identifying code that
does not conform to standards implemented on the target system and then
changing, or conditionally changing, that code. The length of ports vary
widely depending on the application.
5.2.1.2 The porting environment

IBM has established a number of porting centers worldwide. Locations
include Hursley in the UK, Montpellier in France, Boeblingen in Germany and
the Washington Systems Center in the US. These centers provide an
environment (that is, hardware, software, access to skills) in which a UNIX
programmer can conduct a port. They are particularly appropriate for
software vendors with no inhouse S/390 system or skills. The recommended
setup is that the applications programmer uses a familiar workstation (for

example, an X-station or PC) and accesses OS/390 UNIX directly via rlogin
or telnet. which has a more conventional UNIX “look and feel” than that is
obtained via TSO. Given a familiar workstation and a UNIX95-compliant shell,
a UNIX programmer with no MVS or OS/390 skills or experience can be
immediately productive.
5.2.1.3 Skills required

The port itself needs to be carried out by a UNIX programmer who has a
detailed knowledge of the structure, use and maintenance of the application.
C/C++ programming and debugging skills are required, as is familiarity with
the Korn shell and utilities such as make and c89. Previous porting experience
is preferred and a working understanding of open systems standards is
useful. During the port, systems administration tasks such as adding new
user IDs, new file systems, changing OS/390 customization options and so on
require OS/390 systems programming skills. Experience has shown that in
practice the individual application programmer does not need OS/390 skills,
but does require access to them. The programmer need never leave the UNIX
shell environment. OS/390 includes familiar UNIX utilities such as the vi
editor, the dbx debugger, grep, lex, yacc, make, tar, pax, c89 and c++.
5.2.1.4 Customizing OS/390 with open source software

While most of the conventional UNIX development tools have become a
standard part of OS/390, there are other tools in the “open source software”
community which have become accepted and expected by the UNIX
programmer. Many of these tools have been ported to OS/390. Tools
including gmake, gzip, Perl, EMACS, rcs, Samba and others are available on the
MKS S/390 GNU Web site at:
http://www.mks.com/s390/gnu/
Often, getting these tools built and running on OS/390 requires additional
customization. More details of UNIX application development are available
from the following sources.
• The redbook Porting Applications to the OpenEdtion MVS Platform ,
GG24-4473.
• The redbook Networked Applications on OS/390 UNIX, SG24-5447. This
book includes a CD with some open source software packages and
installation scripts to make the customization of OS/390 easier.
• The OS/390 UNIX System Services page entitled Porting, on the Web at
http://www.s390.ibm.com/oe/bpxa1por.html

5.2.1.5 Duration of a port
Some applications can ported to OS/390 without a single problem in a matter
of minutes (an example is GNU’s gzip). At the other end of the spectrum, it
can easily take more than a year for a software vendor to bring a major
application package to the market. A reasonable elapsed time target for most
commercial applications would be three to six months. The technical factors
that have the most influence on the actual duration are:
• The degree of standards compliance of the code
• The database used
• The application development environment used to create the code
5.2.1.6 Feasibility port

It is recommended that a two-to-three day feasibility port be conducted. This
would normally be done at an IBM porting center but could equally be done
on a company's own OS/390 system if the UNIX Systems Services
environment has been customized. The objectives of the feasibility port would
be:
• To identify all technical issues with the proposed port
• To estimate the resource and elapsed time required to complete the work
At the end of the feasibility assessment, the application owner/vendor has

proved the concept of porting to OS/390 and has a good estimate of the
future effort required. This information can then be used as input to a
business case. Depending on the work remaining, the port could be
completed either at the porting center, or at the application owner's site.
5.2.1.7 Porting issues

The overall experience of UNIX programmers porting to OS/390 is that it is as
easy as porting between other UNIX environments. They are happy to
consider OS/390 as a UNIX system. Much of the time spent porting to
OS/390 is generally spent on tasks that are common to porting generally.
However, there are porting issues specific to OS/390 and some of these are
discussed in the following section.
5.2.1.8 ASCII dependencies

All UNIX platforms use ASCII character encoding. OS/390, whether with or
without the UNIX APIs, uses EBCDIC character encoding. Most of the time
this is transparent to a programmer. However, it is significant where an
application passes data from an ASCII system to or from an EBCDIC system
under program control, or where the programming logic is dependent upon a
particular ASCII character code (such as ‘0x41’), rather than the character

itself (such as ‘A’). In OS/390 Version 1 Release 3, a new compiler option
was added (__STRING_CODE_SET__) which generates ASCII strings rather
than EBCDIC strings to avoid later conversion. In addition, a C/C++ library
named libascii is available on Web at the OS/390 UNIX Tools and Toys page:
http://www.s390.ibm.com/oe/bpxa1toy.html
This library supports ASCII input and output characters by performing the
necessary iconv() translations before and after invoking the C/C++ run-time
library functions. This code was originally written to facilitate the port of Lotus
Notes and Lotus Domino to OS/390. DB2 Version 5 is able to hold data in
tables in ASCII format and allows SQL commands to operate against such
data without conversion to EBCDIC.
In summary, ASCII dependencies of some sort are found in most UNIX

applications. However, in no port have they been a show stopper.
5.2.1.9 Database considerations

Applications using the UNIX APIs on OS/390 can also access S/390
databases such as DB2 or Oracle. The same databases can be accessed by
conventional OS/390 applications at the same time. Neither IBM nor Oracle
have any intention or requirement to produce separate UNIX versions of their
databases for S/390. An application that uses DB2/6000 can be migrated to
use DB2 on OS/390 and Oracle UNIX applications can be migrated to use
Oracle on OS/390. When migrating from a UNIX version of a DBMS to the
S/390 version, there will be a number of differences to address. There are
some syntax differences in the SQL, the application connection to the
database may be different, the interfaces to utilities will be TSO rather than
shell, and some performance tuning options may be unique. Other UNIX
databases such as Sybase, Infomix and Ingres have no corresponding
products available on S/390. Applications using these databases would have
to be migrated to a product that runs on OS/390. IBM and third parties have
tools and service offerings which can assist with and largely automate this
process.
5.2.2 Porting UNIX applications summary

OS/390 brings the benefits of Open Systems to the S/390 platform and the
benefits of the S/390 to UNIX applications. To exploit these benefits, UNIX
applications go through a porting process. Porting experiences to date have
been positive, with UNIX programmers regarding OS/390 as a UNIX system.
There are some unique considerations, such as ASCII/EBCDIC translations,
but the overall experience is that porting to OS/390 is really comparable to
other UNIX ports.

5.2.3 Porting NT applications to OS/390
Applications developed on Windows NT are typically written in either the
C/C++ or Visual BASIC programming languages. There is no path to porting
applications written in Visual BASIC, but there is currently a solution available
to port Visual C/C++ applications to OS/390.
Bristol Technology specializes in enabling cross-platform development:

allowing a single source code base (built on NT, or “Win32” interfaces) to be
deployed on both NT and UNIX platforms. The tool, Wind/U, has been ported
to OS/390 by Bristol and is available. It allows C/C++ code with Win32
function calls to be moved to OS/390 and recompiled. For a complete
description of the product, see the redbook Bringing Windows NT
Applications to OS/390, SG24-2093. For more details on the Wind/U product
see the Bristol Web site at:
http://www.bristol.com/
Bristol’s Wind/U currently supports NT Version 4. Recently Bristol lost the

major portion of a lawsuit against Microsoft over the cost of the licensing of
the Windows 2000 source code. While Wind/U remains a viable solution with
Windows NT 4 development, the future of Wind/U as a solution with Windows
2000 development should be considered. The latest information on Windows
2000 support for Wind/U will be maintained on the Bristol Web site.
5.3 Distributed business applications

A key factor in selecting a server is often the availability of an application
package, tool or database management system on that platform. Some
professional business applications, designed as multi-tier applications, were
originally developed for non-S/390 platforms. Answering to the demands of
there customers, who want to gain benefits from both the application and the
S/390 platform, many software vendors ported the central parts of their
applications onto OS/390. Also there is a growing number of vendors who are
developing new applications for the S/390 platform. Vendors recognize that
their customers can only achieve the reliability, scalability and performance
potential of their products on the S/390 platform.
In this section, three traditional non-S/390 application types and their

implementation on OS/390 are discussed:
• Groupware applications
• Web serving
• ERP applications

Each of these is represented by an available mature business application.
5.3.1 Groupware applications: Lotus Domino

Groupware applications enhance a team's ability to communicate, collaborate
and coordinate. Businesses are using groupware applications to improve
responsiveness and reduce complexity. At the same time, they are delivering
competitive advantage in a wide variety of situations across all industries. As
these new applications grow, in terms of users or function, problems are
common which at best delay return on investment and sometimes result in
project failure. The following critical success factors are difficult but important
to achieve:
• Develop distributed applications across heterogeneous networks
• Integrate with existing transaction systems
• Access relational data
• Extend a business to the Internet
In response to these market needs, solutions for e-mail, document

management, workflow and intranet are converging. The need for highly
available and scalable solutions that closely integrate with existing enterprise
applications is critical. Lotus Domino, shown in Figure 39, is positioned as
one of the best solutions in this rapidly growing market.
Notes & HTTP server
inquire
DBMS
Internet
respond escalate
update notify
alert
assign
Customer Service Rep Account Rep
Figure 39. Lotus Domino on S/390

Lotus Notes is an open, distributed, secure, document database with
integrated messaging for mail and workflow. It comes with its own application
environment that consistently enables users to achieve a faster return on
investment than build-your-own solutions. Lotus Domino, the server
component, expands the Notes collaborative offering into an interactive Web
applications server. This allows any Web browser or Notes client to
participate in Notes applications in a secure manner. Lotus Domino for S/390
is the industry's premier groupware, messaging and Internet product on the
most reliable, secure and scalable server platform.
Lotus Domino for S/390 gives organizations unprecedented flexibility,

reliability and scalability for supporting mission-critical groupware
applications. Companies will be able to tie together their S/390 enterprise
data and applications with their Domino network providing secure and
cost-effective collaborative Web applications. As the Notes application
environment is common across all platforms, a S/390 Domino server can be
easily and quickly integrated into an existing Domino or Notes network. Lotus
Domino for S/390 is the ideal choice for implementing new Web-enabled
applications that access existing corporate applications or data.
Lotus Domino for S/390 also provides an ideal replacement for existing
host-based office systems giving scalable mail routing, directory, calendaring
and scheduling services. Pilots started on smaller platforms can easily be
replicated to a S/390 server to provide the integration and scalability required
for many corporate solutions.
Organizations that fall into the following categories are strongly

recommended to consider Lotus Domino for S/390:
• Large Notes users today that need scalability for common applications
• Host-based e-mail clients
• Companies offering large document-based Web servers for publishing or
simple forms-based applications
• Companies developing Web-enabled applications that need to integrate
with S/390 database or transaction services
Lotus applications are platform-independent. Consequently, applications

written inhouse or from any one of the Lotus business partners worldwide can
be investigated using Lotus Domino on a smaller platform and then be used
by Lotus Domino on S/390.
For further information, see the redbook Lotus Domino for S/390 Release 5:
Installation, Customization and Administration , SG24-2083.

5.3.2 Web serving: the OS/390 WebSphere Application Server
World Wide Web technology has been the main driver for the explosive
increase in the use of the Internet that we see today. Figure 40 illustrates this.
Internet connection
Servers
(Web Servers)
Intranet
Web Browser Internet
TCP/IP Internet connection

Web Server
Browser
(Web Server)
Figure 40. Web browsers and web servers
What is different about Web technology? In a Web environment there are

Web servers and browsers. The communication protocol between server and
browser is the HyperText Transfer Protocol (HTTP). The underlying transport
mechanism in a Web environment is predominantly TCP/IP. (SNA networks
can participate with the use of AnyNet.) Broadly speaking, Web servers have
a very straightforward job to do. They listen for requests from Web browsers,
check the authorization of the request, then if approved, send the requested
file to the browser machine. Most files held and distributed by the Web server
are written in HyperText Markup Language (HTML) format. The Web server
does not care about the content of the file and has no need to understand
HTML.
It is the browser, not the server, that does most of the work. The Web browser
needs to understand what to do with the HTML file and how to display the
output with text and graphics as appropriate. It also has the “navigational”

task of locating any subsequent files that may be called for. The beauty of the
Web browser/Web server concept is that, as long as each Web software
component complies with HTML, HTTP and associated standards, then a
browser on any platform can work with a Web server running on any other
platform. Hence the browser is becoming known as the universal client .
Indeed, the browser can be used to access data on a personal system, a
company's servers (an intranet), another company's public servers (the
Internet), or another company’s private servers (an extranet).
5.3.2.1 Computing paradigms

Figure 41 on page 97 shows what network computing is about by comparing
the evolution of different computing paradigms.
The first shows a dumb screen link, generally static, to a central server. In this
scenario all processing and data storage is performed by the central server.
Display functions are limited to text only. Then came the PC which offered a
graphical user interface, performed its own processing, and stored all data
locally. Next came the LAN file server. This model shows the graphical display
and application functions being performed on the local workstation with data
stored on one or more LAN file servers.
In the client/server model, the graphical display is performed at the

workstation but the application and/or data is shared by the workstation and
one or more servers in the network. Although this model seemed to offer
benefits, many implementations became highly complex and difficult to
manage.
With the network computing model, we have what is essentially an intelligent

graphics engine, that is, the Web browser. This has a flexible link to a central
application and data server. In the base model, all application processing is
performed by the central server. The browser handles all display functions
and the GUI. An extension to this base model is in the use of Java applets.
The Java applets are small programs which are stored on the server and
downloaded as required to the browser machine. In this way more function is
given to the browser machine, but all programs and control are still
maintained centrally.

Central application
Dumb Screen D & data server
Intelligent
Workstation G
Intelligent
Workstation
G LAN file server
Client / Server G
Network Central application

Computing
G & data server
Network Computing Central application

including Java G & data server
Figure 41. Different network computing paradigms
5.3.2.2 Network computing

True network computing is being done at various levels of sophistication.
From surfing to working

As companies move from just having a passive presence on the Web, offering
read-only data access or simple mail exchange, into real-time
transaction-based systems, then the demands on these systems moves to a
new level. In the former mode, if a Web server became unavailable, due to
hardware, software, network or capacity problems, then the consequences
would not be too severe. However, if this Web-based service becomes a
business-critical application, then unavailability or poor performance of such
a system can lead to loss of business and customers. This mode of operation
calls for 24 by 7 continuous operation. What better platform to use for this
than S/390, which is renowned for its high availability, scalability and
security?
Working the Web – HTML gateways

In order to use the Web for business or for more customized services, a
method of accessing company databases and transaction systems is
required. A way to prompt the user for data input is also necessary. The
programs that link the Web server to other components on the hosting
system, such as CICS, IMS, DB2, Lotus Notes, SAS or other systems, are
referred to as HTTP gateways. The Common Gateway Interface (CGI) is
currently the most common technique used, although more efficient APIs

such as IBM's Internet Connection API (ICAPI) are gaining acceptance. On
OS/390, ICAPI can be compared to a user exit. Other similar APIs are
Netscape's NSAPI and Microsoft's ISAPI. In fact, IBM's latest Web servers
support NSAPI.
In order to prompt the user for data entry, HTML forms are used; see Figure
42. These contain data entry fields and are linked to specific CGI or other
APIs. When the user completes the entry fields and presses a submit button,
the data is sent back to the Web server, which invokes the appropriate
gateway program. CGI programs can be written in many different languages
which include C, REXX and Perl.
Web Browser
OS/390
machine HTTP
WebSphere
Java Application
Server for
OS/390 as
xxxxxxx xxxxxxx
xxxxxx
xx xxxxxxx xxxxx xxx
xxx Proxy Server
xxxxxxx xxxxxxx
xxxxxx
xx xxxxxxx xxxxx xxx
xxx
xxxxxxx
xxxxxxx CICS
xxxxxxx
xxxxxxx xxxxxxx
xxxxxx
DB2
HTML
document Internet
containing or Intranet
forms Lotus
Notes
or similar
Figure 42. HTML gateways and Internet Connection Secure Server
Product gateways
For most major systems and subsystems that run on OS/390, there are
already IBM and/or third-party software vendor gateways available which
greatly simplify the task of creating the links required. In addition, OS/390
includes the Internet BonusPak. This is a set of tools, sample Web pages,

demonstrations and documentation to enable the S/390 WebSphere
Application Server to be quickly exploited.
Java
Java is a state of the art, object-oriented programming language that is
becoming ubiquitous in the computer industry. The 'write once, run anywhere'
paradigm has created significant demand for the Java language. Java
provides the ability to write an application on any platform and run it on any
platform. Java was designed to let computers and devices communicate with
one another more easily than ever before.
The open standard for Java gives businesses cross-platform support

throughout the enterprise which includes the Web and more cost effective
ways to manage information. OS/390 positions itself as one of these Java
platforms with function equal to that available on any other platform.
5.3.3 Enterprise Resource Planning: SAP R/3

ERP solutions combine core applications, such as financial, production
planning, asset management, sales and distribution, office communication,
human resources, quality assurance and project planning into an integrated
system that can deliver a consistent approach to information throughout the
enterprise. In other words, ERP applications help create a seamless system
that permits employees to work together more efficiently throughout the entire
business cycle, from marketing and taking an order through shipping an order
and accounting for it. In today’s fast changing global business environment,
this integrated approach can be a key competitive advantage. The ability to
share information throughout the organization, as well as up and down the
value chain, helps permit an organization to get to market faster, improve the
availability of services, manage growth and control costs.
Building on an existing S/390 infrastructure can not only speed the ERP
implementation, it permits a company to benefit from the knowledge, skills
and procedures that exist in the data center to ensure a smoother, more
trouble-free transition. The traditional S/390 strengths are necessary
elements for an enterprise seeking to create flexible computing infrastructure
required for ERP solutions.
The major ERP application vendors have ported the central parts of their
solutions on S/390. Originally developed as client/server applications on
UNIX servers, ERP solutions usually are based on a three-tier architecture
consisting of the following:
• A database layer
• An application layer

• A presentation layer
While the presentation layer usually resides on a desktop machine, the

application and especially the database layers are natural for the reliable
S/390 environment.
One of the world’s most popular ERP applications is SAP R/3, a suite of
enterprise applications covering a broad range of business activities,
including finance, payroll and personnel, manufacturing, sales, distribution
and human resources. Originally running in a three-tier implementation on
UNIX platforms, the database layer has been ported to S/390, becoming
generally available in September 1997. This was in direct response to
customer requests that SAP R/3 harness S/390's proven strength for handling
mission-critical applications with large numbers of concurrent users. Figure
43 shows an overview of the SAP R/3 architecture.
RS/6000
S/390 Server
AIX
RS/6000 SP
OS/2
CF
AIX
PC Server
Windows
NT
Other NT...
MacIntosh Other UNIX...
Presentation Application Database

Servers Servers Server
Figure 43. SAP R/3 Database Server on S/390
In a three-tier R/3 configuration, platforms are used for presentation, running

applications, and the underlying database. The three layers are:
• User interface (presentation client)
The end user interacts with SAP R/3 through a presentation front end with
a graphical user interface. From here, the end user reads, interacts with
the application, or changes and creates new data. Users can access

several application servers at the same time. SAP R/3 currently supports
presentation servers on Windows, Macintosh and OS/2.
• Application logic (application server)
Presentation requests from the clients are sent to the application servers
that process SAP R/3 system transactions. The application server runs
these transactions and either reads data from local memory or initiates
database requests. In an R/3 system, each application server can be
defined as a logical group of users, such as a department or geography. A
large number of different application servers can work in parallel with one
another, accessing data stored in the database server. In order to spread
computing load as evenly as possible among the individual computers,
while optimizing overall performance, specialized application servers can
also be defined for certain areas. The supported applications servers that
work with the OS/390 database server run the following operating
systems:
• AIX 4.1.1 or later
• Windows NT
IBM and SAP are cooperating with other vendors to extend the S/390
database server for R/3 to be used with application servers running other
operating systems.
• Data management (database server)
The application programs and user data, including data and process
models, are stored on the database server. SAP R/3 on OS/390 uses DB2
as the database server, which can manage large amounts of data on
behalf of many users.
In a three-tier client/server environment, a high performance link between the

database server and the application server is critical to the performance of
SAP R/3. In the configuration where RS/6000 is the application server,
ESCON channels can be used to connect to the S/390 database server.
When the application server is a PC server running Windows NT, the
connection can be via an OSA-2 card in S/390 with an FDDI or a Fast
Ethernet LAN attachment. Both ESCON and OSA-2 provide extremely high
performance and high bandwidth to more than adequately support the
performance requirements of the SAP R/3 environment.
In addition to this hardware, a high performance software communications

link between application servers and the S/390 database server has been
developed and integrated into OS/390, built upon standard communication
protocols in the TCP/IP stack. Together, the hardware and software deliver
an environment for enterprise computing, satisfying the demands of the SAP
R/3 application.

In May 1999, a port of the SAP R/3 application servers to OS/390 was
announced, with general availability planned for January 2000. This will give
total flexibility to build an infrastructure that supports their unique
environment, using the combined strengths the different server platforms
offer, while at the same time exploiting the unique strengths of each; see the
left side of Figure 44.
AFA Batch w/ 14.000 Assets

Comparison of Execution Times
Database Approximately
Appl. + DB
40 %
Execution Time
DB
Application
Appl.
Appl.
UPDATE Dialog Steps
Comparison of avg. response times
Presentation Approximately
Avg. response time

70 %
GUI
GUI
S/390 options for SAP R/3
Database Network Application
Figure 44. SAP R/3 Application Server on S/390
For example, the continuous availability characteristics of S/390 lends

themselves to the mission-critical functions of the database server. S/390
may be used for other application functions such as enqueue, batch, update
and messaging. Dialog application server functions, on the other hand, can
exploit unique strengths from IBM's Netfinity or AIX servers and would be well
positioned on those platforms.
As shown in the right side of Figure 44, the S/390 applications servers can
provide significant performance improvements. In any SAP implementation,
there are multiple servers passing information, resulting in extensive network
overhead or latency. As the databases grow, this become more of a
bottleneck. The most affected applications are those that execute massive
database calls, such as batch and update. Due to its unique implementation
of DB2, S/390 is the only server that can host the application while
eliminating network lapse times, just using cross-memory services between
address spaces. Compared to a physical three-tier design, this
implementation can result in a 40 percent performance improvement in batch
mode. Coupled with dynamic update capabilities of the S/390 and Workload
Manager, the update improvements can be an even more dramatic 60
percent.

For this reason, the following SAP R/3 application server functions gain the
greatest benefits from being migrated to S/390:
• Workloads that are business-critical: SAP R/3 Enqueue
• Workloads that are database-intensive: SAP R/3 Batch
• Workloads that process large volumes of transactions: SAP R/3 Update
• Utilities that update the R/3 system landscape such as installation of new
R/3 systems, upgrades to new versions of R/3 and client copy operations
• Spool workloads which can exploit the OS/390 printing subsystems
• R/3 applications which benefit from tight integration with existing OS/390
applications
Coupling the reliability, availability, scalability and security of S/390 with the
proven attributes of DB2 ensures that SAP R/3 applications are always
available when users need them. SAP AG and IBM have come together to
combine the most popular suite of client/server applications on the most
powerful and reliable platform in the world. More information about SAP R/3
on S/390 are provided in the redbook Implementing SAP R/3 in an OS/390
Environment: AIX or Windows NT Application Servers, SG24-4945 and the
SAP brochure SAP R/3 on OS/390, May, 1999.
5.3.4 Enterprise Resource Planning: BaanERP

BaanERP is part of the Baan Series Product. BaanERP applications include
manufacturing, finance, project, distribution and service. As with SAP R/3, the
Baan architecture consists of a presentation layer, an application layer and a
database layer. The presentation layer presents information to the end user
through a variety of user interfaces. Users can access several application
servers at the same time. BaanERP runs on OS/390 in a two-tier
environment, which means the application logic and database logic run easily
on the same server. The presentation clients run on Microsoft Windows, Web
browsers and ASCII terminals connected via UNIX machines. The two-tier
environment on S/390 enterprise servers can help reduce complexity by
simplifying system management and can help trim costs by reducing
personnel needed to manage multiple servers. A detailed description of the
BaanERP application and its implementation is provided in the redbook
Installing BAAN IV Applications on OS/390, SG24-5334.
5.3.5 Enterprise Resource Planning: PeopleSoft

The PeopleSoft ERP applications that have been ported to S/390 include the
suites for human resource management, financial, distribution, student
administration and manufacturing. As with the other ERP solutions, the

logical three-tier structure includes a database layer, an application layer and
a presentation layer. The applications are designed so it is transparent to
users which platform their data resides on or their application execute on.
There is no application functionality difference among the supported
platforms. In the implementation on S/390, DB2 serves as the Relational
Database Management System (RDBMS) used for PeopleSoft. The
Application Server can be UNIX or NT. The files on the Application Server
contain most of the online application logic. This tier sends SQL queries to
DB2 and maps the results to the client. Both thin clients and Web clients are
supported. If desired, both can be reside in the same Application Server,
which results in a physical two-tier implementation. The Application Server
communicates with the client using BEA’s Tuxedo program. PeopleSoft ERP
applications on S/390 are described in detail in the redbook Installing
PeopleSoft on OS/390 with DB2 , SG24-5156.
5.4 File and print interoperability in a heterogeneous environment

File and print serving is a large contributor to the problem of server
proliferation. While more expensive than PC desktops, PC servers can be
very inexpensive when compared with UNIX, S/390 or other servers. Network
operating systems such as Novell NetWare and Windows NT are fairly easy
to set up, learn and use. Once in place, it is then easy to share disk drives or
printers over the network for small workgroups, such as a single department
or team. However, as these islands of data and print services grow, both in
age and in size, problems arise in the following areas:
Backup and recovery Sometimes there is a formal backup procedure for
these servers but often it is informal or
non-existent. When data is lost it often cannot be
retrieved in a timely manner, or at all.
Availability and reliability As the file and print services offered by these
servers become more valuable, the need for them
to be continuously available becomes
correspondingly more important.
Access and Security The administrative burden of ensuring the proper
access and security also grows, or security is
abandoned in favor of easy access.
S/390 offers solutions to these problems because of its heritage of strength in

these areas. While some of the solutions available on S/390 do offer the
opportunity to truly consolidate servers, other solutions simply allow S/390 to
operate in a networked, heterogeneous environment.

The solution to be investigated is largely determined by the type of network
operating system predominant in the enterprise. For the ease of
classification, let us divide the world into three types of enterprises or
“shops”.
The Novell shop Utilizes PC servers running Novell NetWare. Novell
Directory Services (NDS) is probably being used to
administrate users, drives and printers, however
Bindery Services may supply this administration if
NetWare 3 is still in use.
The Windows shop Utilizes PC servers running Microsoft Windows NT.
The UNIX shop Utilizes UNIX servers running Sun’s Solaris, Hewlett
Packard’s HP-UX, IBM’s AIX or some of the many
other “flavors” of UNIX.
For each of these types of shops, the solution or solutions available on S/390
is described in the sections that follow.
5.4.1 Novell style file and print serving

LANRES is a S/390 product that provides a file and print solution for
enterprises with Novell Netware servers. It is an acronym that stands for
Local Area Network Resource Extension and Services. LANRES is provided
as a standard no-charge feature of MVS 5.3, VM/ESA Version 2 and
VSE/ESA Version 2, but can also be ordered separately on previous versions
of MVS, VM/ESA and VSE/ESA. It is now an integrated function of OS/390.
LANRES is a three-tier client/server utility which allows the NetWare server to

make use of host services. Part of the LANRES code resides on the NetWare
server and part resides on the S/390 system (MVS, VM or VSE). NetWare
provides disk and print serving facilities to LAN-attached clients/workstations.
LANRES extends these services to the S/390 providing the functions shown
alongside. LANRES complements existing NetWare functions and is totally
transparent to the NetWare LAN users.
The function of LANRES can be categorized into four areas.

Disk serving The LANRES disk serving function extends the storage
resources of the attached NetWare server to utilize
S/390 DASD. Through LANRES, NetWare clients can
use MVS, VM or VSE system DASD for file storage. As
far as the NetWare file server is concerned, the
allocated host DASD space is just another hard drive or
set of hard drives.

Data distribution LANRES data distribution commands allow host files to
be distributed to, and retrieved from NetWare file
servers. These and other LANRES functions can be
automated using a command language such as REXX.
LAN administration The LANRES administration function provides the ability
to perform NetWare administration activities from the
host system. This includes such activities as adding and
deleting LAN userids, changing passwords, and so on.
Printing With LANRES LAN-to-host print function, NetWare
clients can transparently utilize host system printers,
just as if they were other NetWare controlled printers.
Host-to-LAN printing allows host print jobs to be printed
on NetWare LAN printers.
5.4.1.1 NetWare to host connectivity and communication

The physical connectivity between the NetWare server and the S/390 host
can be:
• Direct channel link
• Token-Ring or Ethernet via SNA or TCP/IP gateway
• Other gateway link supporting SNA or TCP/IP
Figure 45 on page 107 shows a high-level view of some of the possible

network configurations that can be used with LANRES.
The Direct channel link is from the PC or an IBM 3172-3 (LAN-to-S/390

gateway) on which the NetWare server resides. PC channel connectivity is
achieved by installing a PCI-ESCON card (machine type 9663-001, part
number 51H8700). ESCON links support speeds up to 17 MB/s. The previous
Micro Channel to mainframe cards (“MMC card”, part number 31G9211) are
no longer available. Though attachment to a parallel channel will still work, it
becomes an issue due to the lack of availability of this card.

S/390
Disk
Serving
Host-to-
Host
LAN
LANRES
Printing LAN-to-
Host
NetWare
Printing
Server
LANRES
NLMs
NetWare
Server
Figure 45. LANRES configuration
The direct channel option requires no external communication protocol such

as SNA or TCP/IP. It also provides the potential for very high performance.
The recommended option for most customers considering a LANRES
implementation is to use the PCI-ESCON option. This provides the best
performance and uses the least amount of CPU resources. With this option,
the NetWare server needs to be local (that is, within ESCON distance), but
this local server can be used as the link to other NetWare servers which may
be local or remote.
To use SNA (APPC) communications, the appropriate VTAM/ESA product is

required on the host system and NetWare for SAA is required on the NetWare
Server.
5.4.1.2 Novell Network Services for OS/390

In addition to LANRES, the function known as Novell Network Services (NNS)
was made available as of OS/390 V2R6. Its main function is to provide Novell
Directory Services (NDS).

NDS provides a global naming service distributed across the entire NetWare
network with a single point of administration. Users log into the directory tree
and, with appropriate rights, have access to any resource on the network
regardless of physical location. It provides a distributed information service,
scalability and reliability due to partitions/replicas, and a single sign-on with a
single point of identification to the network.
For customers who have large distributed NDS servers, NNS for OS/390
could allow multiple NetWare servers to be consolidated.
5.4.1.3 Novell style file and print serving summary

The LANRES solution offers a potential for file and print server consolidation.
It is especially attractive to the enterprise that has an existing Novell Netware
and NDS infrastructure. There is a favorable reference to LANRES in the
META Group paper entitled Enterprise Data Center Strategies, April, 1999.
The function Novell Network Services is a new possibility for enterprises that
have decided NDS is their directory services solution and want the reliability,
scalability and security of S/390.
5.4.2 Windows Style file and print serving

Whereas LANRES is the obvious choice for S/390 file and print serving in
Novell shops, the Windows shop has more available solutions which all share
the common thread of the Server Message Block (SMB) protocol. Each of
these solutions has different pasts and futures.
LAN Server A legacy three-tier solution, similar in architecture to LANRES,
but utilizing a mid-tier server running OS/2.
Samba A tactical two-tier solution for OS/390 and a possible long-term
solution for VM. It consists of an open source software package
which enables UNIX servers to share disks and printers.
DFS/SMB A new strategic two-tier solution for OS/390. It provides nearly
the identical function that Samba does, but will be built in to the
operating system.
PC clients use SMB function included with their operating systems to access
shared directory paths and shared printers. SMB clients include Windows 95,
Windows 98, Windows NT, Windows 3.11 and OS/2.
5.4.2.1 LAN Server

LAN Server provides workstation file system services on a host system. It
uses host disk storage to provide file sharing services to workstation users on

LANs. The LANs can either be OS/2 LAN Server environments (Version 3 and
upwards) or TCP/IP environments using Network File System (NFS) services.
With MVS/ESA Version 5.2.2 and OS/390, LFS/ESA is included with

MVS/ESA at no-charge and is known as 'LAN Server for MVS.' The same
facility exists on VM/ESA Version 2.
In an OS/2 LAN Server environment there are two pieces of LFS/ESA code:
• That on the S/390 host
• That on the OS/2 LAN Server, known as the Front End Processor (FEP)
There are many details that could be included to describe the function offered
by LAN Server, however, the future of this product is limited. With the decline
in popularity of the OS/2 operating system, the strategic value of this solution
suffered a corresponding decline. OS/390 V2R9, targeted for March of 2000,
will be the last release in which the product will still be offered and support
will continue for three years after that. Another factor that could reduce the
future functionality of LAN Server is the fact that OS/2 V4.5 (Warp for
e-business) will not be supported on the FEP. Due to these issues, LAN
Server should not be viewed as a strategic LAN data consolidation solution.
5.4.2.2 Samba for OS/390 and VM

The open source software package Samba has been separately ported to
both OS/390 and VM. Samba provides file and print sharing from Windows,
DOS and OS/2 desktops, via SMB, which utilizes the lower level protocols
NetBIOS over TCP/IP. When a hierarchical file system is shared from UNIX
and accessed on a Windows desktop, this shared resource (or simply
“share”) appears as a disk with a new drive letter, and the computer offering
the share appears as an icon in the Network Neighborhood window. Samba
also gives the user the ability to print on S/390 printers from LAN clients.
The Samba port for VM is discussed in the redbook Porting UNIX

Applications to OpenEdition for VM/ESA , SG24-5458. This book is on the
Web at:
http://www.redbooks.ibm.com/abstracts/sg245458.html
IBM contracted with Mortise Kerns Systems (MKS) to port Samba V1.9.18p1
to OS/390. That port was completed in the first half of 1998. Since the
changes were not put back into the Samba source code stream, this specific
port, and not another from the Samba Web site, is necessary. The code can
be obtained from the MKS S/390 GNU Web site at
http://www.mks.com/s390/gnu/

For details on downloading, building and using this package, see the redbook
File Server Consolidation on OS/390 , SG24-5330. This book is on the Web
at:
http://www.redbooks.ibm.com/abstracts/sg245330.html
Since DFS/SMB offers the same function as Samba, Samba is only

recommended for customers who cannot implement DFS/SMB.
5.4.2.3 DFS/SMB for OS/390

The OS/390 Distributed File Service/Server Message Block (DFS/SMB)
support provides a server that makes hierarchal file system (HFS) files
available to SMB clients over TCP/IP. In addition, Windows SMB clients can
make remote print requests to OS/390 printers that are connected to the
InfoPrint Manager for OS/390. This service is planned for, but not guaranteed
to ship with, OS/390 V2R9, which is scheduled for general availability in
March 2000. This solution will be the strategic method of supporting file and
print sharing to Windows desktops.
The appeal of this solution is its simplicity. Since all modern Windows
desktops have the ability to “map network drives” (act as SMB clients),
DFS/SMB will allow Windows desktops to access OS/390 UNIX hierarchical
file systems.
DFS/SMB and Security

DFS/SMB security will be handled by RACF. To be authenticated for access to
HFS data, the user will have to supply a valid OS/390 user ID/password pair.
Windows clients running Windows 95 OSR 2 or later, or Windows NT 4,

service pack 3 or later transmit passwords over the network that are
encrypted using the Data Encryption Standard (DES). Since RACF currently
does not handle DES encryption, encrypted passwords from Windows clients
cannot be accepted. To remedy this situation, the clients must be instructed
not to perform the encryption via a registry setting. Also, RACF security
cannot be bypassed as it can with Samba. This limitation is recognized as a
requirement and in the future, DFS/SMB should be able to accept DES
encrypted passwords, though no guarantees for this function are made.
DFS/SMB and ASCII/EBCDIC translation

ASCII-to-EBCDIC translation is handled in a way similar to the Web Server
(WebSphere Application Server). A configuration file is read by DFS/SMB,
which sets the nature of files based on their extension (or suffix). The main
attribute that is important here is whether files are text or binary. Once
configured properly, the translation of text files between ASCII and EBCDIC is

done on the fly by DFS/SMB. Details of this function will be available in the
DFS/SMB manuals.
5.4.3 UNIX style file and print serving

The Network File System (NFS) was created in the early 1980s by Sun
Microsystems. It is a client/server protocol that allows a client to see files on a
server as if they were local to the client. NFS is a standard part of all UNIX
systems and is provided on other non-UNIX platforms either as a standard
part of the TCP/IP stack or as an add-on or third-party feature (NFS clients for
Windows NT/Windows 95 from NetManage and Hummingbird). Figure 46 on
page 112 shows an overview of the NFS configuration with the OS/390 NFS
server.
The OS/390 NFS server supports the following types of datasets.

• Sequential, including extended format
• Partitioned, either PDS or PDSE
• Direct access
• VSAM (KSDS, ESDS and RRDS)
• UNIX system services HFS files
The datasets can be system-managed (SMS) or non-system managed,

excluding HFS datasets, which must always be system-managed.

MVS/ESA or OS/390
(OpenEdition)
mount
NFS OS/390 NFS Server
TCP/IP
clients
TCP/IP network
includes HFS Access Methods

AIX
OS/2
DFSMS NFS client
HP/UX
SunOS / Solaris
Windows w/added
software
hierarchical MVS data sets
files
Figure 46. NFS configuration
5.4.3.1 The NFS mount command

Most PC LAN users will be familiar with the concept of logging on to a LAN
file server and then being able to access part or all of the LAN server disks as
if it were one or more local drives (for example, the F:\ and H:\ drives). These
are commonly referred to as remote drives or network drives and the
underlying “link” commands are those such as MAP or NET USE. As
previously discussed, in a UNIX environment there is no concept of a local
drive (for example the F:\ drive), or remote drives. There is just a hierarchy of
files located in a file system. Of course, there is still the same need to link to
other LAN machines. The process used in the UNIX environment is the
“mount” process. In Figure 47 on page 113, the illustration shows that Fred
wants to access files in Jack's home directory on the OS/390 system named
“bigboy”. Fred wants data on this remote link to appear as if it stemmed from
a directory he created named “jackdir”. To effect this link, Fred would issue
the mount command as shown. In this example, /u/fred/jackdir is an empty
directory known as the local mount point . NFS clients on a PC with additional
NFS client software, rather than a UNIX base, would use a drive letter (for
example, the M:\ drive), as their local mount point in a similar way to using a
normal LAN file server.

bigboy UNIX client
(root)
(hfs root) dev u bin temp
dev u bin temp mary fred
mike jack jackdir mydata
bean stalk bean stalk
mount bigboy:/hfs/u/jack /u/fred/jackdir
Figure 47. The NFS mount command on a UNIX client
Files in the HFS appear as a file system, so the NFS mount process is as it
would be on any other UNIX system.
Conventional MVS datasets, on the other hand, do not naturally fall into any
hierarchy, so OS/390 NFS uses dataset qualifiers as if they were directories.
For example, assume an NFS mount is made to the NFS server on OS/390
with a high level qualifier of “FRED” and that there are two datasets:
FRED.ONE.TWO, a sequential dataset, and FRED.THREE, a partitioned
dataset. The first dataset would appear to the NFS client as a file called
ONE.TWO and the second as a directory called THREE with the PDS
members as files within it.
OS/390 NFS and security

The NFS server can be run in several security modes but the most common
way is using the SAF (for example, RACF) interface. Included in OS/390 NFS
is client-enabling code. This code provides commands to enable the NFS
client to login to (or logout of) MVS with a valid RACF user ID and password.
These commands are primarily for UNIX clients and are named mvslogin and
mvslogout. For PC clients, the PC Network File System Daemon (PCNFSD) is

a more appropriate mechanism. The NFS server runs a PCNFSD task and
PC clients include user ID and password information when the mount process
is invoked using the PCNFSD protocols.
The OS/390 NFS client

An NFS client is also provided with OS/390. Each OS/390 system with the
NFS client can read from or write to any remote NFS server platform on a
TCP/IP network. This client also enables one OS/390 system to actively
share data with another OS/390 system. The OS/390 NFS client support
operates under UNIX services. This allows applications which use the UNIX
services interfaces to utilize the NFS client functions with few changes to
those applications. By extension, this also enables conventional BSAM,
QSAM, VSAM applications, in addition to UNIX services applications and
users, to have transparent access to data on any remote NFS server
platform.
5.4.4 Data backup and recovery - Tivoli ADSM

ADSM is an acronym for Adstar Distributed Storage Management. This
client/server application now falls under the Tivoli product umbrella and is
correctly referred to as Tivoli ADSM. For brevity, it will be just be referenced
using the short name, ADSM.
As shown in Figure 48 on page 115, ADSM is an enterprise-wide storage

management application that provides automatic backup and archive
services to multivendor workstations, personal computers, and LAN file
servers. Based on customer-decided criteria, ADSM determines what data to
back up or archive, where to store it, and how long to retain it on central
storage media.
Because data protection requirements may vary, ADSM can be set up to treat
data differently. For example, assume that LAN server data is classified as
either critical or standard. ADSM can be easily configured to maintain four
backup versions of critical data files, but only maintain two versions of
standard data files. Additionally, when critical files are deleted (either
intentionally or accidentally), ADSM could be configured to retain backup
copies of these for several years, whereas backups for deleted standard files
might just be kept for two months.
With central scheduling, ADSM provides “lights out”, unattended backup and
archive operations. These operations can be scheduled to complement
ordinary workflow. Backups can be scheduled during off-peak hours to
maximize network performance.

AIX/6000 DOS
ADSM
Server
Windows
OS/2 MVS Windows/NT
AIX
VM OS/2 Dec
VSE -Ultrix
AS/400
Novell
Netware
Mac
SCO Sun
UNIX
Figure 48. ADSM overview
5.4.4.1 Administration ease and flexibility

Administrators can manage an ADSM server from any administration client in
the network by using a powerful, yet easy-to-use graphical or command line
interface. ADSM tracks the location of backed-up files, eliminating the need
to keep records or to sort through diskettes or tapes at recovery time. ADSM
also provides statistics which include the status of scheduled operations, the
amount of data backed up by each client, and the amount of space used by
an ADSM server.
ADSM supports over 30 different client systems today covering the Intel (for
example, DOS, Windows, Windows 95, Windows NT, NetWare and OS/2),
UNIX (for example, AIX, HP-UX, SunOS, Solaris, SGI and so on), Apple
Macintosh and other operating platforms.
The ADSM server/repository can be run on a variety of platforms. Most large

organizations will find that an MVS, VM or VSE server provides the
appropriate level of performance, capacity and management control for their
needs. As many organizations are coming to realize, it is no good to store
vast quantities of data if it cannot be accessed and recovered when needed,
and if it cannot be easily managed. For backups of large quantities of data, a
reliable, scalable solution is needed.

The performance and capacity of any system is very dependent on that of its
I/O subsystems. No other platform can match the potential capacity and
performance of an MVS- or VM-based I/O subsystem. For example, PC-style
DAT tapes and tape units, although they may be able to store many gigabytes,
cannot match the data access speed of mainframe devices like 3490s and
associated tape libraries (for example, 3494 and 3495s). An enhancement to
these facilities is the IBM Magstar 3590 tape product. This provides up to
three times the data transfer rate and more than ten times the storage
capacity of the 3490E half-inch tape drive, and more than fifty times the
capacity of the widely used IBM 3480 technology. The Magstar 3590 can be
used as a standalone tape system or as part of the IBM 3494 and 3495 Tape
Library Dataservers.
5.4.4.2 ADSM application client

Another client available with ADSM is called the application client (ADSM
API). This client runs on AIX, Windows, HP-UX, Sun and OS/2 and uses a
callable interface for applications to use the storage management services of
ADSM. Applications can use ADSM to backup and archive their own objects,
without ADSM having to know their structure and whether they are consistent.
Through the ADSM API, ADSM can be used to back up leading databases
such as DB2, Sybase, Oracle, Informix and applications such as SAP R/3 and
Lotus Notes. This enables ADSM to back up files, databases and applications
consistently and reliably across the entire enterprise.
5.4.4.3 ADSM Version 3

ADSM Version 3 for MVS has been available since 1998. It includes many
new features and enhancements designed to cope with the emerging trends
impacting storage management. Storage requirements continue to grow at a
very rapid rate, doubling every year in some organizations, as indicated by
multi-gigabyte file systems growing into terabyte file systems and increasingly
large enterprise-wide databases. This data explosion has major implications
on the way systems handle storage management, especially since the cost of
managing distributed storage can be eight times the cost of the hardware,
and labor can often account for 65 percent of the cost.
ADSM Version 3 builds upon the strengths of Version 2 and addresses some
of these emerging trends. The main enhancements for ADSM Version 3 are:
• It provides improved performance to back up and restore increasingly
large databases and file systems with a shrinking or nonexistent backup
window. This includes new data transfer mechanisms such as “fat pipes”
and “small file aggregation”, enhanced restore performance and fault
tolerance features.

• It provides improved usability through facilities to easily navigate through
large file systems, new GUI interfaces, and Web browser access to
perform backup, restore and administrative functions.
• It provides new control through features such as central logging of client
events, SQL reporting, defining client options at the server, integration
with systems management products like Tivoli, and server-to-server
communication. Server-to-server communications lets you exchange data
between ADSM servers, either peer-to-peer or via a hierarchy. This feature
can be used for “electronic vaulting” for disaster protection, or to share
storage resources such as large tape libraries attached to other ADSM
servers.
• It provides ADSMConnect agents to back up leading databases and
applications online.
5.5 Sizing servers - how many S/390 MIPS per server MHz
Server workloads to be consolidated onto S/390 come from machines of
different architectures, vendors and operating systems. This leads to the
need for cross-vendor capacity comparisons. How to make such a
comparison has always been a difficult problem. At best, relative capacity can
be indirectly estimated using means which all vendors will claim are invalid. A
precise capacity comparison can be made only in head-to-head comparisons
of machines running the proposed workload.
There are various sizing tools and methods which have been developed for
specific applications such as SAP, Lotus Domino, Web applications,
PeopleSoft and so on that can help determine the size of the server on a
specific platform.
There is a need for estimating relative performance and capacity of machines

with diverse architectures. Processor speed is not a significant differentiator
since all the processors are fast and improve at similar rates. Because of the
significant differences between servers and S/390 in internal bandwidth and
the ability to manage workloads, the scaling between them cannot be
determined by a single benchmark; rather, a series of measurements which
calibrates workload dependencies must be used.
5.5.1 Using standard benchmarks

A number of attempts have been made to characterize different
manufacturers′ systems by means of both proprietary and
vendor-independent benchmarks. Many of these methodologies have been
designed to minimize the high cost of equipment and people in the

benchmarking process, rather than to provide the benchmarking environment
that most closely matches real workloads. Figure 49 shows popular industry
benchmarks common today.
The industry-standard TPC-C benchmark is currently the choice for most

UNIX vendors. It is being criticized by users for being too unrepresentative of
commercial environments, and too easily tuned. A new version of TPC-C is
planned by the Transaction Processing Council in the year 2000.
Benchmark Sponsor Type Range of Applications

TPC-C TPC Moderately Commercial OLTP
complex OLTP
TPC-D TPC Decision support Business Intelligence
TPC-W TPC OLTP web serving e.Commerce
SPECint95 SPEC Integer processing Relative processor speed
SPESweb96 SPEC Web serving Web serving
Linpack Jack Dongarra, Linear algebra Technical computing

University of
Tennessee
Baan Baan ERP Baan ERP
SAP R/3 SD SAP AG ERP SAP R/3 ERP
Notesbench NotesBench Groupware Groupware

Consortium
Figure 49. Popular industry benchmarks
In running TPC-C benchmarks, vendors often tune the system and database
to achieve close to 100 percent utilization. This can be done by ensuring that
there is no skew in database usage or regular transaction arrival patterns,
and minimal interference between the multiple engines in a symmetric
multiprocessor (SMP), so that cache contents can be reused without a need
to refresh them. For example, in UNIX systems, it is often possible to stop
running functions that are not needed for the benchmark. Unfortunately, in a
real production environment, such functions would be needed; you may not
have the luxury of stopping them. In contrast, OS/390 has many of these

functions integrated, so they cannot be stopped to achieve a better
benchmark result.
The result is that most UNIX systems running real commercial workloads
cannot achieve the transaction throughputs and processor utilizations that the
TPC-C results would indicate. Also, the additional throughput expected by
adding engines to an SMP is often much less in reality than would be
expected from such benchmarks.
The SAP R/3 SD benchmark addresses some but not all of the issues with
the TPC-C benchmark. There is significant data sharing and more data
movement in the benchmark, but there is still no batch report workload
included.
Microprocessors of a given vintage perform about the same on a

CPU-intense environment, but as more data sharing, data movement, and
reporting work is done, the differences in hardware architecture of the various
server systems start to spread their relative capacity. This means that
machines with the same transactions per minute (tpmC) metric will show a
spread in SAP R3 SD users. The spread widens as the workload becomes
more data intensive, the number of users grow, or the data sharing causes a
reduction of the cache hit rate beyond that shown in the benchmark.
System throughput for a given application depends on the subset of

instructions used (different instructions run at different rates), the use of
processor cache, the I/O usage, and the particular database manager (such
as DB2, VSAM, IMS/DB). Thus, processor capacity cannot be accurately
represented by a value for a single workload type. Extensive measurements
and experience with the S/390 have shown that when comparing it to
competitive UNIX servers in a TPC-C benchmark, there is a spread factor of 2
and it increase up to 6 for more data-intense, mixed workloads.
Different workloads also show differing scalability as the number of engines in

an SMP increases. Awareness of this variability is an important consideration
in evaluating the capability of different vendors ′ server platforms for any given
application.
IBM has specialists in the field of sizing S/390, UNIX and NT servers.

5.5.2 Why Not Use MIPS
A complicating factor in making processor comparisons is the different units
of measurement used by different vendors and consultants, such as:
MHz The speed of processor chips, often used for personal computers
and UNIX servers.
MIPS Millions of instructions per second, often used by consultants for
IBM S/390 processors and compatible machines.
ITR Internal Throughput Rate, used by IBM for its S/390 processors
The key to understanding the different terms is that what you need to know is
how much workload a particular machine can process relative to other
machines. This is exactly what ITRs tell you, and the results are numbers of
transactions per second or numbers of batch jobs per hour. Where other
measurements give you the same thing, they are useful to you in performance
comparisons. Where they do not, they are not.
Now what about MIPS? Many vendors make MIPS claims based on cycle
time in nanoseconds:
1000
MIPS = --------------------------------------------------------------------------------------------------------
cycleTime × ( ( cycles ) ⁄ ( instruction ) )
But using cycle time does not allow for valid comparisons between
processors with different types of architectures. To illustrated this, suppose
you want to buy a car, and are interested in how fast it can go. The
information you need is the top speed of the car. However, the MIPS rating
tells you the maximum Revolutions Per Minute (RPM) of the engine. That is
not a good measure of the top speed, since it totally ignores the gear ratios.
For processors of the same type (same gearing ratio), the MIPS rating may
be fairly representative. However, it is of very little value when comparing
processors with different base architectures.
For processors using reduced instruction set computer (RISC) architectures,

the number of instructions per cycle is usually one or less. For such
processors, the MIPS rating can be very high. However, the philosophy
behind the RISC architectures is that complex tasks are run using many
simple, short instructions. By contrast, a complex instruction set computer

(CICS) has more complex instructions, which do the work of many simple
instructions. A CISC machine can therefore run at a lower MIP rate (RPM)
than a RISC machine and still do the same amount of work, since each
instruction is more powerful (the gear ratio is higher). Comparisons between
different types of machines can therefore be very inaccurate if MIPS ratings
are used.
5.5.3 A suggested methodology to estimate relative capacity

So how can potential users estimate the relative capacity of different server
platforms? The following guidelines will help:
1. Use benchmarks of real commercial workloads if available. Check how
closely the measured workload matches the target workload. The closer
the match, the more accurate the benchmark results are likely to be in the
production environment.
2. Use standard benchmarks only with extreme caution. Allow for the fact
that they are probably tuned, and divide by a factor to give an estimate for
a real workload. The factor is likely to be less for S/390, since S/390
comes with the facilities needed to run a real commercial workload as
standard.
3. Estimate the power of SMPs compared to the uniprocessor in the range
using published benchmarks or published numbers of users supported on
each system. Do this only within a range of processors, not between
ranges.
4. For platforms that cannot run close to 100 percent utilization with good
response times, lower the capacity rating accordingly. For example, most
UNIX servers run at around 50 to 60 percent utilization for typical
commercial workloads, in order to provide good response times. In
addition, where there are multiple servers, their utilization is typically
different at different times of the day. It is difficult to plan the capacity of
multiple servers such that they are all running to capacity at the same
time. Therefore, the average utilization is less than the maximum
utilization of any one server. Because of these two factors you need to
reduce the capacity estimate for UNIX servers.
5. Check the sensitivity of your results. Without solid performance
measurements, the true performance of a configuration can be lower by a
factor of two to even ten when estimates are based on assumptions.
6. If possible, get a performance guarantee from the vendor to share the risk
of inaccurate estimates or bad assumptions.

5.6 S/390 Software pricing overview
S/390 delivers a comprehensive set of software pricing initiatives that
facilitate the growth of new and traditional workloads (Enterprise Resource
Planning, Business Intelligence, e-business and Server Consolidation) on the
S/390 platform. There are several pricing methods for OS/390, including
Parallel Sysplex License Charge (PSLC) and Usage Pricing Charge for
traditional workloads, as well as New Application License Charge for
qualifying new workloads. VM and VSE continue to be priced on a Graduated
Monthly License Charge methods, with Multiple Operating System Pricing
available for systems running two or more operating systems (VM,VSE,
OS/390 or TPF).
All S/390 pricing structures are based on Millions of Service Units (MSU), and
processor capacity; following are more detailed explanations of non-PSLC
price structures.
• Entry Level
• Entry Server S/390 One Time Charge
• CPU potential capacity fewer than 80 MSU Graduated Monthly License
charges
• Basic License
• Distributed Systems License Option (DSLO)
• Multiple Operating System PR/SM (MOSP)
• CPU potential capacity more than 80 MSU
• Indexed Monthly License Charge (IMLC)
• Extended License Charge (ELC)
• New Application License Charge - this pricing method is to be used for
dedicated new workloads (that is, SAP, Baan, Domino) and typically do
not need the full suite of OS/390 products.
Note that features discussed may not be available in all countries. Consult
your local IBM business contact for information on services available in your
area.
5.6.1 Parallel Sysplex license charge

Parallel Sysplex license charges are based on processor capacity as defined
in terms of Millions of Service Units (MSUs) per hour. This provides a
consistent measurement across all processor types. Parallel Sysplex license

charges are available for qualified Parallel Sysplex clusters or for eligible
single system processors running OS/390 or eligible MVS versions.
Parallel Sysplex — actively coupled environment cluster

In an actively coupled Parallel Sysplex, multiple qualifying machines are
coupled together to make up a single Parallel Sysplex cluster. Software
charges for products in an actively coupled Parallel Sysplex cluster are based
on the total MSU value for only those machines running those products. With
identical software products, this provides you the flexibility to grow your
workload either horizontally or vertically within a sysplex and experience
similar incremental software costs. This also provides more flexibility to run
your applications where it best meets your operational needs.
The Parallel Sysplex pricing structure is designed to provide improved price

performance as you grow your Parallel Sysplex clusters. Parallel Sysplex
license charges are based on a per MSU price, and software costs increase
in more granular increments as hardware capacity grows, than with GMLC
structures associated with VM and VSE. The Parallel Sysplex pricing
structure consists of a base charge, plus one price per MSU level (Level A,
Level B, Level C and Level D). As the capacity grows, each level offers
increasing price performance. Levels C and D are available for OS/390
Version 2 and associated software products. Level C applies to large Parallel
Sysplex clusters and single system machines above 175 MSUs. Level D
applies to large Parallel Sysplex clusters and single system machines above
315 MSUs.
Single system configurations

Parallel Sysplex license charges are also available for single system
configurations. Software license charges for products running in this
environment are based on the MSU value of the machine. As in an actively
coupled Parallel Sysplex cluster, the software charges for a qualified single
system also provide improved price performance as your capacity needs
grow.
5.6.2 S/390 Usage Pricing

IBM’s S/390 Usage Pricing offers an attractive alternative to Parallel Sysplex
license charge for those customers growing new workloads, or moving stable
work to larger processors. It provides a competitive mechanism to deploy new
workloads across an enterprise, with the system capacity needs growing over
the multiyear rollout. Usage pricing gives you the option to avoid increases in
software charges for subsystems whose use is not growing in proportion to
the more heavily used subsystems.

S/390 Usage Pricing delivers improved entry-level prices, enhanced
granularity, and a price performance structure similar to existing PSLC. In
most cases, S/390 Usage Pricing provides improved price performance for
subsystems with peak utilization below 25 percent of measured capacity.
S/390 Usage Pricing makes use of functions within the software to measure
and record the CPU service units utilized. When licensing software under
S/390 Usage Pricing terms and conditions, you measure the usage levels and
provide a report to IBM to determine initial pricing. The measurement
technology must remain active so that usage statistics continue to be
collected throughout the entire year. At the end of the year, all usage records
for the processor or group of processors in the Parallel Sysplex cluster are
analyzed and you send the new usage report to IBM. With reports required
only once a year, S/390 Usage Pricing makes budgeting more predictable
and reduces administrative tasks.
5.6.3 Entry server S/390 one time charge

For our entry machines, the P/390, R/390 and the Integrated Server, a
separate one time charge licensing option is available
5.6.4 Basic licenses

Full entitlement licenses may include a money-back guarantee or testing
period, problem reporting and a standard complement of program updates
(release and service) directly from IBM to the basic license location.
5.6.5 Distributed Systems License Option (DSLO)

DSLO licenses are available at a reduced charge. These licenses do not
receive entitlements directly from IBM. Problem reporting and distribution of
all program materials are handled by the customer from the basic license
location. Testing periods or software guarantees are not applicable.
5.6.6 Multiple Operating System PR/SM (MOSP)

MOSP options are available on qualifying machines that have the PR/SM
processor feature, or equivalent, for non-IBM processors, installed.
Additionally, there must be at least two different operating systems running
concurrently on the same processor.
5.6.7 Indexed Monthly License Charge (IMLC)

IMLC for software running on large capacity, single system machines is
based on potential processor capacity. For IMLC pricing, potential capacity is
defined in terms of MSUs per hour. IMLC pricing is for OS/390 or MVS

software running on single system machines with capacity greater than 80
MSUs.
5.6.8 Extended License Charge (ELC)

Extended License Charge (ELC) provides the pricing structure for VM and
VSE software applicable to processors with potential capacity above 80
million CPU Service Units (MSUs).

Appendix A. Server consolidation case studies
This appendix discusses some recent success stories of consolidating

servers onto S/390. Often there are only one or two servers consolidated,
and sometimes there is simply the potential for consolidation.
A.1 Successful Domino on OS/390 consolidation

The following example illustrates a customer that successfully consolidated
Windows NT boxes running various mail servers onto OS/390 running Lotus
Domino.
A.1.1 Business need

A large US insurance company needed a robust, scalable system to support
Lotus Domino applications and Lotus Notes e-mail. They also needed to
consolidate a variety of e-mail servers because maintaining multiple e-mail
systems, servers, and gateways was becoming complicated and expensive.
A.1.2 Description of solution

The company implemented Domino for S/390 V4.6.3A under OS/390 V2.6
running in the single production LPAR on the installed 9672-R64. The
production LPAR also supports the data warehouse, IMS transaction
processing, and other key business applications. Domino for S/390
application development is performed in a separate LPAR along with Y2K
testing and other quality assurance testing. There are two marketing
applications based on Domino for S/390 in production with approximately 30
users. The company has also migrated approximately 100 Notes e-mail users
from Domino for Windows NT to the Domino for S/390 solution. The plan is to
have approximately 1,000 e-mail users in production by the end of 1999. The
detailed description of the configuration is as follows.
• Solution hardware: 9672-R64 with 5 LPARs.
• Solution software: OS/390 V2.6 and Domino for S/390 V4.6.3A.
• Clients: desktops use a Lotus Notes client to access the Domino for S/390
mail server using TCP/IP protocols. The desktops run Windows NT on
PCs.
A.1.3 Value to customer

The customer benefited from effective teaming and information sharing. They
plan to reduce hardware and maintenance costs associated with running

multiple Windows NT mail servers by consolidating the Windows NT post
offices onto the Domino for S/390 solution.
A.1.4 Lessons learned

An IBM product specialist should work closely with customers considering
running Domino for S/390 to make sure all the IBM software prerequisites
and latest PTFs on products have been applied. This customer found Domino
for S/390 installation documentation confusing and the procedures difficult to
follow.
A.2 Successful OS/390 UNIX in-house port

The following example shows a customer that successfully moved an
in-house application onto OS/390 UNIX.
A.2.1 Business need

A US Auto Parts company registers and warrants parts sold to customers
from a point of sale terminal into a central database. The company required a
database and server platform that could grow rapidly and scale to several
times the current capacities. Since the primary purpose of a warranty is
customer satisfaction, high availability and responsiveness are also primary
objectives.
The National Warranty system was implemented on a UNIX-based system

with an Informix database. The capacity of a single UNIX system was 1200
online stores. When the chain of stores grew above 1200 stores, The
company added a second UNIX server but now had to maintain two copies of
the database. Since a customer could buy battery in New York and may need
warranty service in Montana, each server had to see the entire set of
customers and all parts registration. This required a very complex
implementation of capturing database updates and then applying then to the
other server. As the growth continued above 2000 stores, it was clear that
managing 3 servers and some form of database replication was not doable.
All of the business logic was written in C++ programs and this investment
need to be saved as well as the connection to the network of clients in the
stores.

The national warranty application was ported to OS/390 UNIX System
Services running on an S/390 Parallel Enterprise Server model 9672-R25.
The TCP/IP network was connected to a FDDI OSA-2 adapter in the S/390.

The application development investment was protected. Business logic in the
application was the same and the network connection was just a different IP
address. The data was ported to DB2 and the calls to Informix changed to
calls to DB2. When the S/390-based national warranty system came on-line,
the store count was 2700 and rising.
One of more pleasant surprises was the ability to manage the responsiveness
of a given task. The national warranty system has three primary functions.
• Lookup-customer is at the store and they are querying status
• Registration-customer has purchased a part and the database needed to
be updated
• Batch-activity that looks at database and creates reports.
In the S/390 environment, is was easy to prioritize the work and give the
customer at the store the best service at the expense to batch and
registration. The workload varies through the day and day of the week.
Even the weather has an effect on transaction rate. Workload manager
makes an easy task of dedicating all of the resources of the processor to
Lookup and customer satisfaction.
Future acquisitions can add stores to the chain and the processor can be
upgraded without disruption form the current size to something 14 times
bigger. Since DB2 can give you a single view of the data in a S/390 Parallel
Sysplex configuration, almost unlimited growth can be handled.

System S/390 provided the company with a single database, scalability to
handle their future growth and the proven reliability necessary to meet their
24 by 7 availability requirements. IBM provided end-to-end service with the
porting center helping to bring up the application and working through tuning
issues.

The IBM porting center in Gaithersburg discovered a transition problem in the
relationship of the UNIX “fork” process to the S/390 address space. The
application on the UNIX side would fork a new process when a store signed
on. In the S/390 environment, that results in the creation of a new address
space for each store. With 2,700 stores, the storage requirements were
unrealistic. Changing from a fork() call to a spawn() call allowed one S/390
address space to own many stores and the storage usage became efficient
and manageable.
Server consolidation case studies 129

A.3 Successful OS/390 UNIX vendor port
The vendor is MOSAIC Software AG. With its EDI 1 gateway, the vendor has
secured the leading market position for EDIFACT clearing and payment
systems in Germany and Switzerland. The software package, which runs
under IBM AIX and other UNIX-based platforms, now is available for OS/390.
MOSAIC EDIFin first was ported to OS/390 at HSBC Trinkaus & Burkhardt in
Düsseldorf, Germany. The system has been successfully operating for six
months at Informatik-Kooperation GmbH in Münster, Germany, one of the
largest clearing centers of the German savings bank organization.
A.3.1 Business need

The vendor’s application is written in C/C++ and runs on other UNIX
operating systems. They need the tool to run on OS/390 to support
customers who require a high level of reliability and availability.

The solution was to port MOSAIC EDI to OS/390 UNIX. The application is
approximately 500 KLOC in size and is a mix of C and C++ code. The code
was ported by one programmer in about six months.
Certain issues arose during the port. There is a limit in DB2 whereby the
length of an SQL command cannot be longer than 80 characters. Header files
were somewhat different with pthread function calls. There were some
ASCIi-to-EBCDIC conversions necessary, but this code only required about a
week of effort. GNU’s flex and bison tools were needed on OS/390 for lexical
analysis code.
A.3.3 Value to vendor

The vendor now can offer their solution on OS/390. Having this offering gives
the vendor’s customers unsurpassed reliability and availability.

DB2 is not always DB2 on other platforms. There were subtle differences on
DB2 for OS/390 that had to be worked around. This same is true for DCE on
S/390.
A.4 Successful LAN data consolidation onto OS/390

The following example shows a customer that successfully used LANRES to
consolidate LAN data.

A.4.1 Business need
Banker’s Trust, a large US bank, has a large population of Novell clients and
servers at multiple locations. Managing the performance, capacity and
availability of these servers is a large, complex task. Disk upgrades to
accommodate the growth of data stored on the LAN servers result in many
service interruptions, extended down time, and require a large amount of
system programmer time. A solution with better availability and requiring less
technical resource time was needed.

The customer installed OS/390 V1.3 with LAN Resource Extension Service
(LANRES) on a ES/9000 9021 processor. Data resident on the Novell PC
server was moved to VSAM linear datasets on the ES/9000 processor. The
data was stored on IBM RAMAC RAID 5 DASD. A dual Novell server
environment was created, with a specific application present on each of the
two servers in conjunction with LANRES and the Novell LAN server operating
system. High speed S/390 channel connections exist from the primary and
secondary PC servers to the ES/9000 processor for accessing the VSAM
data required by the applications. Should the primary PC server go out of
service or require upgrades, users are re-directed to the secondary PC where
the application set provides access to the VSAM datasets. Users experience
minimal interruption of service.
The customer is moving from a parallel channel to a 100 Mb/s ethernet over
TCP/IP attached FEP. This should offer better performance and easier
manageability.

This customer gained effective teaming and information sharing, improved
customer service and improved quality of service. The solution enabled
Bankers Trust to add disk space to the Novell servers without affecting user
availability to the servers and the data. The former Novell server data is
managed under the same robust policies and practices as the company's
mission-critical data which is already resident on ES/9000 and S/390 server
platforms. With data required by LAN Servers being managed under OS/390,
IS's operations procedures are more simplified and reliable, resulting in lower
operation costs. As more data is moved off the Novell servers, immediate
space requirements will be reduced and servers can be consolidated for
additional savings.
Server consolidation case studies 131

The “selling” of some solutions internally is often political and difficult. The
LANRES solution is being used by one department but has not been sold to
the entire enterprise.
A.5 Java port to OS/390

The following example shows a customer that successfully avoided the need
for a new NT server by moving a Java application to OS/390.
A.5.1 Business need

The U.S. Department of Commerce has a human resources application
named HURDS for which the client is a Web browser. It is an in-house
application that was developed on NT in Java. The plan was to also run the
application on NT, however, a more reliable and scalable system was
needed.

The customer already had an OS/390 V2R5 system in house. The Java code
was simply FTPed to OS/390 and run - no coding changes were necessary.
However, initially there were some performance problems. With the help of
OS/390 service, this problem was fixed and the performance is now
adequate.

The application runs on S/390 and there will be no need to add a dedicated
NT server to host it.

The performance of Java on OS/390 can be an issue. This must be
addressed early in the process of moving to OS/390.

Appendix B. Special Notices
This publication is intended to help Information Technology (IT) managers

who want to improve their understanding of how IBM S/390 servers can
integrate with other systems, and how S/390 servers can run new
applications such as Lotus Domino, SAP R/3 and Internet solutions.
References in this publication to IBM products, programs or services do not

imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not
intended to state or imply that only IBM's product, program, or service may be
used. Any functionally equivalent program that does not infringe any of IBM's
intellectual property rights may be used instead of the IBM product, program
or service.
Information in this book was developed in conjunction with use of the

equipment specified, and is limited in application to those specific hardware
and software products and levels.
IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to the IBM
Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY
10504-1785.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and

conditions, including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
("vendor") products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have
been reviewed by IBM for accuracy in a specific situation, there is no
guarantee that the same or similar results will be obtained elsewhere.

Customers attempting to adapt these techniques to their own environments
do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes
available to each customer according to the normal IBM PTF distribution
process.
The following terms are trademarks of the International Business Machines

Corporation in the United States and/or other countries:
IBM  AIX
AnyNet APPN
AS/400 CICS
DB2 DFSMS
DFSMShsm eNetwork
ES/9000 ESCON
IMS InfoPrint
Magstar Micro Channel
MQSeries Multiprise
MVS/ESA Netfinity
NetView OfficeVision
OpenEdition OS/2
OS/390 OS/400
Parallel Sysplex PR/SM
RAMAC RMF
RS/6000 S/370
S/390 S/390 Parallel Enterprise Server
Seascape SP2
StorWatch System/390
SystemView Ultrastar
VM/ESA VSE/ESA
VTAM WebSphere
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc. in the United States and/or other

countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other

countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United

States and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel

Corporation in the United States and/or other countries. (For a complete list
of Intel trademarks see www.intel.com/tradmarx.htm)
UNIX is a registered trademark in the United States and/or other countries

licensed exclusively through X/Open Company Limited.
SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
Other company, product, and service names may be trademarks or service

marks of others.
Special Notices 135

Appendix C. Related Publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
C.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see “How to Get ITSO
Redbooks” on page 141.
• Lotus Domino for S/390 Release 5: Installation, Customization and
Administration, SG24-2083
• Continuous Availability Systems Design Guide, SG24-2085
• Continuous Availability S/390 Technology Guide, SG24-2086
• Consolidating UNIX Systems onto OS/390 , SG24-2090
• Bringing Windows NT Applications to OS/390, SG24-2093
• Selecting a Server - The Value of S/390 , SG24-4812
• S/390 OSA-Express Gigabit Ethernet Implementation Guide, SG24-5443
• IBM 2216 and Network Utility Host Channel Connections , SG24-5303
• Implementing SAP R/3 in an OS/390 Environment: AIX or Windows NT
Application Servers, SG24-4945
• Installing PeopleSoft on OS/390 with DB2, SG24-5156
• File Server Consolidation on S/390 , SG24-5330
• Installing BAAN IV Applications on OS/390, SG24-5334
• IBM Storage Solutions for Server Consolidation, SG24-5355
• Networked Applications on OS/390 UNIX , SG24-5447
• Porting UNIX Applications to OpenEdition for VM/ESA , SG24-5458
• IBM Enterprise Storage Server, SG24-5465
• Porting Applications to the OpenEdtion MVS Platform , GG24-4473

C.2 Redbooks on CD-ROMs
Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
offered, updates and formats.
CD-ROM Title Collection Kit
Number
System/390 Redbooks Collection SK2T-2177
Networking and Systems Management Redbooks Collection SK2T-6022
Transaction Processing and Data Management Redbooks Collection SK2T-8038
Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
AS/400 Redbooks Collection SK2T-2849
Netfinity Hardware and Software Redbooks Collection SK2T-8046
RS/6000 Redbooks Collection (BkMgr) SK2T-8040
RS/6000 Redbooks Collection (PDF Format) SK2T-8043
Application Development Redbooks Collection SK2T-8037
IBM Enterprise Storage and Systems Management Solutions SK3T-3694
C.3 Other Publications

These publications are also relevant as further information sources:
• S/390 Software Pricing Reference Guide July 1999, G326-0594
• Commercial Clustering: Handling Today’s Workload with S/390 Sysplex ,
IBM white paper, September 1996, G326-3025
• e-business powered by S/390 , IBM white paper, January 1998, G326-3026
• SAP R/3 Database Server Running on S/390 , IBM white paper, May 1997,
G326-3027
• S/390 Technology Leadership, IBM white paper, February 1998,
GF22-5008
• S/390 Parallel Sysplex Cluster Technology: IBM’s Advantage, IBM white
paper, May 1999, GF22-5015
• S/390: The Enterprise Resource Planning Platform of Choice , IBM white
paper, December 1997, GF22-5039
• IBM S/390: The Defining Standard of Enterprise Computing, Today and
Tomorrow, IBM white paper, May 1998, GF22-5043
• Enabling OS/390 Platform Support for BaanERP Enterprise Applications,
IBM white paper, January 1999, GF22-5045

• The Mettle Test - Enterprise Computing in the Real World, IBM white
paper, September 1998, GF22-5064
• Meeting the Challenges of Enterprise Groupware: Running Domino on
S/390, IBM white paper, January 1999, GF22-5075
• S/390: Integrated Thinking, IBM white paper, May 1999, GF22-5117
• S/390... Integrated Solutions, IBM white paper, May 1999, GF22-5120
• Enterprise Server Essentials, IBM white paper, May 1999, GF22-5122
• IBM Storage Area Network (SAN) strategy white paper, April 1999
• Enterprise Data Center Strategies, META Group paper, April 1999
• Storage Area Networks: Putting Data to Work for e-businesses, IBM white
paper, June 1999
Most IBM white papers can be found by searching for the order number on
the S/390 Web site at:
http://www.s390.ibm.com
Related Publications 139

How to Get ITSO Redbooks
This section explains how both customers and IBM employees can find out about ITSO redbooks,
redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
• Redbooks Web Site http://www.redbooks.ibm.com/
Search for, view, download, or order hardcopy/CD-ROM redbooks from the redbooks Web site. Also
read redpieces and download additional materials (code samples or diskette/CD-ROM images) from
this redbooks site.
Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few
chapters will be published this way. The intent is to get the information out much quicker than the
formal publishing process allows.
• E-mail Orders
Send orders by e-mail including information from the redbooks fax order form to:
e-mail address
In United States usib6fpl@ibmmail.com
Outside North America Contact information is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl/
• Telephone Orders
United States (toll free) 1-800-879-2755
Canada (toll free) 1-800-IBM-4YOU
Outside North America Country coordinator phone number is in the “How to Order”
section at this site:
• Fax Orders
United States (toll free) 1-800-445-9269
Canada 1-403-267-4455
Outside North America Fax phone number is in the “How to Order” section at this site:
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at the redbooks Web site.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and redbooks by accessing
the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.
Look in the Materials repository for workshops, presentations, papers, and Web pages developed
and written by the ITSO technical professionals; click the Additional Materials button. Employees may
access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Redbook Fax Order Form
Please send me the following:

Title Order Number Quantity
First name Last name
Company
Address
City Postal code Country
Telephone number Telefax number VAT number
Invoice to customer number
Credit card number
Credit card expiration date Card issued to Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.

Index
E
EBCDIC 90
Numerics
2216 68 Enterprise Resource Planning 99
3745/3746 68 BaanERP 103
9672 servers 32 PeopleSoft 103
SAP R/3 99
ESCON 17, 18, 60
A director 18
ADSM 43, 114 Multi Image Facility (EMIF) 18
ATM 34, 59 ESCON Manager 72
Automated Operations Control/MVS 72 ESCON Multiple Image Facility (EMIF) 68
B F
BaanERP 103 FDDI 34
Backup-While-Open (BWO) 42 Fiber Channel (FC) 49
FICON 54, 61
C bridge card 54
Capacity BackUp (CBU) 33 direct attachment 55
Capacity Upgrade on Demand 32 switch connectivity 55
CGI 98 file serving 104
Channel Interface Processor (CIP) 67 firewall 43
CICS 45 Forum Compliant LAN emulation 64
CISC 120 FTP 60
Cisco 7000 67
CMOS 14 G
Common Gateway Interface (CGI) 97 Geographically Dispersed Parallel Sysplex (GDPS)
Concurrent Copy 19 41
consolidation Gigabit Ethernet 67
server 1 Global Enterprise Manager (GEM) 76
storage 4 Groupware applications 93
continuous availability 16
continuous operations 16
CORBA 37 H
coupling facility 31 Hardware Configuration Definition (HCD) 73
Cryptographic Coprocessor 44 Hardware Configuration Manager (HCM) 73
Hierarchical File System 47
high availability 16
D HTML 95
data warehousing 45 HTTP 95
database backup and recovery 42
DFS/SMB 110
DFSMS 41 I
DNS 60 ICAPI 98
Dynamic I/O Reconfiguration Management (DRM) IMS 45
17 Infomix 91
Ingres 91
Integrated Cluster Buses (ICB) 31

Integrated Server 35 UNIX tools and toys Web page 91
Internal Battery Feature (IBF) 17 OS/390 UNIX 47
Internal Disk 33 OSA Systems Facility 66
OSA-2 17, 34, 63
ATM card 64
J configuration and management 65
Java 37, 99
ENTR card 64
Fast ethernet card 64
L FDDI card 64
LAN Server 108 modes of operation 65
LANRES 105 types 64
libascii 91 OSA-Express 66
logical partitioning 27
Lotus Domino 93
LPAR 27 P
Parallel Sysplex 29
M License Charge (PSLC) 122
Magstar 3590 55 Partial I/O Restart 17
memory error correction 17 PCNFSD 113
Micro Channel to Mainframe Connection (MMC) 69 PC-to-S/390 channel connection 69
MIPS vs Mhz 117 Peer-to-Peer Remote Copy (PPRC) 40
Multi-Access Enclosure (MAE) 68 PeopleSoft 103
Multiprise 2000 33 porting 87
Enterprise Server Offering 34 ASCII dependencies 90
mvslogin, mvslogout 113 database considerations 91
NT applications 92
the process 88
N UNIX environment 88
NCITS 62
NetView Access Services (NVAS) 78 POSIX 46
NetView Distribution Manager 78 PR/SM 27
Network Storage Manager 56 pricing
networking 59 Distributed Systems License Option (DSLO)
NFS 60, 111 122, 124
client 114 Extended License Charge (ELC) 122
security 113 Extended License Charges (ELC) 125
NT, porting to OS/390 92 Indexed Monthly License Charge (IMLC) 122,
124
Millions of Service Units (MSU) 122
O Multiple Operating System PR/SM (MOSP)
Open Group, The 88 122, 124
open source software 89 P/390 and R/390 124
Open Systems Adapter 63 usage 123
OpenEdition 46
OS/390 36
continuous availability 19 R
performance management 72 RAID 18
performance monitoring 73 RAMAC Scalable Array (RSA) 18
porting applications to 87 RAMAC Virtual Array (RVA) 18, 40
porting centers 88 Resource Access Control Facility (RACF) 44

Resource Measurement Facility (RMF) 72 application integration 5
RISC 120 centralization 2
RVA 18 data integration 4
definition 1
physical 3
S reasons for 6
S/390
types 1
architecture enhancements 15
SnapShot 40
backup and recovery 40
SnapShot Copy 19
CMOS design 14
Storage Area Network
definition 49
DASD 18
Storage Area Network (SAN) 49
database solutions 45
storage consolidation 4
dual instruction units 16
Storage Networking Industry Association (SNIA)
Enterprise Server 11
49
ESCON 18
Sybase 91
future directions 48
system automation 71
Integrated Server 35
System Automation for OS/390 71
memory error correction 17
System Network Architecture (SNA) 59
Multiprise 2000 33
systems management 71
networking 59
new workloads 48
power system 17 T
pricing 122 Target System Control Facility 72
processor options 32 TCP/IP 59, 60
processor upgrades 32 Telnet 60
RAID 18 The Open Group 46
security 43 Tivoli 73
server consolidation 85 Global Enterprise Manager (GEM) 76, 80
sizing servers 117 management agent 77
Subsystem Storage Protection 17 management gateway 77
system automation 71 management server 77
systems management 39, 71 NetView Access Services (NVAS) 78
uniprocessor performance 14 NetView Distribution Manager 78
usage pricing 123 NetView File Transfer Program 79
S/390 file serving 104 NetView Performance Monitor 78
Samba 109 Operations Planning and Control (OPC) 79
SAP Performance Reporter 79
R/3 architecture 100 Security Manager 79
SAP R/3 99 Service Desk 80
SCSI 56 Tivoli Enterprise Architecture 74
Seascape architecture 55 Tivoli Enterprise Console (TEC) 82
Secure Electronic Transaction (SET) 45 Tivoli Framework 75, 76
security Tivoli Management Region (TMR) 77
network 43 TN3270 60
system 44
transaction 44
Serial Storage Architecture (SSA) 56
U
UNIX
server consolidation 85
porting environment 88
145
porting process 88
UNIX System Services 47
V
Versatile Storage Server (VSS) 56
Virtual Private Network (VPN) 44
Virtual Tape Server 56
Visual BASIC 92
Visual C/C++ 92
VSAM 45
W
Web Cache Manager 56
Web serving 95
WebSphere Application Server 95
Wind/U 92
WorkLoad Manager (WLM) 30, 73
X
XPG 46
X-Windows 60

ITSO Redbook Evaluation
S/390 Server Consolidation A Guide for IT Managers
SG24-5600-00
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?

_ Customer _ Business Partner _ Solution Developer _ IBM employee
_ None of the above
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction __________
Please answer the following questions:
Was this redbook published in time for your needs? Yes___ No___
If no, please explain:
What other redbooks would you like to see published?
Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)

S/390 Server Consolidation A Guide for IT Managers SG24-5600-00
Printed in the U.S.A.
SG24-5600-00

S/390 Server Consolidation A Guide For It Managers: Michael Macisaac, Mike Duffy, Martin Söllig, Ampie Vos

Uploaded by

Copyright:

Available Formats

S/390 Server Consolidation A Guide For It Managers: Michael Macisaac, Mike Duffy, Martin Söllig, Ampie Vos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S/390 Server Consolidation A Guide For It Managers: Michael Macisaac, Mike Duffy, Martin Söllig, Ampie Vos

Uploaded by

Copyright:

Available Formats

S/390 Server Consolidation

A Guide for IT Managers

Michael MacIsaac, Mike Duffy, Martin Söllig, Ampie Vos

International Technical Support Organization

International Technical Support Organization

S/390 Server Consolidation - A Guide for IT Managers

First Edition (October 1999)

Comments may be addressed to:

© Copyright International Business Machines Corporation 1999. All rights reserved.

Chapter 1. Introduction to server consolidation .. . . . .. . . . . .. . . . . .1

Chapter 2. What S/390 has to offer . . . . . . . . . . . . . . . . . . . . . . .. . . . . 11

© Copyright IBM Corp. 1999 iii

Chapter 3. Networking and connectivity . . . . . . . . . . . . .. . . . . .. . . . . 59

Chapter 4. Systems management . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 71

iv S/390 Server Consolidation - A Guide for IT Managers

Chapter 5. Server consolidation on S/390 . . . . . . . . . . . . . . . . . . . . . . 85

Appendix A. Server consolidation case studies . . . . . . . . . . . . . . . . . . 127

Appendix B. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Appendix C. Related Publications. . . . . . . . . . . . . . . . . . . . . . . ...... . 137

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

vi S/390 Server Consolidation - A Guide for IT Managers

The redbook provides an introduction to S/390 capabilities in these areas. It

The team that wrote this redbook

Martin Söllig is a High End Systems Engineer in Germany. He has nine

© Copyright IBM Corp. 1999 vii

Thanks to the following people for their contributions to this project:

Terry Barthel, Dotti Still, Ken Trowell, Stephen Turner

Max Bidle, Bill Marchetti, Alan Martens, Joe Temple

Hans Dieter Mertiens

We want our redbooks to be as helpful as possible. Please send us your

viii S/390 Server Consolidation - A Guide for IT Managers

A decade ago, business professionals and department heads grew weary of

Distributed, client/server computing provided the autonomy that departments

The proliferation of servers resulting from the move to distributed computing

1.1 What is server consolidation

Server consolidation can be categorized into the following types:

© Copyright IBM Corp. 1999 1

Figure 1. Four categories of server consolidation

2 S/390 Server Consolidation - A Guide for IT Managers

Virtual centralization or remote management

1.1.2 Physical consolidation

Figure 3. Physical Consolidation

Introduction to server consolidation 3

Storage consolidation is combining data from different sources (same or

1.1.3 Data integration

Figure 4. Data integration

4 S/390 Server Consolidation - A Guide for IT Managers

1.1.4 Application integration

Figure 5. Application integration

Introduction to server consolidation 5

Analysts and IT professionals say proliferation of systems is driving the

Figure 6 shows why IT organizations move toward server consolidation. The

Reduce/control growth in IT costs

0% 20% 40% 60% 80%

Figure 6. Reasons for consolidation

6 S/390 Server Consolidation - A Guide for IT Managers

1.2.1 The total cost of computing

Figure 7. True total cost of computing