S 390 Server Consolidation - A Guide for IT Managers

8/10/2019 S 390 Server Consolidation - A Guide for IT Managers

http://slidepdf.com/reader/full/s-390-server-consolidation-a-guide-for-it-managers 1/158

SG24-5600-00

International Technical Support Organization

http://www.redbooks.ibm.com

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

October 1999

SG24-5600-00

International Technical Support Organization



© Copyr ight Intern ation al Busi ness Machi nes Cor porati on 1999. All righ ts reser ved.

Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

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.

Before using this information and the product it supports, be sure to read the general information in

Appendix B, “Special Notices” on page 133.

Take Note!



© Copyright IBM Corp. 1999 iii

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.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



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

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.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 . . . . . . . . . . . . . . . . . . . . . . . . . 774.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



v

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.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 . . . . . . . . . . . . . . . . . . . . . 1085.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





© Copyright IBM Corp. 1999 vii

Preface

This redbook was writ ten 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.



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

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 TurnerInternational 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 [email protected]





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

• 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.

Figure 1. Four categories of server consolidation

1.1.1 CentralizationServer 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.

ApplicationIntegration

DataIntegration

PhysicalConsolidation

Centralization

Logical

Physical

System Integration



Introduction to server consolidation 3

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.

Figure 3. Physical Consolidation

N Y

G A

N J

C T

C A

M N

N Y

C A

a

a

a

a




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.

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.

a

a

a

a




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

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.

ba ba

ed ed




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.

Figure 6. Reasons for consolidation

0% 20% 40% 60% 80%

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




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 manualintervention 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 ser vers.

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 andexpand 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 withpeak 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 ser ver).

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.






© Copyright IBM Corp. 1999 11

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 byincorporating 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.




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, strictlyseparated 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

File...Print...Communication...Database...Application Processing

S i z e / C a p a c i t y

LargeSystems

Mid-range

PC



What S/390 has to offer 13

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. Buttime 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.




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 toreplace 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.

Figure 9. S/390 CMOS capacity and performance

R2/3

0.3 times

G4

R1

0.2 times

G4

G3

0.7 times

G4

G4G5

Up to 3.2times

G4

G6

Up to 2.4times

G4

85 94 95 96 97 98 99

3090B

3090E

3090S

9021-520

9021-711

3090J 9672-R1

9672-R2/R3

G3 Server

G4 Server

G5 Server

G6 Server

Uni-processor Comparison: Bipolar – CMOS

RelativePerformance




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. M ost

of these enhancements are discussed in the following chapters.

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:

Integrated ClusterB usInternal Coupling (IC)channel128 bit TOD Clock

Spare Processor UnitTransparent CP/ICFSparing

Business ContinuanceFunction

Partial I/OHalf of a PU cluster

Enhanced ApplicationPreservationEnhanced Storage

RecoveryEnhanced MemoryGranularityIEEE FP

Parallel SysplexCoupling Facility (CF)Coupling LinksIntegrated Coupling

Migration FacilityCoupling FacilityControl CodeSysplex TimerOpen SystemsAdapter

Enhanced ProcessorDesign

Dual I/E UnitsSpare Processor

UnitDynamic CPSparing

Internal CouplingFacilityHiPerLinksDynamic CF

DispatchingDynamic CFExpansionDual CryptographicCoprocessorOpen SystemsAdapter 2 (OSA-2)

Non-Disruptive GrowthConcurrentConditioningCapacity Upgrade on

DemandCapacity BackUp

CBU AutoActivationDedicated or SharedICFsEnhanced Dynamic ICFExpansionCrypto NIST FIPS

CertificationFICON Channel CardOSA Express

G5/G6 R1/2/3 G3 G4

1994/95 1996 1997 1999 1998




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 memorychips, 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/OReconfiguration 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 disturbanceimmunity.

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 I ndependent 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 dataredundancy. 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 DASDinstallation 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 theshared 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.




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.

Data

Servers

Distributed Partitioned

CouplingTechnology

Shared




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.

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.

Partitioned Shared

CouplingTechnology




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.

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

Tuned Benchmark Real Workload

CouplingTechnology

