Teil 10 System Address Spaces

Betriebssysteme
it-Akademie Bayern
z/OS und OS/390 Lehrgang 2009
Prof. Dr.-Ing. Wilhelm G. Spruth
Teil 10
System Address Spaces
bs 0906 ww6
© copyright W. G. Spruth, 10-2000
wgs 03-95
What is an Address Space
The range of virtual addresses that the operating
system assigns to a user or separately running
program is called an address space. This is the area
of contiguous virtual addresses available for
executing instructions and storing data. The range
of virtual addresses in an address space starts at
zero and can extend to the highest address
permitted by the operating system architecture.
z/OS provides each user with a unique address
space and maintains the distinction between the
programs and data belonging to each address
space. Within each address space the user can start
multiple tasks, using task control blocks or TCBs
that allow user multiprogramming.
The private areas within one user’s address space
are isolated from the private areas within other
address spaces, and this provides much of the
operating system’s security. Yet, each address
space also contains a common area that is
accessible to every other address space.
Aufteilung des virtuellen Adressenraums (Namensraum) in
einen Bereich für den Überwacher (Kernel) und in mehrere
Bereiche für mehrere Prozesse.
es 0607 ww6
wgs 11-02
z/OS and Unix Address Spaces
In some ways an address space in z/OS is
analogous to a UNIX process and the address space
identifier (ASID) is like a process ID (PID). Further,
TCBs are like threads, in that the UNIX kernel
supports multiple threads at once.
The use of address spaces in z/OS, however, holds
some special advantages. Both z/OS and UNIX, for
example, provide APIs to allow in-memory data to be
shared between processes. In z/OS, a user can
access another user’s address spaces directly
through cross-memory services.
Similarly, UNIX has the concept of Shared Memory
functions, and these can be used on UNIX without
special authority. In contrast to UNIX, z/OS crossmemory services require the issuing program to
have special authority, controlled by the authorized
program facility (APF). This method allows efficient
and secure access to data owned by others, data
owned by the user but stored in another address
space for convenience, and for rapid and secure
communication with services like transaction
managers and database managers.
To allow z/OS and OS/390 to be delivered to the
customer in a customer-tailored version, IBM ships
these systems in the form of z/OS or OS/390
elements and features. z/OS and OS/390 consist of
base elements and two types of optional features.
The base elements are part of every z/OS or OS/390
order.
z/OS base elements und
optional features
The z/OS and OS/390 system base elements deliver
essential operating functions. In addition to the
services provided by the BCP, other functions, such
as communications support, online access, host
graphics, and online viewing of publications are also
considered base elements.
In addition to the base elements, the z/OS and
OS/390 optional features have a high affinity to the
base. There are two types of optional features:
One type of feature is always shipped with the z/OS
or OS/390 system whether they are ordered or not.
These features support dynamic enablement which
allows you to dynamically enable and disable them. If such a feature is ordered, it is shipped enabled for
use. - If such a feature is not ordered, it is shipped
disabled. It can later be enabled.
A second type of optional feature is not shipped
automatically. These features must be ordered
specifically.
z/OS base elements und
optional features
In addition to the base elements, IBM also includes a
set of optional features in each z/OS or OS/390
package. These optional features support dynamic
enablement.
Basic Control Program
Der z/OS Kernel wird als“Basic Control Program”
(BCP) bezeichnet. Er stellt die wichtigsten
Dienstleistungen des Betriebssystems zur
Verfügung. Der BCP für z/OS und OS/390 geht aus
dem früheren Multiple Virtual Storage (MVS)
Operating System hervor. Aus diesem Grund werden
die Begriffe BCP und MVS in den Documenten für
z/OS and OS/390 oft austauschbar benutzt.
Zusätzliche System Address Spaces
Ähnlich wie allen anderen modernen
Betriebssysteme starten OS/390 und z/OS eine
ganze Reihe von Systemprozessen, die in eigenen
virtuellen Adressenräumen (Regions) laufen,
getrennt von den virtuellen Adressenräumen, die für
Benutzerprozesse angelegt werden (und die Private
Area eines Address Spaces verwenden). Die
Adressenräume der Systemprozesse sind durch
Protektion Keys gegen einen unauthorisierten
Zugriff geschützt.
System Address Spaces eines
Operationsfähigen z/OS oder OS/390
Systems
System Address Spaces
The master scheduler subsystem
The master scheduler subsystem is used to
establish communication between the operating
system and the primary job entry subsystem, which
can be JES2 or JES3. When you start z/OS, master
initialization routines initialize system services, such
as the system log and communication task, and start
the master scheduler address space, which
becomes address space number one (ASID=1).
Then, the master scheduler may start the job entry
subsystem (JES2 or JES3). JES is the primary job
entry subsystem.
Then other defined subsystems are started. All
subsystems are defined in the IEFSSNxx member of
PARMLIB. These subsystems are secondary
subsystems.
An initial MSTJCL00 load module can be found in
SYS1.LINKLIB library.
Protection Keys
Mit Hilfe der Speicherschutzschlüssel des
Speicherschutz-Schnellspeichers (Protection Key
Store) werden die Systemprozesse vor einem
unauthorisierten Zugriff geschützt
The authorized program facility or APF is used to allow the installation to identify system or user
programs that can use sensitive system functions. To maintain system security and integrity, a
program must be authorized by the APF before it can access restricted functions, such as supervisor
calls (SVC) or SVC paths. APF helps to avoid integrity exposures; the installation identifies which
libraries contain special functions or programs. These libraries are then called APF libraries.
bs 0414 ww6
wgs 09-02
SpeicherschutzSchlüssel
0
Nutzung
Genutzt vor allem vom
Betriebssystem Kernel.
Erlaubt Zugriff auf den
gesamten Speicher
1–7
von verschiedenen
Subsystemen verwendet
8
Default für Anwendungen
9
CICS Speicherschutz
10 - 15
6 unterschiedliche Prozesse
in virtual = real mode
Austausch von Daten
zwischen Adressenräumen
Methoden, um Daten zwischen
Address Spaces auszutauschen,
1.Service Request Block
2.Cross-Memory-Funktionen
3.Access Registers
4.Shared Memory
Es 0609 ww6
wgs 11-02
Service Request Block
Ein SRB (Service Request Block) ist eine Kontrollstruktur
zur Abarbeitung von Dienstprogrammen oder Programmen
außerhalb des Kontextes eines Address Spaces. Mit dieser
Methode lassen sich auch Daten zwischen Address Spaces
austauschen. Diese Datenaustauschmethode ist vor allem
dann sinnvoll, wenn ein Programm bestimmte Daten in
einen anderen Address Space verschieben oder kopieren
möchte, um diese Daten den dortigen Programmen
zugänglich zu machen.
Dazu kann das Programm einen SRB aufsetzen, der unter
der Kontrolle des Ziel Address Space abläuft. Gleichzeitig
muss das Ursprungsprogramm die zu kopierenden Daten
in den Common Storage kopieren. Nachdem der SRB
aufgesetzt ist, geht die Kontrolle von dem
Ursprungsprogramm an den Dispatcher über. Durch die
Ausführung des SRBs kommt das mit dem SRB assoziierte
Programm zur Ausführung, und die Daten werden durch
dieses Programm in den Ziel-Address Space kopiert.
Diese Methode hat einen weiteren Vorteil. Zu dem
Zeitpunkt, an dem das Ursprungs programm die Daten in
den Ziel-Address Space kopieren möchte, weiß es nicht, ob
sich dieser Address Space, beziehungsweise der
Speicherbereich, in den die Daten hinkopiert werden
sollen, im Speicher befindet. Über den SRB, der als
ausführbare Einheit des Ziel- Address Space abläuft, stellt
das System sicher, dass der Address Space und die
benötigten Speicherbereiche verfügbar sind.
Ein Nachteil dieser Methode ist, dass, wenn auch nur
kurzzeitig, Common Storage benötigt wird.
Common Area
Common Area ist der Bereich, der in allen Adressenräumen
identisch aussieht. Die Common Area wird in jeden
Adresseraum abgebildet.
CSA/ECSA (Extended) Common Service Area ist als
gemeinsam zu nutzender Speicher für Anwendungen und
Systemkomponenten gedacht. Diese Daten werden von
mehr als einem Address Space genutzt. Beispiele sind
VTAM und IMS Puffer.
bs 0408 ww6
wgs 09-02
Cross-Memory-Funktionen
Eine naheliegende Methode ist es, ein Programm im Ziel-Address
Space direkt aufzurufen. Dazu wurden im MVS eine Reihe von
Assembler-Operationen eingeführt, die diese Aufrufe in einfacher
Weise ermöglichen:
PC Program Call: Der Aufruf eines Programmes in einem anderen
Address Space.
PT Program Transfer: Übertragen der Kontrolle auf ein anderes
Programm. Dies dient dazu, um die Kontrolle zwischen
Programmen zu übergeben, die sich im Cross Memory Mode
befinden.
PR Program Return: Die Rückgabe der Kontrolle an das initiierende
Programm und das Beenden der Cross Memory Kommunikation.
Eine Cross-Memory-Kommunikation kann uber mehrere Address
Spaces erfolgen. Derjenige Address Space, der die Kette in Gang
gesetzt hat, wird dabei als Home Address Space bezeichnet. Der
Address Space, der gerade die Kontrolle hat, als Primary und der
Address Space, von dem entweder die letzte PC oder PT Operation
ausgegangen ist, als Secondary. Mit dieser Festlegung lassen sich
in einfacher Weise Operationen definieren, die Daten zwischen dem
Primary und Secondary Address Space kopieren. Diese heißen
Move Character to Primary (MVCP) und Move Character to
Secondary (MVCS).
Diese Technik benötigt (wie der Service Request Block) ein
Programm, das in einem anderen Address Space ausgeführt wird.
Der Vorteil dieser Mehrprogrammmethode ist, dass beide Address
Spaces zum Zeitpunkt des Datenaustausches adressierbar sind.
Access Registers
Zum Beispiel bei Address Spaces, die Non-Swappable sind, gibt es
die Möglichkeit, auf die Daten eines anderen Address Space direkt
zuzugreifen, ohne dafür ein zusätzliches Programm zu initiieren.
Dazu gibt es in einem z/OS System einen zusätzlichen Satz von 16
Access Registern (AR) heißen. Zu jedem General Purpose Register
(GPR) existiert ein Access Register. Über dieses Access Register
kann angegeben werden, für welchen Address Space die virtuelle
Adresse in dem GPR Gültigkeit besitzt.
In der Regel ist das AR gleich 0, was bedeutet, dass die virtuelle
Adresse im zugehörigen GPR für den momentan als Primary
definierten Address Space gilt. Über die Instruktion Set Secondary
Address Space (SSAR) lässt sich eine Identifizierung eines anderen
Address Space in ein Access Regidter laden.
Anschliessend können die Instruktionen MVCP und MVCS
ausgeführt werden, um auf Speicherbereiche eines anderen
Address Space zuzugreifen.
Mehrzweck Register
Access Register
0
31
0
15
0
1
2
15
S/390 Access Register
OP
ar 0536 ww6
R1
R3
R2
D2
wgs 10-02
OS/390 Adressenräume
Virtuelle Adressräume werden als “Spaces” oder “Regions”
bezeichnet. Die Größe war bisher auf 2 Gbyte begrenzt (31 Bit). Die
zSeries erweitert dies auf 63 Bit.
Ein Prozeß kann mehrere 2 Gbyte Spaces gleichzeitig verwalten. Es
wird zwischen Address Spaces und Data Spaces unterschieden.
Address
Space
Data
Space
Data
Space
Programmcode befindet sich in einem Address Space. Ein Prozess
kann auf die ihm zugeordneten Data spaces gleichzeitig zugreifen, z.
B. mit einem MOVE Maschinenbefehl.
Multitasking innerhalb eines Address Spaces ist möglich. Prozesse
und Threads werden durch Task Control Blöcke (TCB) und Service
Request Blöcke (SRB) verwaltet.
Der Inhalt eines Data Spaces geht verloren, wen der Prozess, der
diesen Data Space besitzt, terminiert wird.
es 0506z ww6
wgs 09-99
Shared Memory
Eine andere Methode für den Datenaustausch ist Shared
Memory, die hauptsächlich von Unix-Programmen
verwendet wird und mit Unix System Services in MVS
eingeführt wurde.
Es verwendet gemeinsam genutzte Seitentafeln
Data Spaces und Hierspaces
Neben den Address Spaces gibt es noch zwei weitere
virtuelle Speicherbereiche, die hauptsächlich dazu
existieren, die Adressierungsgrenze von 2 GB vor der
Einführung der 64-Bit-Adressierung zu erweitern. Dazu
wurden zwei Speicherbereiche mit MVS/XA eingeführt, die
ausschließlich für Benutzerdaten gedacht sind .
Data Spaces und Hiperspaces sind bis zu maximal 2 GB
groß und können mittels Systemdiensten von
Anwendungen erzeugt werden. Der Hauptunterschied
zwischen ihnen liegt in der Art, wie auf den Speicher
zugegriffen wird. Bei Data Spaces wird der Speicher direkt
adressiert. Der Zugriff erfolgt über Adressregister. Data
Spaces werden in der Regel von Systemkomponenten oder
Subsystemen verwendet. Der Zugriff ist auch nur über
Assembler-Operationen möglich.
Auf Hiperspaces kann zwar prinzipiell genauso zugegriffen
werden, allerdings werden hier Dienste angeboten, die es
Programmen erlauben, Pages aus dem Hiperspace in den
eigenen Address Space zu kopieren und dann den Inhalt
dieser Pages zu bearbeiten. Hiperspaces waren seinerzeit
als direktere Ausnutzung des Expanded Storages in MVS
und OS/390 Systemen gedacht.
1
IUCV/VMCF considerations
z/OS V1R9.0 Communications Server IP Configuration Guide
SC31-8775-11
The IUCV/VMCF inter-address space communication API enables applications
running in the same MVS™ image to communicate with each other without
requiring the services of the TCP/IP protocol stack. The VMCF/TNF subsystems
provide these services, which are still available in z/OS Communications
Server. Several components of TCP/IP in z/OS Communications Server
continue to make some use of these services for the purpose of inter-address
space communications. These include:
•
The AF_IUCV domain sockets for the TCP/IP C socket interface. The
AF_IUCV domain enables applications executing in the same z/OS®
image and using the TCP/IP C socket interface to communicate with
each other using a socket API, but without requiring the services of the
TCP/IP protocol stack, as no network flows result in these
communications. This is quite different from the more common AF_INET
domain that enables socket communication over a TCP/IP network.
AF_IUCV sockets continue to be supported in z/OS Communications
Server.
An example of a TCP/IP-provided application that exploits AF_IUCV
sockets is the SNMP Query Engine component (SQESERVE). The z/OS
UNIX® socket library provides a similar functionality to the AF_IUCV
domain sockets with its AF_UNIX domain. Users creating new
applications should consider using AF_UNIX domain sockets.
•
The Pascal socket interface also makes use of the IUCV/VMCF services
for a limited set of inter-address space communication flows. As a
result, any applications (provided by IBM® or others) that use the Pascal
socket API also still have a requirement for the VMCF/TNF subsystems.
TCP/IP provides several applications and commands that exploit these
interfaces, such as the SMTP and LPD servers, and the TSO TELNET,
HOMETEST, TESTSITE, RSH, REXEC, and LPR commands. IUCV/VMCF
services require the usage of an address space name of SYSTEM. This
means a TSO user cannot have the user ID name of SYSTEM.
Therefore, in z/OS Communications Server you must continue to configure and
start the VMCF and TNF subsystems as you did in TCP/IP V3R2. However,
because the VMCF/TNF subsystems are no longer used to communicate
directly with the TCP/IP protocol stack in z/OS Communications Server, the
amount of CPU they will consume will be significantly lower than in the TCP/IP
V3R2 environment.
ASCII- und EBCDIC Zeichentabellen
Beispiele:
ASCII R = Hex 52 ;
EBCDIC R = Hex D9 ;
Weltweit sind etwa 60% aller wirtschaftlich relevanten Daten sind im
8 Bit EBCDIC Standard (Extended Binary Coded Decimal
Interchange Code) abgespeichert. Etwa 40% aller wirtschaftlich
relevanten Daten sind im 7 Bit ASCII Standard (American Standard
Code for Information Interchange) bzw. seiner 8 bit Erweiterung
abgespeichert.
es 0182 ww6
wgs 06-02
Code Page, Locale
Ein „Character Set“ ist eine Menge von alpha-numerischen
Zeichen
Eine „Code Page“ ist eine Zuordnung von hexadezimalen
Werten zu den Zeichen eines Charakter Sets.
Eine „Locale“ beschreibt eine kulturelle Umgebung. Hierzu
gehören neben einer Code Page Spezifikation:
•
•
•
•
Sortierfolge
Datum Konventionen
Uhrzeit Konventionen
Darstellung numerischer Daten (z.B. Dezimal Komma,
Dezimalpunkt)
• Darstellung von Geldbeträgen
Wichtige OS/390 Code Pages sind:
•
•
•
•
273
1141
037
1047
Deutschland
Deutschland Euro
USA
USA
Für Entwicklungsaufgaben in C/C++ empfiehlt sich OS/390
Code Page 1047. Ein bekanntes Problem ist die
unterschiedliche Darstellung der rechteckigen Klammern in
Code Page 037 (normalerweise von OS/390 verwendet) und
Code Page 1047.
Ein 3270 Klient (Emulator) konvertiert automatisch ASCII in
EBCDIC. Die OS/390 Code Page läßt sich in der Regel im
3270 Klienten einstellen.
es 0565 ww6
wgs 07-01