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