| 翻訳と辞書 |
Multiple Virtual Storage, more commonly called MVS, was the most commonly used operating system on the System/370 and System/390 IBM mainframe computers. It was developed by IBM, but is unrelated to IBM's other mainframe operating systems, e.g., VSE, VM, TPF.First released in 1974, MVS was extended by program products with new names multiple times, first to MVS/SE (MVS/System Extension), next to MVS/SP (MVS/System Product) Version 1, next to MVS/XA (MVS/eXtended Architecture), next to MVS/ESA (MVS/Enterprise Systems Architecture), next to OS/390 and finally to z/OS (when 64-bit support was added with the zSeries models). IBM added Unix support (originally called OPEN EDITION) in MVS/SP V4.3 and has obtained POSIX and Unix certifications at several different levels. The MVS core remains fundamentally the same operating system. By design, programs written for MVS run on z/OS without modification.At first IBM described MVS as simply a new release of OS/VS2, but it was, in fact a major rewrite. OS/VS2 release 1 was an upgrade of OS/360 MVT that retained most of the original code and, like MVT, was mainly written in assembly language. The MVS core was almost entirely written in Assembler XF, although a few modules were written in PL/S, but not the performance-sensitive ones, in particular not the Input/Output Supervisor (IOS). IBM's use of "OS/VS2" emphasized upwards compatibility: application programs that ran under MVT did not even need recompiling to run under MVS. The same Job Control Language files could be used unchanged; utilities and other non-core facilities like TSO ran unchanged. IBM and users almost unanimously called the new system MVS from the start, and IBM continued to use the term ''MVS'' in the naming of later ''major'' versions such as MVS/XA.==Evolution of MVS==OS/360 MFT (Multitasking with a Fixed number of Tasks) provided multitasking: several memory partitions, each of a fixed size, were set up when the operating system was installed and when the operator redefined them. For example, there could be a small partition, two medium partitions, and a large partition. If there were two large programs ready to run, one would have to wait until the other finished and vacated the large partition.OS/360 MVT (Multitasking with a Variable number of Tasks) was an enhancement that further refined memory use. Instead of using fixed-size memory partitions, MVT allocated memory to regions for job steps as needed, provided enough ''contiguous'' physical memory was available. This was a significant advance over MFT's memory management, but had some weaknesses: if a job allocated memory dynamically (as most sort programs and database management systems do), the programmers had to estimate the job's maximum memory requirement and pre-define it for MVT. A job step that contained a mix of small and large programs wasted memory while the small programs ran. Most seriously, memory could become fragmented, i.e., the memory not used by current jobs could be divided into uselessly small chunks between the areas used by current jobs, and the only remedy was to wait some current jobs finished before starting any new ones.In the early 1970s IBM sought to mitigate these difficulties by introducing virtual memory (which IBM called "virtual storage"), which allowed programs to request address spaces larger than physical memory. The original implementations had a single virtual address space, shared by all jobs. OS/VS1 was OS/360 MFT within a single virtual address space; OS/VS2 SVS was OS/360 MVT within a single virtual address space. So OS/VS1 and SVS in principle had the same disadvantages as MFT and MVT, but the impacts were less severe because jobs could request much larger address spaces and the requests came out of a 16 MB pool even if physical storage was smaller.|}In the mid-1970s IBM introduced MVS, which not only supported virtual storage that was larger than the available real storage,Some processors could take more physical storage than the size of a single address space, but still much smaller than the aggregate size of a typical workload's virtual storage. as did SVS, but also allowed an indefinite number of applications to run in different address spaces. Two concurrent programs might try to access the same virtual memory address, but the virtual memory system redirected these requests to different areas of physical memory. Each of these address spaces consisted of three areas: an operating system (one instance shared by all jobs), an application area unique for each application, and a shared virtual area used for various purposes, including inter-job communication. IBM promised that application areas would always be at least 8 MB. This made MVS the perfect solution for business problems that resulted from the need to run more applications.MVS maximized processing potential by providing multiprogramming and multiprocessing capabilities. Like its MVT and OS/VS2 SVS predecessors, MVS supported multiprogramming; program instructions and associated data are scheduled by a control program and given processing cycles. Unlike a single-programming operating system, these systems maximize the use of the processing potential by dividing processing cycles among the instructions associated with several different concurrently running programs. This way, the control program does not have to wait for the I/O operation to complete before proceeding. By executing the instructions for multiple programs, the computer is able to switch back and forth between active and inactive programs.Early editions of MVS (mid-1970s) were among the first of the IBM OS series to support multiprocessor configurations, though the M65MP variant of OS/360 running on 360 Models 65 and 67 had provided limited multiprocessor support. The 360 Model 67 had also hosted the multiprocessor capable TSS/360, MTS and CP-67 operating systems. Because multiprocessing systems can execute instructions simultaneously, they offer greater processing power than single-processing system. As a result, MVS was able to address the business problems brought on by the need to process large amounts of data.Multiprocessing systems are either loosely coupled, which means that each computer has access to a common workload, or tightly coupled, which means that the computers share the same real storage and are controlled by a single copy of the operating system. MVS retained both the loosely coupled multiprocessing of Attached Support Processor (ASP)Via Job Entry Subsystem 3 (JES3) and the tightly coupled multiprocessing of OS/360 Model 65 Multiprocessing. In tightly coupled systems, two CPUs shared concurrent access to the same memory (and copy of the operating system) and peripherals, providing greater processing power and a degree of graceful degradation if one CPU failed. In loosely coupled configurations each of a group of processors (single and / or tightly coupled) had its own memory and operating system but shared peripherals and the operating system component JES3 allowed managing the whole group from one console. This provided greater resilience and let operators decide which processor should run which jobs from a central job queue. MVS JES3 gave users the opportunity to network together two or more data processing systems via shared disks and Channel-to-Channedl Adapters (CTCA's). This capability eventually became available to JES2 users as Multi-Access SPOOL (MAS).MVS originally supported 24-bit addressing (i.e., up to 16 MB). As the underlying hardware progressed, it supported 31-bit (XA and ESA; up to 2048 MB) and now (as z/OS) 64-bit addressing. The most significant motives for the rapid upgrade to 31-bit addressing were the growth of large transaction-processing networks, mostly controlled by CICS, which ran in a single address space—and the DB2 relational database management system needed more than 8 MB of application address space to run efficiently. (Early versions were configured into two address spaces that communicated via the shared virtual area, but this imposed a significant overhead since all such communications had transmit via the operating system.)The main user interfaces to MVS are: Job Control Language (JCL), which was originally designed for batch processing but from the 1970s onwards was also used to start and allocate resources to long-running interactive jobs such CICS; and TSO (Time Sharing Option), the interactive time-sharing interface, which was mainly used to run development tools and a few end-user information systems. ISPF is a TSO application for users on 3270-family terminals (and later, on VM as well), which allows the user to accomplish the same tasks as TSO's command line but in a menu and form oriented manner, and with a full screen editor and file browser. TSO's basic interface is command line, although facilities were added later for form-driven interfaces).MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called ''software recovery''. IBM decided to do this after years of practical real-world experience with MVT in the business world. System failures were now having major impacts on customer businesses, and IBM decided to take a major design jump, to assume that despite the very best software development and testing techniques, that 'problems WILL occur.' This profound assumption was pivotal in adding great percentages of fault-tolerance code to the system and likely contributed to the system's success in tolerating software and hardware failures. Statistical information is hard to come by to prove the value of these design features (how can you measure 'prevented' or 'recovered' problems?), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.This design specified a hierarchy of error-handling programs, in system (kernel/'privileged') mode, called Functional Recovery Routines, and in user ('task' or 'problem program') mode, called "ESTAE" (Extended Specified Task Abnormal Exit routines) that were invoked in case the system detected an error (actually, hardware processor or storage error, or software error). Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).Thus, with each error the system captured diagnostic data, and attempted to perform a repair and keep the system up. The worst thing possible was to take down a user address space (a 'job') in the case of unrepaired errors. Though it was an initial design point, it was not until the most recent MVS version (z/OS), that recovery program was not only guaranteed its own recovery routine, but each recovery routine now has its own recovery routine. This recovery structure was embedded in the basic MVS control program, and programming facilities are available and used by application program developers and 3rd party developers.Practically, the MVS software recovery made problem debugging both easier and more difficult. Software recovery requires that programs leave 'tracks' of where they are and what they are doing, thus facilitating debugging—but the fact that processing progresses despite an error can overwrite the tracks. Early date capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.IBM included additional criteria for a major software problem that required IBM service. If a mainline component failed to initiate software recovery, that was considered a valid reportable failure. Also, if a recovery routine failed to collect significant diagnostic data such that the original problem was solvable by data collected by that recovery routine, IBM standards dictated that this fault was reportable and required repair. Thus, IBM standards, when rigorously applied, encouraged continuous improvement.IBM introduced an on-demand hypervisor, a major serviceability tool, called Dynamic Support System (DSS), in the first release of MVS. This facility could be invoked to initiate a session to create diagnostic procedures, or invoke already-stored procedures. The procedures 'trapped' special events, such as the loading of a program, device I/O, system procedure calls, and then triggered the activation of the previously defined procedures. These procedures, which could be invoked recursively, allowed for reading and writing of data, and alteration of instruction flow. Program Event Recording hardware was used. Due to the overhead of this tool, it was removed from customer-available MVS systems. Program-Event Recording (PER) exploitation was performed by the enhancement of the diagnostic "SLIP" command with the introduction of the PER support (SLIP/Per) in SU 64/65 (1978).Multiple copies of MVS (or other IBM operating systems) could share thesame machine if that machine was controlled by VM/370. In this case VM/370 was the real operating system, and regarded the "guest" operating systems as applications with unusually high privileges. As a result of later hardware enhancements one instance of an operating system (either MVS, or VM with guests, or other) could also occupy a Logical Partition (LPAR) instead of an entire physical system.Multiple MVS instances can be organized and collectively administered in a structure called a ''systems complex'' or ''sysplex'', introduced in September, 1990. Instances interoperate through a software component called a Cross-system Coupling Facility (XCF) and a hardware component called a ''Hardware Coupling Facility'' (CF or Integrated Coupling Facility, ICF, if co-located on the same mainframe hardware). Multiple sysplexes can be joined via standard network protocols such as IBM's proprietary Systems Network Architecture (SNA) or, more recently, via TCP/IP. The z/OS operating system (MVS' most recent descendant) also has native support to execute POSIX and Single UNIX Specification applications. The support began with MVS/SP V4R3, and IBM has obtained UNIX 95 certification for z/OS V1R2 and later.(【引用サイトリンク】title=IBM Corporation - UNIX 95 )The system is typically used in business and banking, and applications are often written in COBOL. COBOL programs were traditionally used with transaction processing systems like IMS and CICS. For a program running in CICS, special EXEC CICS statements are inserted in the COBOL source code. A preprocessor (translator) replaces those EXEC CICS statements with the appropriate COBOL code to call CICS before the program is compiled — not altogether unlike SQL used to call DB2. Applications can also be written in other languages such as C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX. Language support is packaged as a common component called "Language Environment" or "LE" to allow uniform debugging, tracing, profiling, and other language independent functions.MVS systems are traditionally accessed by 3270 terminals or by PCs running 3270 emulators. However, many mainframe applications these days have custom web or GUI interfaces. The z/OS operating system has built-in support for TCP/IP. System management, done in the past with a 3270 terminal, is now done through the Hardware Management Console (HMC) and, increasingly, Web interfaces. Operator consoles are provided through 2074 emulators, so you are unlikely to see any S/390 or zSeries processor with a real 3270 connected to it.The native character encoding scheme of MVS and its peripherals is EBCDIC, but the TR instruction made it easy to translate to other 7- and 8-bit codes. Over time IBM added hardware-accelerated services to perform translation to and between larger codes, hardware-specific service for Unicode transforms and software support of, e.g., ASCII, ISO/IEC 8859, UTF-8, UTF-16, and UTF-32. The software translation services take source and destination code pages as inputs.
Multiple Virtual Storage, more commonly called MVS, was the most commonly used operating system on the System/370 and System/390 IBM mainframe computers. It was developed by IBM, but is unrelated to IBM's other mainframe operating systems, e.g., VSE, VM, TPF.
First released in 1974, MVS was extended by program products with new names multiple times, first to MVS/SE (MVS/System Extension), next to MVS/SP (MVS/System Product) Version 1, next to MVS/XA (MVS/eXtended Architecture), next to MVS/ESA (MVS/Enterprise Systems Architecture), next to OS/390 and finally to z/OS (when 64-bit support was added with the zSeries models). IBM added Unix support (originally called OPEN EDITION) in MVS/SP V4.3 and has obtained POSIX and Unix certifications at several different levels. The MVS core remains fundamentally the same operating system. By design, programs written for MVS run on z/OS without modification.
At first IBM described MVS as simply a new release of OS/VS2, but it was, in fact a major rewrite. OS/VS2 release 1 was an upgrade of OS/360 MVT that retained most of the original code and, like MVT, was mainly written in assembly language. The MVS core was almost entirely written in Assembler XF, although a few modules were written in PL/S, but not the performance-sensitive ones, in particular not the Input/Output Supervisor (IOS). IBM's use of "OS/VS2" emphasized upwards compatibility: application programs that ran under MVT did not even need recompiling to run under MVS. The same Job Control Language files could be used unchanged; utilities and other non-core facilities like TSO ran unchanged. IBM and users almost unanimously called the new system MVS from the start, and IBM continued to use the term ''MVS'' in the naming of later ''major'' versions such as MVS/XA.
==Evolution of MVS==
OS/360 MFT (Multitasking with a Fixed number of Tasks) provided multitasking: several memory partitions, each of a fixed size, were set up when the operating system was installed and when the operator redefined them. For example, there could be a small partition, two medium partitions, and a large partition. If there were two large programs ready to run, one would have to wait until the other finished and vacated the large partition.
OS/360 MVT (Multitasking with a Variable number of Tasks) was an enhancement that further refined memory use. Instead of using fixed-size memory partitions, MVT allocated memory to regions for job steps as needed, provided enough ''contiguous'' physical memory was available. This was a significant advance over MFT's memory management, but had some weaknesses: if a job allocated memory dynamically (as most sort programs and database management systems do), the programmers had to estimate the job's maximum memory requirement and pre-define it for MVT. A job step that contained a mix of small and large programs wasted memory while the small programs ran. Most seriously, memory could become fragmented, i.e., the memory not used by current jobs could be divided into uselessly small chunks between the areas used by current jobs, and the only remedy was to wait some current jobs finished before starting any new ones.
In the early 1970s IBM sought to mitigate these difficulties by introducing virtual memory (which IBM called "virtual storage"), which allowed programs to request address spaces larger than physical memory. The original implementations had a single virtual address space, shared by all jobs. OS/VS1 was OS/360 MFT within a single virtual address space; OS/VS2 SVS was OS/360 MVT within a single virtual address space. So OS/VS1 and SVS in principle had the same disadvantages as MFT and MVT, but the impacts were less severe because jobs could request much larger address spaces and the requests came out of a 16 MB pool even if physical storage was smaller.
|}
In the mid-1970s IBM introduced MVS, which not only supported virtual storage that was larger than the available real storage,〔Some processors could take more physical storage than the size of a single address space, but still much smaller than the aggregate size of a typical workload's virtual storage.〕 as did SVS, but also allowed an indefinite number of applications to run in different address spaces. Two concurrent programs might try to access the same virtual memory address, but the virtual memory system redirected these requests to different areas of physical memory. Each of these address spaces consisted of three areas: an operating system (one instance shared by all jobs), an application area unique for each application, and a shared virtual area used for various purposes, including inter-job communication. IBM promised that application areas would always be at least 8 MB. This made MVS the perfect solution for business problems that resulted from the need to run more applications.
MVS maximized processing potential by providing multiprogramming and multiprocessing capabilities. Like its MVT and OS/VS2 SVS predecessors, MVS supported multiprogramming; program instructions and associated data are scheduled by a control program and given processing cycles. Unlike a single-programming operating system, these systems maximize the use of the processing potential by dividing processing cycles among the instructions associated with several different concurrently running programs. This way, the control program does not have to wait for the I/O operation to complete before proceeding. By executing the instructions for multiple programs, the computer is able to switch back and forth between active and inactive programs.
Early editions of MVS (mid-1970s) were among the first of the IBM OS series to support multiprocessor configurations, though the M65MP variant of OS/360 running on 360 Models 65 and 67 had provided limited multiprocessor support. The 360 Model 67 had also hosted the multiprocessor capable TSS/360, MTS and CP-67 operating systems. Because multiprocessing systems can execute instructions simultaneously, they offer greater processing power than single-processing system. As a result, MVS was able to address the business problems brought on by the need to process large amounts of data.
Multiprocessing systems are either loosely coupled, which means that each computer has access to a common workload, or tightly coupled, which means that the computers share the same real storage and are controlled by a single copy of the operating system. MVS retained both the loosely coupled multiprocessing of Attached Support Processor (ASP)〔Via Job Entry Subsystem 3 (JES3)〕 and the tightly coupled multiprocessing of OS/360 Model 65 Multiprocessing. In tightly coupled systems, two CPUs shared concurrent access to the same memory (and copy of the operating system) and peripherals, providing greater processing power and a degree of graceful degradation if one CPU failed. In loosely coupled configurations each of a group of processors (single and / or tightly coupled) had its own memory and operating system but shared peripherals and the operating system component JES3 allowed managing the whole group from one console. This provided greater resilience and let operators decide which processor should run which jobs from a central job queue. MVS JES3 gave users the opportunity to network together two or more data processing systems via shared disks and Channel-to-Channedl Adapters (CTCA's). This capability eventually became available to JES2 users as Multi-Access SPOOL (MAS).
MVS originally supported 24-bit addressing (i.e., up to 16 MB). As the underlying hardware progressed, it supported 31-bit (XA and ESA; up to 2048 MB) and now (as z/OS) 64-bit addressing. The most significant motives for the rapid upgrade to 31-bit addressing were the growth of large transaction-processing networks, mostly controlled by CICS, which ran in a single address space—and the DB2 relational database management system needed more than 8 MB of application address space to run efficiently. (Early versions were configured into two address spaces that communicated via the shared virtual area, but this imposed a significant overhead since all such communications had transmit via the operating system.)
The main user interfaces to MVS are: Job Control Language (JCL), which was originally designed for batch processing but from the 1970s onwards was also used to start and allocate resources to long-running interactive jobs such CICS; and TSO (Time Sharing Option), the interactive time-sharing interface, which was mainly used to run development tools and a few end-user information systems. ISPF is a TSO application for users on 3270-family terminals (and later, on VM as well), which allows the user to accomplish the same tasks as TSO's command line but in a menu and form oriented manner, and with a full screen editor and file browser. TSO's basic interface is command line, although facilities were added later for form-driven interfaces).
MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called ''software recovery''. IBM decided to do this after years of practical real-world experience with MVT in the business world. System failures were now having major impacts on customer businesses, and IBM decided to take a major design jump, to assume that despite the very best software development and testing techniques, that 'problems WILL occur.' This profound assumption was pivotal in adding great percentages of fault-tolerance code to the system and likely contributed to the system's success in tolerating software and hardware failures. Statistical information is hard to come by to prove the value of these design features (how can you measure 'prevented' or 'recovered' problems?), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.
This design specified a hierarchy of error-handling programs, in system (kernel/'privileged') mode, called Functional Recovery Routines, and in user ('task' or 'problem program') mode, called "ESTAE" (Extended Specified Task Abnormal Exit routines) that were invoked in case the system detected an error (actually, hardware processor or storage error, or software error). Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).
Thus, with each error the system captured diagnostic data, and attempted to perform a repair and keep the system up. The worst thing possible was to take down a user address space (a 'job') in the case of unrepaired errors. Though it was an initial design point, it was not until the most recent MVS version (z/OS), that recovery program was not only guaranteed its own recovery routine, but each recovery routine now has its own recovery routine. This recovery structure was embedded in the basic MVS control program, and programming facilities are available and used by application program developers and 3rd party developers.
Practically, the MVS software recovery made problem debugging both easier and more difficult. Software recovery requires that programs leave 'tracks' of where they are and what they are doing, thus facilitating debugging—but the fact that processing progresses despite an error can overwrite the tracks. Early date capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.
IBM included additional criteria for a major software problem that required IBM service. If a mainline component failed to initiate software recovery, that was considered a valid reportable failure. Also, if a recovery routine failed to collect significant diagnostic data such that the original problem was solvable by data collected by that recovery routine, IBM standards dictated that this fault was reportable and required repair. Thus, IBM standards, when rigorously applied, encouraged continuous improvement.
IBM introduced an on-demand hypervisor, a major serviceability tool, called Dynamic Support System (DSS), in the first release of MVS. This facility could be invoked to initiate a session to create diagnostic procedures, or invoke already-stored procedures. The procedures 'trapped' special events, such as the loading of a program, device I/O, system procedure calls, and then triggered the activation of the previously defined procedures. These procedures, which could be invoked recursively, allowed for reading and writing of data, and alteration of instruction flow. Program Event Recording hardware was used. Due to the overhead of this tool, it was removed from customer-available MVS systems. Program-Event Recording (PER) exploitation was performed by the enhancement of the diagnostic "SLIP" command with the introduction of the PER support (SLIP/Per) in SU 64/65 (1978).
Multiple copies of MVS (or other IBM operating systems) could share the
same machine if that machine was controlled by VM/370. In this case VM/370 was the real operating system, and regarded the "guest" operating systems as applications with unusually high privileges. As a result of later hardware enhancements one instance of an operating system (either MVS, or VM with guests, or other) could also occupy a Logical Partition (LPAR) instead of an entire physical system.
Multiple MVS instances can be organized and collectively administered in a structure called a ''systems complex'' or ''sysplex'', introduced in September, 1990. Instances interoperate through a software component called a Cross-system Coupling Facility (XCF) and a hardware component called a ''Hardware Coupling Facility'' (CF or Integrated Coupling Facility, ICF, if co-located on the same mainframe hardware). Multiple sysplexes can be joined via standard network protocols such as IBM's proprietary Systems Network Architecture (SNA) or, more recently, via TCP/IP. The z/OS operating system (MVS' most recent descendant) also has native support to execute POSIX and Single UNIX Specification applications. The support began with MVS/SP V4R3, and IBM has obtained UNIX 95 certification for z/OS V1R2 and later.〔(【引用サイトリンク】title=IBM Corporation - UNIX 95 )〕
The system is typically used in business and banking, and applications are often written in COBOL. COBOL programs were traditionally used with transaction processing systems like IMS and CICS. For a program running in CICS, special EXEC CICS statements are inserted in the COBOL source code. A preprocessor (translator) replaces those EXEC CICS statements with the appropriate COBOL code to call CICS before the program is compiled — not altogether unlike SQL used to call DB2. Applications can also be written in other languages such as C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX. Language support is packaged as a common component called "Language Environment" or "LE" to allow uniform debugging, tracing, profiling, and other language independent functions.
MVS systems are traditionally accessed by 3270 terminals or by PCs running 3270 emulators. However, many mainframe applications these days have custom web or GUI interfaces. The z/OS operating system has built-in support for TCP/IP. System management, done in the past with a 3270 terminal, is now done through the Hardware Management Console (HMC) and, increasingly, Web interfaces. Operator consoles are provided through 2074 emulators, so you are unlikely to see any S/390 or zSeries processor with a real 3270 connected to it.
The native character encoding scheme of MVS and its peripherals is EBCDIC, but the TR instruction made it easy to translate to other 7- and 8-bit codes. Over time IBM added hardware-accelerated services to perform translation to and between larger codes, hardware-specific service for Unicode transforms and software support of, e.g., ASCII, ISO/IEC 8859, UTF-8, UTF-16, and UTF-32. The software translation services take source and destination code pages as inputs.
抄文引用元・出典: フリー百科事典『 regions for job steps as needed, provided enough ''contiguous'' physical memory was available. This was a significant advance over MFT's memory management, but had some weaknesses: if a job allocated memory dynamically (as most sort programs and database management systems do), the programmers had to estimate the job's maximum memory requirement and pre-define it for MVT. A job step that contained a mix of small and large programs wasted memory while the small programs ran. Most seriously, memory could become fragmented, i.e., the memory not used by current jobs could be divided into uselessly small chunks between the areas used by current jobs, and the only remedy was to wait some current jobs finished before starting any new ones.In the early 1970s IBM sought to mitigate these difficulties by introducing virtual memory (which IBM called "virtual storage"), which allowed programs to request address spaces larger than physical memory. The original implementations had a single virtual address space, shared by all jobs. OS/VS1 was OS/360 MFT within a single virtual address space; OS/VS2 SVS was OS/360 MVT within a single virtual address space. So OS/VS1 and SVS in principle had the same disadvantages as MFT and MVT, but the impacts were less severe because jobs could request much larger address spaces and the requests came out of a 16 MB pool even if physical storage was smaller.|}In the mid-1970s IBM introduced MVS, which not only supported virtual storage that was larger than the available real storage,Some processors could take more physical storage than the size of a single address space, but still much smaller than the aggregate size of a typical workload's virtual storage. as did SVS, but also allowed an indefinite number of applications to run in different address spaces. Two concurrent programs might try to access the same virtual memory address, but the virtual memory system redirected these requests to different areas of physical memory. Each of these address spaces consisted of three areas: an operating system (one instance shared by all jobs), an application area unique for each application, and a shared virtual area used for various purposes, including inter-job communication. IBM promised that application areas would always be at least 8 MB. This made MVS the perfect solution for business problems that resulted from the need to run more applications.MVS maximized processing potential by providing multiprogramming and multiprocessing capabilities. Like its MVT and OS/VS2 SVS predecessors, MVS supported multiprogramming; program instructions and associated data are scheduled by a control program and given processing cycles. Unlike a single-programming operating system, these systems maximize the use of the processing potential by dividing processing cycles among the instructions associated with several different concurrently running programs. This way, the control program does not have to wait for the I/O operation to complete before proceeding. By executing the instructions for multiple programs, the computer is able to switch back and forth between active and inactive programs.Early editions of MVS (mid-1970s) were among the first of the IBM OS series to support multiprocessor configurations, though the M65MP variant of OS/360 running on 360 Models 65 and 67 had provided limited multiprocessor support. The 360 Model 67 had also hosted the multiprocessor capable TSS/360, MTS and CP-67 operating systems. Because multiprocessing systems can execute instructions simultaneously, they offer greater processing power than single-processing system. As a result, MVS was able to address the business problems brought on by the need to process large amounts of data.Multiprocessing systems are either loosely coupled, which means that each computer has access to a common workload, or tightly coupled, which means that the computers share the same real storage and are controlled by a single copy of the operating system. MVS retained both the loosely coupled multiprocessing of Attached Support Processor (ASP)Via Job Entry Subsystem 3 (JES3) and the tightly coupled multiprocessing of OS/360 Model 65 Multiprocessing. In tightly coupled systems, two CPUs shared concurrent access to the same memory (and copy of the operating system) and peripherals, providing greater processing power and a degree of graceful degradation if one CPU failed. In loosely coupled configurations each of a group of processors (single and / or tightly coupled) had its own memory and operating system but shared peripherals and the operating system component JES3 allowed managing the whole group from one console. This provided greater resilience and let operators decide which processor should run which jobs from a central job queue. MVS JES3 gave users the opportunity to network together two or more data processing systems via shared disks and Channel-to-Channedl Adapters (CTCA's). This capability eventually became available to JES2 users as Multi-Access SPOOL (MAS).MVS originally supported 24-bit addressing (i.e., up to 16 MB). As the underlying hardware progressed, it supported 31-bit (XA and ESA; up to 2048 MB) and now (as z/OS) 64-bit addressing. The most significant motives for the rapid upgrade to 31-bit addressing were the growth of large transaction-processing networks, mostly controlled by CICS, which ran in a single address space—and the DB2 relational database management system needed more than 8 MB of application address space to run efficiently. (Early versions were configured into two address spaces that communicated via the shared virtual area, but this imposed a significant overhead since all such communications had transmit via the operating system.)The main user interfaces to MVS are: Job Control Language (JCL), which was originally designed for batch processing but from the 1970s onwards was also used to start and allocate resources to long-running interactive jobs such CICS; and TSO (Time Sharing Option), the interactive time-sharing interface, which was mainly used to run development tools and a few end-user information systems. ISPF is a TSO application for users on 3270-family terminals (and later, on VM as well), which allows the user to accomplish the same tasks as TSO's command line but in a menu and form oriented manner, and with a full screen editor and file browser. TSO's basic interface is command line, although facilities were added later for form-driven interfaces).MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called ''software recovery''. IBM decided to do this after years of practical real-world experience with MVT in the business world. System failures were now having major impacts on customer businesses, and IBM decided to take a major design jump, to assume that despite the very best software development and testing techniques, that 'problems WILL occur.' This profound assumption was pivotal in adding great percentages of fault-tolerance code to the system and likely contributed to the system's success in tolerating software and hardware failures. Statistical information is hard to come by to prove the value of these design features (how can you measure 'prevented' or 'recovered' problems?), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.This design specified a hierarchy of error-handling programs, in system (kernel/'privileged') mode, called Functional Recovery Routines, and in user ('task' or 'problem program') mode, called "ESTAE" (Extended Specified Task Abnormal Exit routines) that were invoked in case the system detected an error (actually, hardware processor or storage error, or software error). Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).Thus, with each error the system captured diagnostic data, and attempted to perform a repair and keep the system up. The worst thing possible was to take down a user address space (a 'job') in the case of unrepaired errors. Though it was an initial design point, it was not until the most recent MVS version (z/OS), that recovery program was not only guaranteed its own recovery routine, but each recovery routine now has its own recovery routine. This recovery structure was embedded in the basic MVS control program, and programming facilities are available and used by application program developers and 3rd party developers.Practically, the MVS software recovery made problem debugging both easier and more difficult. Software recovery requires that programs leave 'tracks' of where they are and what they are doing, thus facilitating debugging—but the fact that processing progresses despite an error can overwrite the tracks. Early date capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.IBM included additional criteria for a major software problem that required IBM service. If a mainline component failed to initiate software recovery, that was considered a valid reportable failure. Also, if a recovery routine failed to collect significant diagnostic data such that the original problem was solvable by data collected by that recovery routine, IBM standards dictated that this fault was reportable and required repair. Thus, IBM standards, when rigorously applied, encouraged continuous improvement.IBM introduced an on-demand hypervisor, a major serviceability tool, called Dynamic Support System (DSS), in the first release of MVS. This facility could be invoked to initiate a session to create diagnostic procedures, or invoke already-stored procedures. The procedures 'trapped' special events, such as the loading of a program, device I/O, system procedure calls, and then triggered the activation of the previously defined procedures. These procedures, which could be invoked recursively, allowed for reading and writing of data, and alteration of instruction flow. Program Event Recording hardware was used. Due to the overhead of this tool, it was removed from customer-available MVS systems. Program-Event Recording (PER) exploitation was performed by the enhancement of the diagnostic "SLIP" command with the introduction of the PER support (SLIP/Per) in SU 64/65 (1978).Multiple copies of MVS (or other IBM operating systems) could share thesame machine if that machine was controlled by VM/370. In this case VM/370 was the real operating system, and regarded the "guest" operating systems as applications with unusually high privileges. As a result of later hardware enhancements one instance of an operating system (either MVS, or VM with guests, or other) could also occupy a Logical Partition (LPAR) instead of an entire physical system.Multiple MVS instances can be organized and collectively administered in a structure called a ''systems complex'' or ''sysplex'', introduced in September, 1990. Instances interoperate through a software component called a Cross-system Coupling Facility (XCF) and a hardware component called a ''Hardware Coupling Facility'' (CF or Integrated Coupling Facility, ICF, if co-located on the same mainframe hardware). Multiple sysplexes can be joined via standard network protocols such as IBM's proprietary Systems Network Architecture (SNA) or, more recently, via TCP/IP. The z/OS operating system (MVS' most recent descendant) also has native support to execute POSIX and Single UNIX Specification applications. The support began with MVS/SP V4R3, and IBM has obtained UNIX 95 certification for z/OS V1R2 and later.(【引用サイトリンク】title=IBM Corporation - UNIX 95 )The system is typically used in business and banking, and applications are often written in COBOL. COBOL programs were traditionally used with transaction processing systems like IMS and CICS. For a program running in CICS, special EXEC CICS statements are inserted in the COBOL source code. A preprocessor (translator) replaces those EXEC CICS statements with the appropriate COBOL code to call CICS before the program is compiled — not altogether unlike SQL used to call DB2. Applications can also be written in other languages such as C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX. Language support is packaged as a common component called "Language Environment" or "LE" to allow uniform debugging, tracing, profiling, and other language independent functions.MVS systems are traditionally accessed by 3270 terminals or by PCs running 3270 emulators. However, many mainframe applications these days have custom web or GUI interfaces. The z/OS operating system has built-in support for TCP/IP. System management, done in the past with a 3270 terminal, is now done through the Hardware Management Console (HMC) and, increasingly, Web interfaces. Operator consoles are provided through 2074 emulators, so you are unlikely to see any S/390 or zSeries processor with a real 3270 connected to it.The native character encoding scheme of MVS and its peripherals is EBCDIC, but the TR instruction made it easy to translate to other 7- and 8-bit codes. Over time IBM added hardware-accelerated services to perform translation to and between larger codes, hardware-specific service for Unicode transforms and software support of, e.g., ASCII, ISO/IEC 8859, UTF-8, UTF-16, and UTF-32. The software translation services take source and destination code pages as inputs.">ウィキペディア（Wikipedia）』
■regions for job steps as needed, provided enough ''contiguous'' physical memory was available. This was a significant advance over MFT's memory management, but had some weaknesses: if a job allocated memory dynamically (as most sort programs and database management systems do), the programmers had to estimate the job's maximum memory requirement and pre-define it for MVT. A job step that contained a mix of small and large programs wasted memory while the small programs ran. Most seriously, memory could become fragmented, i.e., the memory not used by current jobs could be divided into uselessly small chunks between the areas used by current jobs, and the only remedy was to wait some current jobs finished before starting any new ones.In the early 1970s IBM sought to mitigate these difficulties by introducing virtual memory (which IBM called "virtual storage"), which allowed programs to request address spaces larger than physical memory. The original implementations had a single virtual address space, shared by all jobs. OS/VS1 was OS/360 MFT within a single virtual address space; OS/VS2 SVS was OS/360 MVT within a single virtual address space. So OS/VS1 and SVS in principle had the same disadvantages as MFT and MVT, but the impacts were less severe because jobs could request much larger address spaces and the requests came out of a 16 MB pool even if physical storage was smaller.|}In the mid-1970s IBM introduced MVS, which not only supported virtual storage that was larger than the available real storage,Some processors could take more physical storage than the size of a single address space, but still much smaller than the aggregate size of a typical workload's virtual storage. as did SVS, but also allowed an indefinite number of applications to run in different address spaces. Two concurrent programs might try to access the same virtual memory address, but the virtual memory system redirected these requests to different areas of physical memory. Each of these address spaces consisted of three areas: an operating system (one instance shared by all jobs), an application area unique for each application, and a shared virtual area used for various purposes, including inter-job communication. IBM promised that application areas would always be at least 8 MB. This made MVS the perfect solution for business problems that resulted from the need to run more applications.MVS maximized processing potential by providing multiprogramming and multiprocessing capabilities. Like its MVT and OS/VS2 SVS predecessors, MVS supported multiprogramming; program instructions and associated data are scheduled by a control program and given processing cycles. Unlike a single-programming operating system, these systems maximize the use of the processing potential by dividing processing cycles among the instructions associated with several different concurrently running programs. This way, the control program does not have to wait for the I/O operation to complete before proceeding. By executing the instructions for multiple programs, the computer is able to switch back and forth between active and inactive programs.Early editions of MVS (mid-1970s) were among the first of the IBM OS series to support multiprocessor configurations, though the M65MP variant of OS/360 running on 360 Models 65 and 67 had provided limited multiprocessor support. The 360 Model 67 had also hosted the multiprocessor capable TSS/360, MTS and CP-67 operating systems. Because multiprocessing systems can execute instructions simultaneously, they offer greater processing power than single-processing system. As a result, MVS was able to address the business problems brought on by the need to process large amounts of data.Multiprocessing systems are either loosely coupled, which means that each computer has access to a common workload, or tightly coupled, which means that the computers share the same real storage and are controlled by a single copy of the operating system. MVS retained both the loosely coupled multiprocessing of Attached Support Processor (ASP)Via Job Entry Subsystem 3 (JES3) and the tightly coupled multiprocessing of OS/360 Model 65 Multiprocessing. In tightly coupled systems, two CPUs shared concurrent access to the same memory (and copy of the operating system) and peripherals, providing greater processing power and a degree of graceful degradation if one CPU failed. In loosely coupled configurations each of a group of processors (single and / or tightly coupled) had its own memory and operating system but shared peripherals and the operating system component JES3 allowed managing the whole group from one console. This provided greater resilience and let operators decide which processor should run which jobs from a central job queue. MVS JES3 gave users the opportunity to network together two or more data processing systems via shared disks and Channel-to-Channedl Adapters (CTCA's). This capability eventually became available to JES2 users as Multi-Access SPOOL (MAS).MVS originally supported 24-bit addressing (i.e., up to 16 MB). As the underlying hardware progressed, it supported 31-bit (XA and ESA; up to 2048 MB) and now (as z/OS) 64-bit addressing. The most significant motives for the rapid upgrade to 31-bit addressing were the growth of large transaction-processing networks, mostly controlled by CICS, which ran in a single address space—and the DB2 relational database management system needed more than 8 MB of application address space to run efficiently. (Early versions were configured into two address spaces that communicated via the shared virtual area, but this imposed a significant overhead since all such communications had transmit via the operating system.)The main user interfaces to MVS are: Job Control Language (JCL), which was originally designed for batch processing but from the 1970s onwards was also used to start and allocate resources to long-running interactive jobs such CICS; and TSO (Time Sharing Option), the interactive time-sharing interface, which was mainly used to run development tools and a few end-user information systems. ISPF is a TSO application for users on 3270-family terminals (and later, on VM as well), which allows the user to accomplish the same tasks as TSO's command line but in a menu and form oriented manner, and with a full screen editor and file browser. TSO's basic interface is command line, although facilities were added later for form-driven interfaces).MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called ''software recovery''. IBM decided to do this after years of practical real-world experience with MVT in the business world. System failures were now having major impacts on customer businesses, and IBM decided to take a major design jump, to assume that despite the very best software development and testing techniques, that 'problems WILL occur.' This profound assumption was pivotal in adding great percentages of fault-tolerance code to the system and likely contributed to the system's success in tolerating software and hardware failures. Statistical information is hard to come by to prove the value of these design features (how can you measure 'prevented' or 'recovered' problems?), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.This design specified a hierarchy of error-handling programs, in system (kernel/'privileged') mode, called Functional Recovery Routines, and in user ('task' or 'problem program') mode, called "ESTAE" (Extended Specified Task Abnormal Exit routines) that were invoked in case the system detected an error (actually, hardware processor or storage error, or software error). Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).Thus, with each error the system captured diagnostic data, and attempted to perform a repair and keep the system up. The worst thing possible was to take down a user address space (a 'job') in the case of unrepaired errors. Though it was an initial design point, it was not until the most recent MVS version (z/OS), that recovery program was not only guaranteed its own recovery routine, but each recovery routine now has its own recovery routine. This recovery structure was embedded in the basic MVS control program, and programming facilities are available and used by application program developers and 3rd party developers.Practically, the MVS software recovery made problem debugging both easier and more difficult. Software recovery requires that programs leave 'tracks' of where they are and what they are doing, thus facilitating debugging—but the fact that processing progresses despite an error can overwrite the tracks. Early date capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.IBM included additional criteria for a major software problem that required IBM service. If a mainline component failed to initiate software recovery, that was considered a valid reportable failure. Also, if a recovery routine failed to collect significant diagnostic data such that the original problem was solvable by data collected by that recovery routine, IBM standards dictated that this fault was reportable and required repair. Thus, IBM standards, when rigorously applied, encouraged continuous improvement.IBM introduced an on-demand hypervisor, a major serviceability tool, called Dynamic Support System (DSS), in the first release of MVS. This facility could be invoked to initiate a session to create diagnostic procedures, or invoke already-stored procedures. The procedures 'trapped' special events, such as the loading of a program, device I/O, system procedure calls, and then triggered the activation of the previously defined procedures. These procedures, which could be invoked recursively, allowed for reading and writing of data, and alteration of instruction flow. Program Event Recording hardware was used. Due to the overhead of this tool, it was removed from customer-available MVS systems. Program-Event Recording (PER) exploitation was performed by the enhancement of the diagnostic "SLIP" command with the introduction of the PER support (SLIP/Per) in SU 64/65 (1978).Multiple copies of MVS (or other IBM operating systems) could share thesame machine if that machine was controlled by VM/370. In this case VM/370 was the real operating system, and regarded the "guest" operating systems as applications with unusually high privileges. As a result of later hardware enhancements one instance of an operating system (either MVS, or VM with guests, or other) could also occupy a Logical Partition (LPAR) instead of an entire physical system.Multiple MVS instances can be organized and collectively administered in a structure called a ''systems complex'' or ''sysplex'', introduced in September, 1990. Instances interoperate through a software component called a Cross-system Coupling Facility (XCF) and a hardware component called a ''Hardware Coupling Facility'' (CF or Integrated Coupling Facility, ICF, if co-located on the same mainframe hardware). Multiple sysplexes can be joined via standard network protocols such as IBM's proprietary Systems Network Architecture (SNA) or, more recently, via TCP/IP. The z/OS operating system (MVS' most recent descendant) also has native support to execute POSIX and Single UNIX Specification applications. The support began with MVS/SP V4R3, and IBM has obtained UNIX 95 certification for z/OS V1R2 and later.(【引用サイトリンク】title=IBM Corporation - UNIX 95 )The system is typically used in business and banking, and applications are often written in COBOL. COBOL programs were traditionally used with transaction processing systems like IMS and CICS. For a program running in CICS, special EXEC CICS statements are inserted in the COBOL source code. A preprocessor (translator) replaces those EXEC CICS statements with the appropriate COBOL code to call CICS before the program is compiled — not altogether unlike SQL used to call DB2. Applications can also be written in other languages such as C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX. Language support is packaged as a common component called "Language Environment" or "LE" to allow uniform debugging, tracing, profiling, and other language independent functions.MVS systems are traditionally accessed by 3270 terminals or by PCs running 3270 emulators. However, many mainframe applications these days have custom web or GUI interfaces. The z/OS operating system has built-in support for TCP/IP. System management, done in the past with a 3270 terminal, is now done through the Hardware Management Console (HMC) and, increasingly, Web interfaces. Operator consoles are provided through 2074 emulators, so you are unlikely to see any S/390 or zSeries processor with a real 3270 connected to it.The native character encoding scheme of MVS and its peripherals is EBCDIC, but the TR instruction made it easy to translate to other 7- and 8-bit codes. Over time IBM added hardware-accelerated services to perform translation to and between larger codes, hardware-specific service for Unicode transforms and software support of, e.g., ASCII, ISO/IEC 8859, UTF-8, UTF-16, and UTF-32. The software translation services take source and destination code pages as inputs.">ウィキペディアで「Multiple Virtual Storage, more commonly called MVS, was the most commonly used operating system on the System/370 and System/390 IBM mainframe computers. It was developed by IBM, but is unrelated to IBM's other mainframe operating systems, e.g., VSE, VM, TPF.First released in 1974, MVS was extended by program products with new names multiple times, first to MVS/SE (MVS/System Extension), next to MVS/SP (MVS/System Product) Version 1, next to MVS/XA (MVS/eXtended Architecture), next to MVS/ESA (MVS/Enterprise Systems Architecture), next to OS/390 and finally to z/OS (when 64-bit support was added with the zSeries models). IBM added Unix support (originally called OPEN EDITION) in MVS/SP V4.3 and has obtained POSIX and Unix certifications at several different levels. The MVS core remains fundamentally the same operating system. By design, programs written for MVS run on z/OS without modification.At first IBM described MVS as simply a new release of OS/VS2, but it was, in fact a major rewrite. OS/VS2 release 1 was an upgrade of OS/360 MVT that retained most of the original code and, like MVT, was mainly written in assembly language. The MVS core was almost entirely written in Assembler XF, although a few modules were written in PL/S, but not the performance-sensitive ones, in particular not the Input/Output Supervisor (IOS). IBM's use of "OS/VS2" emphasized upwards compatibility: application programs that ran under MVT did not even need recompiling to run under MVS. The same Job Control Language files could be used unchanged; utilities and other non-core facilities like TSO ran unchanged. IBM and users almost unanimously called the new system MVS from the start, and IBM continued to use the term ''MVS'' in the naming of later ''major'' versions such as MVS/XA.==Evolution of MVS==OS/360 MFT (Multitasking with a Fixed number of Tasks) provided multitasking: several memory partitions, each of a fixed size, were set up when the operating system was installed and when the operator redefined them. For example, there could be a small partition, two medium partitions, and a large partition. If there were two large programs ready to run, one would have to wait until the other finished and vacated the large partition.OS/360 MVT (Multitasking with a Variable number of Tasks) was an enhancement that further refined memory use. Instead of using fixed-size memory partitions, MVT allocated memory to regions for job steps as needed, provided enough ''contiguous'' physical memory was available. This was a significant advance over MFT's memory management, but had some weaknesses: if a job allocated memory dynamically (as most sort programs and database management systems do), the programmers had to estimate the job's maximum memory requirement and pre-define it for MVT. A job step that contained a mix of small and large programs wasted memory while the small programs ran. Most seriously, memory could become fragmented, i.e., the memory not used by current jobs could be divided into uselessly small chunks between the areas used by current jobs, and the only remedy was to wait some current jobs finished before starting any new ones.In the early 1970s IBM sought to mitigate these difficulties by introducing virtual memory (which IBM called "virtual storage"), which allowed programs to request address spaces larger than physical memory. The original implementations had a single virtual address space, shared by all jobs. OS/VS1 was OS/360 MFT within a single virtual address space; OS/VS2 SVS was OS/360 MVT within a single virtual address space. So OS/VS1 and SVS in principle had the same disadvantages as MFT and MVT, but the impacts were less severe because jobs could request much larger address spaces and the requests came out of a 16 MB pool even if physical storage was smaller.|}In the mid-1970s IBM introduced MVS, which not only supported virtual storage that was larger than the available real storage,Some processors could take more physical storage than the size of a single address space, but still much smaller than the aggregate size of a typical workload's virtual storage. as did SVS, but also allowed an indefinite number of applications to run in different address spaces. Two concurrent programs might try to access the same virtual memory address, but the virtual memory system redirected these requests to different areas of physical memory. Each of these address spaces consisted of three areas: an operating system (one instance shared by all jobs), an application area unique for each application, and a shared virtual area used for various purposes, including inter-job communication. IBM promised that application areas would always be at least 8 MB. This made MVS the perfect solution for business problems that resulted from the need to run more applications.MVS maximized processing potential by providing multiprogramming and multiprocessing capabilities. Like its MVT and OS/VS2 SVS predecessors, MVS supported multiprogramming; program instructions and associated data are scheduled by a control program and given processing cycles. Unlike a single-programming operating system, these systems maximize the use of the processing potential by dividing processing cycles among the instructions associated with several different concurrently running programs. This way, the control program does not have to wait for the I/O operation to complete before proceeding. By executing the instructions for multiple programs, the computer is able to switch back and forth between active and inactive programs.Early editions of MVS (mid-1970s) were among the first of the IBM OS series to support multiprocessor configurations, though the M65MP variant of OS/360 running on 360 Models 65 and 67 had provided limited multiprocessor support. The 360 Model 67 had also hosted the multiprocessor capable TSS/360, MTS and CP-67 operating systems. Because multiprocessing systems can execute instructions simultaneously, they offer greater processing power than single-processing system. As a result, MVS was able to address the business problems brought on by the need to process large amounts of data.Multiprocessing systems are either loosely coupled, which means that each computer has access to a common workload, or tightly coupled, which means that the computers share the same real storage and are controlled by a single copy of the operating system. MVS retained both the loosely coupled multiprocessing of Attached Support Processor (ASP)Via Job Entry Subsystem 3 (JES3) and the tightly coupled multiprocessing of OS/360 Model 65 Multiprocessing. In tightly coupled systems, two CPUs shared concurrent access to the same memory (and copy of the operating system) and peripherals, providing greater processing power and a degree of graceful degradation if one CPU failed. In loosely coupled configurations each of a group of processors (single and / or tightly coupled) had its own memory and operating system but shared peripherals and the operating system component JES3 allowed managing the whole group from one console. This provided greater resilience and let operators decide which processor should run which jobs from a central job queue. MVS JES3 gave users the opportunity to network together two or more data processing systems via shared disks and Channel-to-Channedl Adapters (CTCA's). This capability eventually became available to JES2 users as Multi-Access SPOOL (MAS).MVS originally supported 24-bit addressing (i.e., up to 16 MB). As the underlying hardware progressed, it supported 31-bit (XA and ESA; up to 2048 MB) and now (as z/OS) 64-bit addressing. The most significant motives for the rapid upgrade to 31-bit addressing were the growth of large transaction-processing networks, mostly controlled by CICS, which ran in a single address space—and the DB2 relational database management system needed more than 8 MB of application address space to run efficiently. (Early versions were configured into two address spaces that communicated via the shared virtual area, but this imposed a significant overhead since all such communications had transmit via the operating system.)The main user interfaces to MVS are: Job Control Language (JCL), which was originally designed for batch processing but from the 1970s onwards was also used to start and allocate resources to long-running interactive jobs such CICS; and TSO (Time Sharing Option), the interactive time-sharing interface, which was mainly used to run development tools and a few end-user information systems. ISPF is a TSO application for users on 3270-family terminals (and later, on VM as well), which allows the user to accomplish the same tasks as TSO's command line but in a menu and form oriented manner, and with a full screen editor and file browser. TSO's basic interface is command line, although facilities were added later for form-driven interfaces).MVS took a major step forward in fault-tolerance, built on the earlier STAE facility, that IBM called ''software recovery''. IBM decided to do this after years of practical real-world experience with MVT in the business world. System failures were now having major impacts on customer businesses, and IBM decided to take a major design jump, to assume that despite the very best software development and testing techniques, that 'problems WILL occur.' This profound assumption was pivotal in adding great percentages of fault-tolerance code to the system and likely contributed to the system's success in tolerating software and hardware failures. Statistical information is hard to come by to prove the value of these design features (how can you measure 'prevented' or 'recovered' problems?), but IBM has, in many dimensions, enhanced these fault-tolerant software recovery and rapid problem resolution features, over time.This design specified a hierarchy of error-handling programs, in system (kernel/'privileged') mode, called Functional Recovery Routines, and in user ('task' or 'problem program') mode, called "ESTAE" (Extended Specified Task Abnormal Exit routines) that were invoked in case the system detected an error (actually, hardware processor or storage error, or software error). Each recovery routine made the 'mainline' function reinvokable, captured error diagnostic data sufficient to debug the causing problem, and either 'retried' (reinvoke the mainline) or 'percolated' (escalated error processing to the next recovery routine in the hierarchy).Thus, with each error the system captured diagnostic data, and attempted to perform a repair and keep the system up. The worst thing possible was to take down a user address space (a 'job') in the case of unrepaired errors. Though it was an initial design point, it was not until the most recent MVS version (z/OS), that recovery program was not only guaranteed its own recovery routine, but each recovery routine now has its own recovery routine. This recovery structure was embedded in the basic MVS control program, and programming facilities are available and used by application program developers and 3rd party developers.Practically, the MVS software recovery made problem debugging both easier and more difficult. Software recovery requires that programs leave 'tracks' of where they are and what they are doing, thus facilitating debugging—but the fact that processing progresses despite an error can overwrite the tracks. Early date capture at the time of the error maximizes debugging, and facilities exist for the recovery routines (task and system mode, both) to do this.IBM included additional criteria for a major software problem that required IBM service. If a mainline component failed to initiate software recovery, that was considered a valid reportable failure. Also, if a recovery routine failed to collect significant diagnostic data such that the original problem was solvable by data collected by that recovery routine, IBM standards dictated that this fault was reportable and required repair. Thus, IBM standards, when rigorously applied, encouraged continuous improvement.IBM introduced an on-demand hypervisor, a major serviceability tool, called Dynamic Support System (DSS), in the first release of MVS. This facility could be invoked to initiate a session to create diagnostic procedures, or invoke already-stored procedures. The procedures 'trapped' special events, such as the loading of a program, device I/O, system procedure calls, and then triggered the activation of the previously defined procedures. These procedures, which could be invoked recursively, allowed for reading and writing of data, and alteration of instruction flow. Program Event Recording hardware was used. Due to the overhead of this tool, it was removed from customer-available MVS systems. Program-Event Recording (PER) exploitation was performed by the enhancement of the diagnostic "SLIP" command with the introduction of the PER support (SLIP/Per) in SU 64/65 (1978).Multiple copies of MVS (or other IBM operating systems) could share thesame machine if that machine was controlled by VM/370. In this case VM/370 was the real operating system, and regarded the "guest" operating systems as applications with unusually high privileges. As a result of later hardware enhancements one instance of an operating system (either MVS, or VM with guests, or other) could also occupy a Logical Partition (LPAR) instead of an entire physical system.Multiple MVS instances can be organized and collectively administered in a structure called a ''systems complex'' or ''sysplex'', introduced in September, 1990. Instances interoperate through a software component called a Cross-system Coupling Facility (XCF) and a hardware component called a ''Hardware Coupling Facility'' (CF or Integrated Coupling Facility, ICF, if co-located on the same mainframe hardware). Multiple sysplexes can be joined via standard network protocols such as IBM's proprietary Systems Network Architecture (SNA) or, more recently, via TCP/IP. The z/OS operating system (MVS' most recent descendant) also has native support to execute POSIX and Single UNIX Specification applications. The support began with MVS/SP V4R3, and IBM has obtained UNIX 95 certification for z/OS V1R2 and later.(【引用サイトリンク】title=IBM Corporation - UNIX 95 )The system is typically used in business and banking, and applications are often written in COBOL. COBOL programs were traditionally used with transaction processing systems like IMS and CICS. For a program running in CICS, special EXEC CICS statements are inserted in the COBOL source code. A preprocessor (translator) replaces those EXEC CICS statements with the appropriate COBOL code to call CICS before the program is compiled — not altogether unlike SQL used to call DB2. Applications can also be written in other languages such as C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX. Language support is packaged as a common component called "Language Environment" or "LE" to allow uniform debugging, tracing, profiling, and other language independent functions.MVS systems are traditionally accessed by 3270 terminals or by PCs running 3270 emulators. However, many mainframe applications these days have custom web or GUI interfaces. The z/OS operating system has built-in support for TCP/IP. System management, done in the past with a 3270 terminal, is now done through the Hardware Management Console (HMC) and, increasingly, Web interfaces. Operator consoles are provided through 2074 emulators, so you are unlikely to see any S/390 or zSeries processor with a real 3270 connected to it.The native character encoding scheme of MVS and its peripherals is EBCDIC, but the TR instruction made it easy to translate to other 7- and 8-bit codes. Over time IBM added hardware-accelerated services to perform translation to and between larger codes, hardware-specific service for Unicode transforms and software support of, e.g., ASCII, ISO/IEC 8859, UTF-8, UTF-16, and UTF-32. The software translation services take source and destination code pages as inputs.」の詳細全文を読む
スポンサード リンク
| 翻訳と辞書 : 翻訳のためのインターネットリソース |
Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.
|
|