Partitioned Shared Partitioned Shared




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 theutilization 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.




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.

Coupling Technology

Partitioned Shared




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.

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 needfor 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, vir tual 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.

0 0 : 0 0

0 1 : 0 0

0 2 : 0 0

0 3 : 0 0

0 4 : 0 0

0 5 : 0 0

0 6 : 0 0

0 7 : 0 0

0 8 : 0 0

0 9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

2 4 : 0 0

0

50

100

150

200

P e r c e n t C P U

U t i l i z a

t i o n

Domain 3 -Business Intelligence /Data Mining

Domain 1 - OLTP

Domain 2 - Batch

Domain 4 - Web Serving

P e r c e n t C P U

U t i l i z a t i o n

0 0 : 0 0

0 1 : 0 0

0 2 : 0 0

0 3 : 0 0

0 4 : 0 0

0 5 : 0 0

0 6 : 0 0

0 7 : 0 0

0 8 : 0 0

0 9 : 0 0

1 0 : 0 0

1 1 : 0 0

1 2 : 0 0

1 3 : 0 0

1 4 : 0 0

1 5 : 0 0

1 6 : 0 0

1 7 : 0 0

1 8 : 0 0

1 9 : 0 0

2 0 : 0 0

2 1 : 0 0

2 2 : 0 0

2 3 : 0 0

2 4 : 0 0




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 than32 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 prioritiesfor 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 afunction. 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.

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 LPARconfiguration. 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

PROD

TEST

DEV

4 real

processors

4 LPs

2 LPs

3 LPs

Dedicated or shared

I/O devices




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 astrategy 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 intime” 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.






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.

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

G5 G5

RD6

RC6

R26

R16

Alumina CeramicSubstrate6 PUsUp to 4 CPs1 - 12 GB Memory2.6 ns Cycle time

G5 "Turbo" ModelsGlass CeramicSubstrateMCU (Modular CoolingUnit)12 PUsUp to 10 CPs8 - 24 GB Memory2.0 ns Cycle timeY16,Y26 CBU only

Glass CeramicSubstrateMCU (ModularCooling Unit)14 PUsUp to 12 CPs2 SAPs Standard5 - 32 GB Memory1.8 ns Cycle time

X17, X27 CBU only

G6 "Turbo" ModelsGlass CeramicSubstrateMCU (ModularCooling Unit)14 PUsUp to 12 CPs2 SAPs Standard5 - 32 GB Memory1.57 ns Cycle timeZ17- Z67 CBU only

Glass Ceramic

Substrate

8/12 PUs

Up to 10 CPs

2 - 24 GB Memory

2.4 ns Cycle time

T16, T26 CBU only

RX6

R96

R86

R76

R66

R56

R46

R36

T26

T16

YX6

Y96

Y86

Y76

Y66

Y56

Y46

Y36

Y26

Y16

XZ7

XY7

XX7

X97

X87X77

X67

X57

X47

X37

X27

X17

ZZ7

ZY7

ZX7

Z97

Z87

Z77

Z27

Z17

G6 G6

RB6

RA6

Z67

Z57

Z47

Z37




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).




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

Reduced Cost of Computing

Internal DiskEnvironmentalsInnovative FunctionsPackaged Offerings

Internal Disk

Mirrored, cost-effective storageSpace, energy, maintenancesavingsFast reads and writes7 logical volume options

Cyptographic Coprocessor Feature

Hardware data securityEnhanced capabilitiesSecure electroniccommerce

ESCON

Access to local/remoteI/O devicesConfiguration flexibilityUp to 17 MB/second

OSA-2

Standard functionEthernet, Token Ring,FDDI, ATMSimplifies networking

PR/SM

Up to 10 partitionsShared Channels,network and disk storage

Enhanced DynamicStorage Reconfiguration

Hardware Data Compression

Up to 70% DASD storagesavingsUp to 70% communicationsline utilization savings

Availability

Designed for HIGH availabilityRedundant Power andcoolingConcurrent maintenancefor critical parts

IT Without Boundaries

Enables Year 2000continuitySupports current andnew applications

Internal Battery Feature

