MVS/XA has become obsolete for those using super sized files, so that the concept of address space became too small of an area to maintain processing efficiency. To overcome this deficiency, IBM developed a new operating system called MVS/ESA. ESA, unlike the XA machine, allow the application to use multiple 2GB-address spaces. The MVS/ESA operating system in addition to creating these huge address spaces for processing efficiency also redefines some of the larger application into a number of functional areas. This concept is important when processing CICS applications because the data utilized by each real application is segregated into a particular area, thus preventing an application from wiping out a subsequent file—one that belongs to another application.

In terms of operating efficiency it means that data spaces are economical for those application programs that continually process the same data. Thus, data can be stored in primary rather than auxiliary storage, where the slow I/O operations are not required. In addition to the 2GB of super storage available for holding the instructions and data of a particular job in an address space, each job can also have access to many data spaces. Thus, you can think of data spaces as expanding virtual storage horizontally rather than vertically, as does MVS/XA. In a typical MVS/ESA environment, three kinds of spaces are used by the operating system:

  • Address Spaces, referred to as application space, in which only programs can execute and which contains no data.
  • Data Spaces, meaning that they contain exclusive data for an application. Because a program cannot execute in data space, it must be copied into an application space prior to execution. Data spaces are allocated purely to data, so the 2GB of storage does not contain any part of the MVS operating system. Data spaces are addressable by the byte and they are virtual-storage-resident during the execution of the job or task.
  • Hiperspaces, which enables the storage of temporary data addressable in 4KB rather than by individual bytes. The primary function of hiperspaces is to store temporary data sets created through an application program. When such data is required, it is physically moved from hiperspace into application space 4KB at a time.

Because data spaces isolate data from programs, data spaces prevent unintentional changes to the data. At the same time data spaces can permit the sharing of data among selected users.

Along with this technology, IBM developed SMS or Storage Management Subsystem. SMS continually migrates data residing on DASD to tape and back to DASD based on priority and usage. SMS allow an installation to set classes on disk data sets with identical attributes. Programmers can create their file in reference to such a class. One of the functions of SMS is to avoid the fragmentation on disk space by setting an efficient balance through use. In conjunction with this you do not have to define a block size to SMS any longer—unless you have a specific reason for doing so, SMS will do it for you. And the advantage of letting SMS do the calculation is that it will supply you with the most efficient block-size ratio attained through a set of sophisticated algorithms. This kind of device independence means that the user does not have to aware of how a particular device is being used by the operating system.

More on MVS operating system...

Computer systems and computer resources can be classified into three areas: processor, real storage and I/O devices. The ultimate goal of the MVS operating system, of course, is to keep all those resources as busy as possible, to use a cliche, for the maximization of performance'. Unfortunately, there is an inherent conflict in this goal. To make sure that all computer resources are kept busy might mean a slow down in one area—thus not using the system to its fullest potential at some point in time.

One of the tools MVS uses in executing a job is a subsystem within the main operating system called Job Entry Subsystem (JES). To be more specific, as an MVS user you might relay on one of the Job Entry Subsystems referred to as JES2 or JES3. Essentially JES accepts a job and sets it up for execution while providing temporary storage facilities on disk until the operating system is ready to process it. The relationship between MVS and JES is simply that MVS executes a particular job, while JES is responsible for the more 'mundane' details of that job, such as printing an output, purging a job once MVS is through processing it, and so on. To identify a job to JES and consequently to MVS, you need to relay on JCL statements.

JES is actually a very intelligent piece of software. Users can classify jobs, so JES can select them for execution to maximize the efficiency of the operating system in handling expensive resources. For example, JES has the intelligence to select and submit jobs with different requirements so they will not compete with one another for resources, such as those requiring tape volumes or special DASD.

To continually maintain efficiency, the MVS operating system divides each job into separate executable units referred to as tasks. MVS selects and sequence work for processing by address space and, within each address space, by task based on the highest priority. While taking action to keep resources as busy as possible, MVS also decides how to process its workload. MVS bases its decisions on a priority scheme that is specified by particular installation standards. Normally, a computer installation categorizes jobs into certain groups and each group is denoted by the amount of service or privileges it receives. Thus, as MVS executes the job, it repeatedly checks and compares the amount of service each job is getting, as opposed to what is specified for it. It then compensates for either too much or too little of such service.

When MVS processes a workload, it uses a technique that enables the operating system to switch control from one task to another, so that while one task waits another can execute. In the MVS environment, this is done through interrupts. An interrupt is simply an event that changes the specific order in which the CPU executes instructions. Actually, interrupts can be caused by internal or external events. An application program can trigger an internal event and external event can be invoked by a situation unrelated to the currently executing task.

Interrupts are initiated by a system (as opposed to an application) program called an interrupt handler. The interrupt handler saves viable information about the application program being interrupted. For example, when an I/O operation is completed, it cause and I/O interrupt. The interrupt handler at this time receives control, saves the status of the interrupted unit of work, and then passes control to handle a function with a higher priority.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics