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:
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.
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.