20 to 90 minutes fullholdup powerExploitation by InternalDisk Fast Write function




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.

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,

Connectivity

Industry standard I/O connections

PCI and ISA I/O ports

ESCON Channels

Access to local/remote I/O devices

Up to two channels

Up to 17 MB/sec

S/390 Parallel Channels

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

Reduced Cost of Computing

Entry Support License (ESL)software pricing

Integrated Communications

Integrated I/O

Environmentals

Packaged Offerings

Internal Disk

255 GB available

RAID 5

FBA, CKD, ECKD DASDEmulation

Concurrent maintenance

Space, Energy,Maintenance Savings

IT without Boundaries

Year 2000 Ready

Supports current and newapplications

Application Isolation

256 MB Main Memory

Environment

Standard Single Phase Power

Redundant Power

Internal Battery Feature

N+1 Power

Easy InstallationLow Environmental Cost

Available

Generally available onNovember 12, 1998

Early Support shipmentsin September, 1998

2X performance increasein 1999




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 bymodern enterprises (see Figure 21 on page 37).




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 bepossible 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

Appl Appl Appl Appl Appl Appl...

S/390 Processor

OS/390

WorkloadManager

RACF DFSMS/ MVS

UNIXServices

JES2/3

Data Manager

IMS DB VSAMDB2

Batch Transaction Manager

CICS IMS TMTSO

VTAM TCP/IP

BatchJob

