深入理解IBM z/OS操作系统

3星 · 超过75%的资源需积分: 3 141 浏览量更新于2024-07-30 收藏 1.59MB PDF 举报

"IBM z/OS 概念" IBM z/OS 是一款由IBM开发的大型主机操作系统，主要用于企业级关键业务的处理。这个系统以其高度的稳定性和安全性著称，是许多金融机构、电信公司和其他大型企业的核心计算平台。"z/OS Concepts" 提供了对z/OS操作系统的深入理解和详细解释，旨在帮助用户掌握该系统的基础知识和技能。在"z/OS Basic Skills Information Center"中，你可以找到关于z/OS的各个方面的信息，包括系统架构、管理、性能优化、网络配置、安全性、存储管理和JCL（Job Control Language）等关键概念。这些内容对于系统管理员、开发者和IT专业人员来说至关重要，因为他们需要了解如何有效地操作和维护z/OS环境。在学习z/OS的概念时，首先要注意的是它的多任务和多用户的特性，这使得它能够同时处理大量的并发任务。z/OS采用了一个称为MVS（Multiple Virtual Storage）的内存管理机制，允许不同任务在虚拟地址空间内独立运行，从而实现资源隔离和高效利用。另外，z/OS的文件系统称为DFS (Distributed File System)，它支持分布式计算环境中的数据共享。此外，z/OS还集成了TCP/IP协议栈，可以与各种网络环境无缝交互，包括支持HTTP、FTP等网络服务。在安全方面，z/OS提供了强大的RACF（Resource Access Control Facility），这是一个全面的身份验证和授权系统，用于控制对系统资源的访问。RACF与其他IBM安全产品集成，如Tivoli安全管理器，提供了全面的安全策略实施和审计功能。性能监控和调优是z/OS管理的重要部分。通过使用IBM的System Management Facilities (SMF) 和 Performance Management Tools，管理员可以跟踪系统性能，识别瓶颈，并进行相应的调整。最后，z/OS的JCL是编写和控制作业流程的关键工具，它定义了作业的执行顺序、输入输出处理以及与其他系统组件的交互方式。熟练掌握JCL编写能确保作业的正确执行和自动化。为了获取更多技术问题的支持，或者获取产品和价格信息，用户可以联系IBM的分支办公室、IBM商业伙伴或授权经销商。IBM鼓励用户提供反馈，以改进其文档和产品的质量。用户可以通过指定的网站提交评论，而IBM有权使用这些评论来改进其产品和服务，但不会对用户提供任何义务。 "z/OS Concepts"是理解IBM z/OS操作系统基础的一个重要资源，涵盖了从系统架构到日常运维的广泛知识，对于想要在z/OS环境中工作的专业人士来说，是不可或缺的学习材料。

was to have the entire program reside in central storage when its instructions were

executing. However, the entire program does not really need to be in central

storage when an instruction executes. Instead, by bringing pieces of the program

into central storage only when the processor is ready to execute them--moving

them out to auxiliary storage when it doesn't need them, an operating system can

execute more and larger programs concurrently.

How does the operating system keep track of each program piece? How does it

know whether it is in central storage or auxiliary storage, and where? It is

important for z/OS professionals to understand how the operating system makes

this happen.

Physical storage is divided into areas, each the same size and accessible by a

unique address. In central storage, these areas are called frames; in auxiliary

storage, they are called slots. Similarly, the operating system can divide a program

into pieces the size of frames or slots and assign each piece a unique address. This

arrangement allows the operating system to keep track of these pieces. In z/OS,

the program pieces are called pages.

Pages are referenced by their virtual addresses and not by their real addresses.

From the time a program enters the system until it completes, the virtual address

of the page remains the same, regardless of whether the page is in central storage

or auxiliary storage. Each page consists of individual locations called bytes, each of

which has a unique virtual address.

How virtual storage addressing works in z/OS

z/OS manages address spaces in units of various sizes; these units are tracked in a

virtual address.

Virtual storage is an illusion created by the architecture, in that the system seems

to have more memory than it really has. Each user or program gets an address

space, and each address space contains the same range of storage addresses. Only

those portions of the address space that are needed at any point in time are

actually loaded into central storage. z/OS keeps the inactive pieces of address

spaces in auxiliary storage. z/OS manages address spaces in units of various sizes,

