Computer multiprogramming is the allocation of a computer system and its resources to more than one concurrent application, job or user ("program" in this nomenclature).
Initially, this technology was sought in order to optimize use of a computer system, since time and processing resources were often wasted when a single job waited for human interaction was developed as a feature of operating systems in the late 1950s and came into common use in mainframe computing in the mid- to late 1960s. This followed the development of hardware systems that possessed the requisite circuit logic and instruction sets to facilitate the transfer of control between the operating system and one or more independent applications, users or job streams.
The use of multiprogramming was enhanced by the arrival of virtual memory and virtual machine technology, which enabled individual programs to make use of memory and operating system resources as if other concurrently running programs were, for all practical purposes, non-existent and invisible to them.
Multiprogramming should be differentiated from multi-tasking since not all multiprogramming entails—or has the capability for-- "true" multi-tasking. This is the case even though the use of multi-tasking generally implies the use of some multiprogramming methods.
In this context, the root word "program" does not necessarily refer to a compiled application, rather, any set of commands submitted for execution by a user or operator. Such "program" could include a script or job control stream and any included calls to macro-instructions, system utilities or application program modules. An entire, interactive, logged-in user session can be thought of as a "program" in this sense.
A program generally comprises numerous tasks, a task being a relatively small group of processor instructions which together achieve a definable logical step in the completion of a job or the execution of a continuous-running application program. A task frequently ends with some request requiring the moving of data, a convenient opportunity to allow another program to have system resources, particularly CPU time.
In multiprogramming, concurrent running (sharing of the processor) is achieved when the operating system identifies opportunities to interrupt the handling of one program between tasks (e.g., when it is waiting for input/output) and to transfer process control to another program (application, job or user). To a great extent, the ability of a system to share its resources equitably—or according to certain priorities—is dependent upon the design of the programs being handled and how frequently they may be interrupted.
Multi-tasking eliminates that dependency and expands upon multiprogramming by enabling the operating system supervisor to interrupt programs in the middle of tasks and to transfer processor control so rapidly that each program is now assured a portion of each processing second, making the interruptions imperceptible to most human-interactive applications.
To allow the parts of a program in virtual storage to move between real and auxiliary storage, MVS breaks real storage, virtual storage, and auxiliary storage into blocks. The terminology the system uses Is as follows:
A page, a frame and a slot are all of the same size; each consists of 4096 bytes (4KB). An active virtual storage page resides in a real storage frame; a virtual storage page that becomes inactive resides in an auxiliary storage slot.
Moving pages between real storage frames and auxiliary storage slots is called paging. The following figure shows how paging is done for a program running in MVS.
At point 1, parts A, B and C of a three-page program is in virtual storage. Page A is active and is executing in real storage frame, while pages B and C are inactive because they have been moved to slots. At point 2, page B is required; the system brings page B from the auxiliary storage and puts it in an available real storage frame. At point 3, page C is required; the system brings in C from auxiliary storage and puts in an available real storage frame. If page had not been used recently and if the system needed its frame in real storage, page B would have been moved to an auxiliary storage slot, as shown at point 4.
Thus, the entire program reside in virtual storage and the system copies pages of the program between real storage frames and auxiliary storage slots to ensure that the pages that are currently active are in real storage as they are required. Note that neither the frames nor the slots allocated to a program need be contiguous; thus a page can occupy several different frames and several different slots during the execution of a program. So if page A in the above example were to become active again MVS would move it to any available frame.
As we have already seen, the total amount of virtual storage that can be used under MVS is almost unlimited. As a result, the amount of real storage present on a particular machine is nearly always less than the amount of virtual storage being used. To provide for the larger virtual storage, MVS treats DASD as an extension of real storage.
MVS divides virtual storage into 4K sections called pages. Data is transferred between real and DASD storage one page at a time. As a result, real storage is divided into 4K sections called page frames, each of which can hold one page of virtual storage. Similarly, the DASD area used for virtual storage, called a page data set, is divided into 4K page slots, each of which holds one page of virtual storage.
Virtual Storage Page Movement
When a program refers to a storage location that is not in real storage, a page fault occurs. When that happens, MVS locates the page that contains the needed data on DASD and transfers it into real storage. That operation is called a page-in. In some cases, the new page can overlay data in a real storage page frame. In other cases, data in a page frame has to be moved to a page data set to make room for the new page. That is called a page-out. Either way, the process of bringing a new page into real storage is called paging.
Page frames in real storage contain pages from more than one address space. That is what the various shades and patterns in real and virtual storage represent. MVS keeps track of what pages are in what page frames by maintaining tables that reflect the current status of real storage and of each address space. The real storage frames that contain those tables cannot be paged out; they must always remain in real storage as long as their associated address spaces are active.
Most new System/370 processors include a special type of memory known as expanded storage. Expanded storage improves the efficiency of virtual storage operations by acting as a large buffer between real storage and the page data sets. Simply put, when a virtual storage page must be paged out, the processor moves the page's contents to expanded storage. This transfer occurs at CPU speeds rather than at DASD speeds, so the operation is almost instantaneous. Pages are written to the actual page data set only when expanded storage becomes full. The amount of expanded storage on a processor varies depending on the processor model. The largest ES/9000 processors can be configured with as much as 8GB of expanded storage.
Most installations do not need that much expanded storage for normal paging operations, but as you will see in a moment, large amounts of expanded storage can provide additional benefits when MVS/ESA is used.
In paging auxiliary storage slots are moved to real storage frame and vice-versa as and when required. But in swapping address spaces are moved from real storage to auxiliary storage and vice-versa. Swapping is the process of transferring all of the recently valid private pages of an address space between real storage and auxiliary storage. This has the effect of moving an entire address space into or out of real storage. It is one of several methods MVS employs to balance the system workload as well as to ensure that an adequate supply of available real storage frames is maintained. Address spaces that are swapped-in are active, having pages in real storage frames and pages in auxiliary storage slots. Address spaces that are swapped-out are inactive; the address spaces reside on auxiliary storage and cannot execute until it is swapped-in. Swapping is performed in response to the recommendations from the System Resource Manager (SRM).
Concept of Swapping under MVS
Depending on the amount of real storage a system has and the types of jobs it is processing, MVS can efficiently multiprogram only a certain number of jobs at once. So, using a process called swapping, MVS periodically transfers entire address spaces in and out of virtual storage so they are temporarily unavailable for processing. When an address space is swapped out, its critical pages—the ones that contain the tables that keep track of the location of each virtual storage page for the address space—are written to a special data set called a swap data set. Later, when the system can accommodate the job again, the address space is swapped in so it can be processed again.
The above figure should help you understand swapping. Here, four address spaces are currently swapped in; the shading indicates the address space that is currently in control. Four additional address spaces are swapped out. They cannot compete for virtual storage or the CPU until they are swapped in, You can think of swapping as the same thing as paging, only at a higher level. Rather than move small 4K pieces of virtual storage in and out of real storage, swapping effectively moves entire address spaces in and out of virtual storage. Because paging occurs only for address spaces that are currently in virtual storage, paging does not occur for address spaces that are swapped out.
A program within an address space may run in one of two modes: real mode and virtual mode. These modes simply indicate whether or not a program is subject to the paging and swapping processes we have just seen. Paging and swapping operate only for programs that run in virtual mode. Programs that operate in real mode are not paged or swapped.
Why are some programs allowed to operate in real mode? Consider how the operating system must operate: The parts of the operating system that are responsible for managing virtual storage cannot themselves be subject to the paging process. In other words, those parts must be resident in real storage all the time. Those parts of the operating system must run in real mode, so they are non-pageable and non
IBM Mainframe Related Interview Questions
|IBM Lotus Notes Interview Questions||IBM-CICS Interview Questions|
|COBOL Interview Questions||Linux Interview Questions|
|IBM-JCL Interview Questions||IBM Mainframe Interview Questions|
|IBM AIX Interview Questions||IBM WAS Administration Interview Questions|
|IBM Lotus Domino Interview Questions||IBM Integration Bus Interview Questions|
|Mainframe DB2 Interview Questions||Unix Production Support Interview Questions|
Ibm Mainframe Tutorial
Introduction To Software Development
Introduction To Ibm Mainframes
Tso And Ispf
Jes2, ]es3 And Sms
Introduction To Job Control Language (jcl)
The Job Statement
The Exec Statement
The Job And Exec Statements
The Dd Statement
Procedures And Symbolic Parameters
Generation Data Groups (gdg), Compile/link-edit And Run Jcls
Access Method Services (ams)
Additional Vsam Commands
Introduction To Rexx
Overview Of Rexx
Introduction To Cics
Exception Handling In Cics
Developing A Cics Application
Cics Programming Techniques
Basic Mapping Support (bms)
Transient Data Control
Temporary Storage Control
Interval And Task Control
Cics Application Design
Recovery And Restart
System Security And Intersystem Communication
Cics Debugging Facilities And Techniques
Bms Map Definition Macros And Copylib Members
Cics Response And Abend Codes
Data, Information And Information Processing
Introduction To Database Management Systems
Introduction To Relational Database Management Systems
Database Architecture And Data Modeling
Overview Of Db2
Structured Query Language (sql)
Data Security And Access
Db2 Application Development
Qmf And Db2i
Db2 Performance Monitoring, Utilities And Recovery/restart
Overview Of Information Management System (ims)
Introduction To Vs Cobol Ii
Overview Of Application Development In Vs Cobol Ii
Overview Of The Cobol Program
Sorting And Merging Files
Coding Cobol Programs That Run Under Cics. Ims, Db2 And Ispf
Compiling The Program
Link-editing The Program
Executing The Program
Improving Program Performance
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.