UNIX Windows Web




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 theCryptographic 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.








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 S ysplex (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.

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.

Site A Site B

Local copy and remote copyLocal copy and remote copy




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-sitelocation.

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 i mage 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, enhancedperformance 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/390is 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 formanaging 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 onpage 46.




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 aC 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

Net.Datafor OS/390

MQSeriesInternet Gateway

JAVAInternet Gateway

Internet

AIFInternet Gateway

CICS Connectorsfor S/390

Domino

Connectors

IMS Connectorsfor S/390




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.

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 andthere 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.

UNIX* Std

S/390

Full UNIX branding

hierarchical

files

MVS Datasets

databases

TCP/IPand

SNA

rlogin

telnet

nfs

ftp

tn3270




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 forcontinuous 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 Channelarchitecture.

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.




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

Local Area Network

Storage Area Network




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 forhigher 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 UNIXservers 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.




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, likesystems 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

A d v a n c e d F u n c t i o

n s

time

SAN Optimized SystemsShared file systems

SAN based storage management

Benefits include:

Transparent data access

Heterogenous true date sharing

Challenges include:

Interoperability

Heterogenous operating systems, RDMS standards

Application software to exploit potential

Security issues

SAN Optimized StorageAdvanced SAN solutions,including disk/tape pooling, highavailability clustering and so on

Storage-to-storage data copy andmovement for remote copy,instant copy, data migration,

LAN-less backupExtended fabric management

Benefits include:

Improved data movement performance

Storage servers exploit Fibre Channel connectivity

Reduced server processing workload for storage

Standardization of storage processing

SAN-Attached StorageNo functional change in storagesubsystems

FC attachment via gateways and

native adaptersBox-level SAN management andreporting

Simple SAN solutions

Hubs and switches

All building blocks functional

Benefits include:

Fewer adapters and cables

Extended adressing and distance

Greatest benefits in area of SCSI replacement

service offerings: multi-vendor, best-of-breed solutions

consulting .. planning .. design .. integration .. testing . . qualification






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 beingdelivered 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.




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.

FICON Bridge Connections:

FICONChannelS/390

G5/G6 Servers

ESCONCU

ESCONCU

ESCONCU

Exploit FICON Channel with existing ESCON Control Units

Native FICON Direct Attachment: Statement of Direction

Native FICON Control Units

Native FICON Switched Connectivity: Statement of Direction

Full Dynamic Switching of FICON Control Units

FICONChannel

FICONCU

S/390

G5/G6 Servers

FICONCU

FICONCU

S/390

G5/G6 Servers

9032-5with

FICONBridge

FICONSwitch




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 S torage Architecture (SSA), isused within the S eascape architecture to connect the processors and internal

disks to ensure high performance and availability. This is shown in Figure 29.

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, forexample 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

SSA Device

Adapter




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.

Figure 30. S/390 Server connectivity options

TCP/IP comms OSA (integrated adapter)

3746 (communicationscontroller)

3172 (interconnect controller)

2216 (channel attached router)

RS/6000 (channel attached)

SNA comms OSA (integrated adapter)

3745/6 (communicationscontroller)

3172 (interconnect controller)

2216 (channel attached router)

RS/6000 (channel attached)

3174 (cluster controller)

Direct Channel FICON (Fibre

Connections)ESCON

MMC (MCA ESCON) card

PCI-ESCON

Parallel




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 forVSE/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.



Networking and connectivity 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.

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.

Parallel Channels1.5 MB/sec --> 4.5MB/sec0.12 km/400 ft maximumdistance

2 Paths per image perCUDisruptive ChangeManagementLimited connectivity

ESCON Channels10 MB/sec --> 17 MB/sec Datatransfer Rate3 km maximum without re-drive26 km/16.2 miles maximumdistance(requires 2 Directors with XDFFeatures)43 km/26.7 miles with 9729Wavelength Division MultiplexerSwitched Point-to-Point Topology -ConnectivityESCON Multiple Image Facility(EMIF)2 Paths per CPC per CUSystem Automation for OS/390

CU

CU

CU

CU

CU

CU

CU

CU

ESCON

Parallel




Figure 32. Fibre CONnectivity channel I/O Architecture

Over the last decade ESCON has been delivering to S/390 customersincreased 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 theFICON 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.

Up to 24 FICON channels

Bandwidth increasedFICON 100 MB/s vs. 17 MB/son ESCON

1 FICON equivalent up to8 ESCON channels

Patchcable for existing ESCONinfrastructure

Reduced cabling complexity

FICON control units and FICON director (SOD)

FICON

FICONBridgeCard

17 MB/s

Link

100 MB/s

Full DuplexLink

...

ESCON

CU

FICON

ESCD9032

Model

5

..

.

ESCON

CU

ESCON

CU




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.

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.

10-95 Token-Ring10-95 Ethernet10-95 FDDI09-96 155 ATM09-96 OSA-2 Standard

97 ATM Enhancements97 SNA Enhancements97 VSE support

04-98 Fast Ethernet

06-99 GAGigabit EthernetSOD:Fast Ethernet155 ATM

1Q 1995Token-RingEthernetFDDI

Future ?4/16/100 TR622 ATM

ES/9000 511/711

9672-R1

9672/R2-R5

G5 (R6)9672-G5+

OSA-1 OSA-2OSA

Express

OSAExpress




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 O SA-2 cards are currently available: an FDDI card; an ENTR

card which supports both Token-Ring and Ethernet; an ATM card forsingle-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 andsecondary 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.

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 maximumnumber 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.

ATM

Token-Ring

Ethernet

FDDI

ATM Network

SDLC

V.35

X.25

ATM,Frame Relay

Network

Switch

Switch

TCP/IP

SNA

APPN

HPR

155 ATM

FDDIToken-Ring

10/100 Ethernet






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 G bE 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-transactionprocessing. 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 cansupport 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, butmight 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 thesecards 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 networkmanagement 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 bedelivered 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



Systems management 73

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-orientedtargets for each piece of work such as the following:

• Transaction response time ranges for different online applications

• Performance cri teria 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.






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)

Integration Tivoli Global Enterprise Manager

ApplicationTivoli Manager for …..ADSM

MQ Series SAP R/3 DatabaseDomino/ Notes

Infrastructure

Tivoli Framework (3.6)Tivoli Framework (3.6)

Deployment

SoftwareDistribution

Availability

DistributedMonitoring

NetviewInventoryManagement

EnterpriseConsole

Security

SecurityManagement

UserAdministration

Operations

WorkloadManagement

StorageManagement

RemoteControl

ServiceDesk

NetworksNetworks InternetInternetDatabasesDatabases ApplicationsApplicationsSystemsSystems

Tivoli

Value




• 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 OperationsNetwork/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. P roblem 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. TMfor 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 CreditCheck 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.




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/390platform.