as follows:

v Page address spaces are divided into 4-kilobyte units of virtual storage called

pages.

v Segment address spaces are divided into 1-megabyte units called segments. A

segment is a block of sequential virtual addresses spanning megabytes,

beginning at a 1-megabyte boundary. A 2-gigabyte address space, for example,

consists of 2048 segments.

v Region address spaces are divided into 2-8 gigabyte units called regions. A

region is a block of sequential virtual addresses spanning 2-8 gigabytes,

beginning at a 2-gigabyte boundary. A 2-terabyte address space, for example,

consists of 2048 regions.

v A virtual address, accordingly, is divided into four principal fields: Bits 0-32 are

called the region index (RX), bits 33-43 are called the segment index (SX), bits

44-51 are called the page index (PX), and bits 52-63 are called the byte index

(BX).

A virtual address has the format shown in Figure 2 on page 9.

8 z/OS Basic Skills Information Center: z/OS concepts

v A block of auxiliary storage is a slot.

A page, a frame, and a slot are all the same size: Four kilobytes. An active virtual

storage page resides in a central storage frame. A virtual storage page that becomes

inactive resides in an auxiliary storage slot (in a paging data set). Figure 4 shows

the relationship of pages, frames, and slots.

In Figure 4, z/OS is performing paging for a program running in virtual storage.

The lettered boxes represent parts of the program. In this simplified view, program

parts A, E, F, and H are active and running in central storage frames, while parts

B, C, D, and G are inactive and have been moved to auxiliary storage slots. All of

the program parts, however, reside in virtual storage and have virtual storage

addresses.

z/OS uses a series of tables to determine whether a page is in real or auxiliary

storage, and where. To find a page of a program, z/OS checks the table for the

virtual address of the page, rather than searching through all of physical storage

for it. z/OS then transfers the page into central storage or out to auxiliary storage

as needed. This movement of pages between auxiliary storage slots and central

storage frames is called paging. Paging is key to understanding the use of virtual

storage in z/OS.

z/OS paging is transparent to the user. During job execution, only those pieces of

the application that are required are brought in, or paged in, to central storage.

The pages remain in central storage until no longer needed, or until another page

is required by the same application or a higher-priority application and no empty

central storage is available. To select pages for paging out to auxiliary storage,

z/OS follows a "Least Used" algorithm. That is, z/OS assumes that a page that has

not been used for some time will probably not be used in the near future.

How paging works in z/OS

In addition to the DAT hardware and the segment and page tables required for

address translation, paging activity involves a number of system components to

handle the movement of pages and several additional tables to keep track of the

most current version of each page.

To understand how paging works, assume that DAT encounters an invalid page

table entry during address translation, indicating that a page is required that is not

in a central storage frame. To resolve this page fault, the system must bring the

page in from auxiliary storage. First, however, it must locate an available central

storage frame. If none is available, the request must be saved and an assigned

frame freed. To free a frame, the system copies its contents to auxiliary storage and

marks its corresponding page table entry as invalid. This operation is called a

page-out.

Figure 4. Frames, pages, and slots

10 z/OS Basic Skills Information Center: z/OS concepts

After a frame is located for the required page, the contents of the page are copied

from auxiliary storage to central storage and the page table invalid bit is set off.

This operation is called a page-in.

Paging can also take place when z/OS loads an entire program into virtual

storage. z/OS obtains virtual storage for the user program and allocates a central

storage frame to each page. Each page is then active and subject to the normal

paging activity; that is, the most active pages are retained in central storage while

the pages not currently active might be paged out to auxiliary storage.

z/OS tries to keep an adequate supply of available central storage frames on hand.

When a program refers to a page that is not in central storage, z/OS uses a central

storage page frame from a supply of available frames.

When this supply becomes low, z/OS uses page stealing to replenish it, that is, it

takes a frame assigned to an active user and makes it available for other work. The

decision to steal a particular page is based on the activity history of each page

currently residing in a central storage frame. Pages that have not been active for a

relatively long time are good candidates for page stealing.

z/OS uses a sophisticated paging algorithm to efficiently manage virtual storage

based on which pages were most recently used. An unreferenced interval count

indicates how long it has been since a program referenced the page. At regular

intervals, the system checks the reference bit for each page frame. If the reference

bit is off– that is, the frame has not been referenced– the system adds to the