• 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.

Re-host work

or interoperate

File servers

Print servers Database servers

Lotus Notes servers Application servers

Web servers Mail servers

etc; servers



Server consolidation on S/390 87

• 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.




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 areunaffected 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/390UNIX 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 varywidely 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 softwareWhile 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 LotusNotes 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 theirdatabases 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 A SCII/EBCDIC translations,

but the overall experience is that porting to OS/390 is really comparable to

other UNIX ports.






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 deli vering

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 asone of the best solutions in this rapidly growing market.

Figure 39. Lotus Domino on S/390

inquire

respond

Internet

update

assign

Customer Service Rep Account Rep

DBMS

escalate

alertnotify

Notes & HTTP server




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 cor porate 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.

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 havea 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 di stributed 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”

Internet

Intranet

Web Browser

WebBrowser

Internet connection

Servers

(Web Servers)

Internet connection

Server

(Web Server)

TCP/IP




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 ser vers (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 isgiven to the browser machine, but all programs and control are still

maintained centrally.




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

Dumb ScreenCentral application

& data server

G

D

LAN file serverG

Client / Server G

IntelligentWorkstation

IntelligentWorkstation

Network Computing

G Central application& data server

G Central application

& data serverNetwork Computing

including Java




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 appropriategateway program. CGI programs can be written in many different languages

which include C, REXX and Perl.

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,

Internet

or Intranet

Web Browsermachine

xxxxxxx xxxxxxxxxxxxxxx xxxxxxx xxxxx xxxxxx

xxxxxxx xxxxxxxxxxxxxxx xxxxxxx xxxxx xxxxxx

xxxxxxx xxxxxxxxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

HTMLdocument

containingforms

or similar

HTTP

Java

OS/390

WebSphereApplicationServer for

OS/390 asProxy Server

CICS

Lotus Notes

DB2




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 withone 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 theenterprise. 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






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 FastEthernet 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.

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 ser vers passing information, resulting in extensive network

overhead or latency. As the databases grow, this become more of abottleneck. 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.

Presentation

Application

Database

A p p l . + D B

G U I

G U I

A p p l .

D B

S/390 options for SAP R/3

A p p l .

A v g . r e s p o n s e t i m e

Database Network Application

UPDATE Dialog StepsComparison of avg. response times

E x e c u t i o n T i m e

AFA Batch w/ 14.000 AssetsComparison of Execution Times

Approximately

40 %

Approximately

70 %




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 r un 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 aresupported. 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 easyto 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 becomescorrespondingly 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 contr olled 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.




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 S NA (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).

Disk

Serving

Host-to-

LANPrinting LAN-to-

Host

Printing

S/390

LANRES

NLMs

Host LANRES

NetWare

Server

NetWareServer




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 par titions/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 servingWhereas 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 theoperating 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 theWeb 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/






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.




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.

Access MethodsHFS

MVS/ESA or OS/390

(OpenEdition)

TCP/IPNFS

clients

OS/390 NFS Server

TCP/IP network

mount

includesAIX

OS/2

DFSMS NFS client

HP/UX

SunOS / Solaris

Windows w/addedsoftware

hierarchical

filesMVS data sets




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 calledONE.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

mount bigboy:/hfs/u/jack /u/fred/jackdir

dev u bin temp

fredmary

jackdir

(root)

mydata

bigboy

dev u bin temp

jack mike

(hfs root)

bean stalk bean stalk

UNIX client






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.

Novell

Netware

AIX/6000

SunMac

Dec

-Ultrix

SCO

UNIX

Windows

ADSMServer

MVS

VM

VSE AS/400

AIX

OS/2

OS/2

DOS

Windows/NT




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 thecapacity 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 andLotus 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 T ivoli, 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 canbe 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 no t 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.

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

Benchmark Sponsor Type Range of Applications

TPC-C TPC Moderatelycomplex OLTP

Commercial OLTP

TPC-D TPC Decision support Business Intelligence

TPC-W TPC OLTP web serving e.Commerce

SPEC int95 SPEC Integer processi ng R el ative processor speed

SPESweb96 SPEC Web serving Web serving

Linpack Jack Dongarra,University ofTennessee

Linear algebra Technical computing

Baan Baan ERP Baan ERP

SAP R/3 SD SAP AG ERP SAP R/3 ERP

Notesbench NotesBenchConsortium

Groupware Groupware




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 considerationin 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.






(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 maximumutilization 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 GraduatedMonthly 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, B aan, 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 S ysplex license






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 measurementtechnology 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. T hey

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 iscustomer 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 thatmanaging 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.






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 i s 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 thelargest 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. T here 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.



Server consolidation case studies 131

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.





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 needfor 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.






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 ofincluding 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:

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

IBM ® AIX

AnyNet APPN

AS/400 CICS

DB2 DFSMS

DFSMShsm eNetwork

ES/9000 ESCONIMS 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 ServerSeascape SP2

StorWatch System/390

SystemView UltrastarVM/ESA VSE/ESA

VTAM WebSphere









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 ITSORedbooks” 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.

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

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



Related Publications 139

• 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





© Copyr ight IBM Cor p. 1999 141

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:

• Telephone Orders

• Fax Orders

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.

In United States

Outside North America

e-mail [email protected]

Contact information is in the “How to Order” section at this site:

http://www.elink.ibmlink.ibm.com/pbl/pbl/

United States (toll free)

Canada (toll free)


1-800-879-2755

1-800-IBM-4YOU

Country coordinator phone number is in the “How to Order”

section at this site:


United States (toll free)

Canada


1-800-445-9269

1-403-267-4455

Fax phone number is in the “How to Order” section at this site:


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 Mail ing 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 redb ook, residency, and workshop announ cemen ts.

IBM Intranet for Employees






Index

Numerics2216 68

3745/3746 68

9672 servers 32

AADSM 43, 114

ATM 34, 59

Automated Operations Control/MVS 72

BBaanERP 103

Backup-While-Open (BWO) 42

CCapacity BackUp (CBU) 33

Capacity Upgrade on Demand 32

CGI 98

Channel Interface Processor (CIP) 67

CICS 45

CISC 120

Cisco 7000 67

CMOS 14

Common Gateway Interface (CGI) 97

Concurrent Copy 19

consolidation

server 1

storage 4

continuous availability 16

continuous operations 16

CORBA 37

coupling facility 31

Cryptographic Coprocessor 44

Ddata warehousing 45

database backup and recovery 42

DFS/SMB 110

DFSMS 41

DNS 60

Dynamic I/O Reconfiguration Management (DRM)

17

EEBCDIC 90

Enterprise Resource Planning 99

BaanERP 103

PeopleSoft 103

SAP R/3 99

ESCON 17, 18, 60

director 18Multi Image Facility (EMIF) 18

ESCON Manager 72

ESCON Multiple Image Facility (EMIF) 68

FFDDI 34

Fiber Channel (FC) 49

FICON 54, 61

bridge card 54

direct attachment 55

switch connectivity 55

file serving 104

firewall 43

Forum Compliant LAN emulation 64FTP 60

GGeographically Dispersed Parallel Sysplex(GDPS)

41

Gigabit Ethernet 67

Global Enterprise Manager (GEM) 76

Groupware applications 93

HHardware Configuration Definition (HCD) 73

Hardware Configuration Manager (HCM) 73

Hierarchical File System 47high availability 16

HTML 95

HTTP 95

IICAPI 98

IMS 45

Infomix 91

Ingres 91

Integrated Cluster Buses (ICB) 31




Integrated Server 35

Internal Battery Feature (IBF) 17

Internal Disk 33

JJava 37, 99

L

LAN Server 108LANRES 105

libascii 91

logical partitioning 27

Lotus Domino 93

LPAR 27

MMagstar 3590 55

memory error correction 17

Micro Channel to Mainframe Connection (MMC) 69

MIPS vs Mhz 117

Multi-Access Enclosure (MAE) 68

Multiprise 2000 33

Enterprise Server Offering 34

mvslogin, mvslogout 113

NNCITS 62

NetView Access Services (NVAS) 78

NetView Distribution Manager 78

Network Storage Manager 56

networking 59

NFS 60, 111

client 114

security 113

NT, porting to OS/390 92

OOpen Group, The 88

open source software 89

Open Systems Adapter 63

OpenEdition 46

OS/390 36


performance management 72

performance monitoring 73

porting applications to 87

porting centers 88

UNIX tools and toys Web page 91

OS/390 UNIX 47

OSA Systems Facility 66

OSA-2 17, 34, 63

ATM card 64

configuration and management 65

ENTR card 64

Fast ethernet card 64

FDDI card 64

modes of operation 65types 64

OSA-Express 66

PParallel Sysplex 29


License Charge (PSLC) 122

Partial I/O Restart 17

PCNFSD 113

PC-to-S/390 channel connection 69

Peer-to-Peer Remote Copy (PPRC) 40

PeopleSoft 103

porting 87

ASCII dependencies 90

database considerations 91

NT applications 92

the process 88

UNIX environment 88

POSIX 46

PR/SM 27

pricing

Distributed Systems License Option (DSLO)

122, 124

Extended License Charge (ELC) 122

Extended License Charges (ELC) 125

Indexed Monthly License Charge (IMLC) 122,

124Millions of Service Units (MSU) 122

Multiple Operating System PR/SM (MOSP)

122, 124

P/390 and R/390 124

usage 123

RRAID 18

RAMAC Scalable Array (RSA) 18

RAMAC Virtual Array (RVA) 18, 40

Resource Access Control Facility (RACF) 44



145

Resource Measurement Facility (RMF) 72

RISC 120

RVA 18

SS/390

architecture enhancements 15

backup and recovery 40

CMOS design 14


DASD 18

database solutions 45

dual instruction units 16

Enterprise Server 11

ESCON 18

future directions 48

Integrated Server 35

memory error correction 17

Multiprise 2000 33

networking 59

new workloads 48

power system 17

pricing 122

processor options 32

processor upgrades 32

RAID 18

security 43

server consolidation 85

sizing servers 117

Subsystem Storage Protection 17

system automation 71

systems management 39, 71

uniprocessor performance 14

usage pricing 123

S/390 file serving 104

Samba 109

SAPR/3 architecture 100

SAP R/3 99

SCSI 56

Seascape architecture 55

Secure Electronic Transaction (SET) 45

security

network 43

system 44

transaction 44

Serial Storage Architecture (SSA) 56

server consolidation 85

application integration 5

centralization 2

data integration 4

definition 1

physical 3

reasons for 6

types 1

SnapShot 40

SnapShot Copy 19

Storage Area Networkdefinition 49

Storage Area Network (SAN) 49

storage consolidation 4

Storage Networking Industry Association (SNIA)

49

Sybase 91

system automation 71

System Automation for OS/390 71

System Network Architecture (SNA) 59

systems management 71

TTarget System Control Facility 72

TCP/IP 59, 60

Telnet 60

The Open Group 46

Tivoli 73

Global Enterprise Manager (GEM) 76, 80

management agent 77

management gateway 77

management server 77

NetView Access Services (NVAS) 78

NetView Distribution Manager 78

NetView File Transfer Program 79

NetView Performance Monitor 78

Operations Planning and Control (OPC) 79

Performance Reporter 79Security Manager 79

Service Desk 80

Tivoli Enterprise Architecture 74

Tivoli Enterprise Console (TEC) 82

Tivoli Framework 75, 76

Tivoli Management Region (TMR) 77

TN3270 60

UUNIX

porting environment 88




porting process 88

UNIX System Services 47


VVersatile Storage Server (VSS) 56

Virtual Private Network (VPN) 44

Virtual Tape Server 56

Visual BASIC 92

Visual C/C++ 92

VSAM 45

WWeb Cache Manager 56

Web serving 95

WebSphere Application Server 95

Wind/U 92

WorkLoad Manager (WLM) 30, 73

XXPG 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 [email protected]

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!)



Printed in the U.S.A.

SG24-5600-00 S

/ 3 9 0 S e r v e r C on

s ol i

d a t i onA

G ui d

e f or I T M

an

a g e r s

Documents

S 390 Server Consolidation - A Guide for IT Managers