frame's unreferenced interval count. It adds the number of seconds since this

address space last had the reference count checked. If the reference bit is on, the

frame has been referenced and the system turns it off and sets the unreferenced

interval count for the frame to zero. Frames with the highest unreferenced interval

counts are the ones most likely to be stolen.

Swapping and the working set

Swapping is the process of transferring all of the pages of an address space

between central storage and auxiliary storage.

A swapped-in address space is active, having pages in central storage frames and

pages in auxiliary storage slots. A swapped-out address space is inactive; the

address space resides on auxiliary storage and cannot execute until it is swapped

in.

While only a subset of the address space's pages (known as its working set) would

likely be in central storage at any time, swapping effectively moves the entire

address space. It is one of several methods that z/OS uses to balance the system

workload and ensure that an adequate supply of available central storage frames is

maintained.

Swapping is performed by the System Resource Manager (SRM) component, in

response to recommendations from the Workload Manager (WLM) component.

What is storage protection?

Many programs and users are competing for the use of the system. So how does

z/OS preserves the integrity of each user's work? One technique is through the use

of multiple storage protect keys.

Chapter 1. z/OS operating system: Providing virtual environments since the 1960s 11

Under z/OS, the information in central storage is protected from unauthorized use

by means of multiple storage protect keys. A control field in storage called a key is

associated with each 4K frame of central storage.

When a request is made to modify the contents of a central storage location, the

key associated with the request is compared to the storage protect key. If the keys

match or the program is executing in key 0, the request is satisfied. If the key

associated with the request does not match the storage key, the system rejects the

request and issues a program exception interruption.

When a request is made to read (or fetch) the contents of a central storage location,

the request is automatically satisfied unless the fetch protect bit is on, indicating

that the frame is fetch-protected. When a request is made to access the contents of

a fetch-protected central storage location, the key in storage is compared to the key

associated with the request. If the keys match, or the requestor is in key 0, the

request is satisfied. If the keys do not match, and the requestor is not in key 0, the

system rejects the request and issues a program exception interruption.

z/OS uses 16 storage protect keys. A specific key is assigned according to the type

of work being performed. The key is stored in bits 8 through 11 of the program

status word (PSW). A PSW is assigned to each job in the system.

Storage protect keys 0 through 7 are used by the z/OS base control program (BCP)

and various subsystems and middleware products. Storage protect key 0 is the

master key. Its use is restricted to those parts of the BCP that require almost

unlimited store and fetch capabilities. In almost any situation, a storage protect key

of 0 associated with a request to access or modify the contents of a central storage

location means that the request will be satisfied.

Storage protect keys 8 through 15 are assigned to users. Because all users are

isolated in private address spaces, most users– those whose programs run in a

virtual region– can use the same storage protect key. These users are called V=V

(virtual = virtual) users and are assigned a key of 8.

The role of storage managers

Central storage frames and auxiliary storage slots, and the virtual storage pages

that they support, are managed by separate components of z/OS. These

components are known as the real storage manager (not central storage manager),

the auxiliary storage manager, and the virtual storage manager.

Real storage manager

The real storage manager or RSM keeps track of the contents of central

storage. It manages the paging activities– such as page-in, page-out, and

page stealing– and helps with swapping an address space in or out. RSM

also performs page fixing, which is marking pages as unavailable for

stealing.

Auxiliary storage manager

The auxiliary storage manager or ASM uses the system's page data sets to

keep track of auxiliary storage slots. Specifically:

v Slots for virtual storage pages that are not in central storage frames

v Slots for pages that do not occupy frames but, because the frame's

contents have not been changed, the slots are still valid.

When a page-in or page-out is required, ASM works with RSM to locate

the proper central storage frames and auxiliary storage slots.

12 z/OS Basic Skills Information Center: z/OS concepts

剩余119页未读，继续阅读

athona2008

粉丝: 0

深入理解IBM z/OS操作系统

z/os concepts

db2_sql--for OS/390 and z/OS

Z/OS基础概念入门：学习与实践指南

OS总汇.7z.002

Concepts of SAS Files

was8.5 concepts,planing and design guide.pdf

OS_introduction

IBM RedBook :WebSphere Application Sever V7 Concepts, Planning, and Design

Start with DB2 for z

springboot应急救援物资管理系统.zip

最新资源