Extensive List of Standard Products
SIGMA 9 STRENGTHS - XOS Memory Management:
•
UTS VS TSO
UTS provides all the following unique features:
Shared Processors: OS MVT/TSO provides no capability along this line. TSO functions much like BTM - in a dedicated area of core. Only one user is there at a time. Of course, more than one area can be devoted to TSO, but no processors are shared.
Mapped Memory: There is no capability under OS MVT/TSO to fragment mem-ory. All programs must reside in contiguous space; thus, there is no way to selectively remove a program from core and then return it to any alternate lo-cation!
Performance Management: IBM's philosophy has always been that they wi
II
not provide dynamic computer measurement features. This is considered a cus-tomer function and to be arrived at as he sees fit. This outstanding feature of UTS is an industry leading feature.SIGMA 9 STRENGTHS - XOS Memory Management:
Monitor - OS MVT devotes a fixed area to transient monitor routines. Alter-nately, an installation can dedicate an additional area for resident monitor routine. Other routines, such as Open/Close, which normally would reside in the user areas, can be selected for residency in the linkpack area - a dedicated area in upper core. This is contrasted to the mapping of the monitor under XOS.
First of all, it must be remembered that the XOS logical I/O routines are a part of the monitor and thus are not required in each user area as they are under OS MVT (except for an installation selection for residency - generally, the most used routines are made resident, but the larger ones are not). Trans-ient monitor routines are provided mapped core storage on an as-needed basis under XOS. This means that the core space for them is not completely taken away from the user except on an as-required basis. They occupy core space on a dynamic basis and in areas currently not in use by the user programs.
These routines become resident because of usage and not because of overt dedication. This results in a dynamic allocation of monitor used space and, as such, optimizes core usage. Contrast this to the OS MVT operating char-acteristic that either the installation management must select the dedicated monitor area, or the operator must look ahead for each run - ususlly two or more hours - and halt the system, re-boot the monitor to place speci'fic routines in resident areas and then continue operation. XOS takes 64KB (16KW) for dedicated space versus at least lOOKB (25KW) for OS MVT.
User Area - OS MVT requires a region (contiguous) of space in core for each user. This size is specified in the job card and reserves that much core for the duration of a job. Consider that a particular job is compile, load and go. The region size is selected to be large enough for the compiler and a corresponding loader is selected. The execution phase may only occupy 1/4 or 1/3 of the region and may well take more time for execution. Thus, during execution, 2/3 to 3/4 of the region lays fallow {un-used}. Suppose that 3/4 of the jobs do this and execution time equals compile and load time. This means that 1/2 of core goes completely unused for 1/2 plus the time!
XOS does not let this situation occur. Each step of a job uses only what core it needs - specifically the execution step discussed above would not reserve the whole region; thus, other jobs/job steps have access to the unused core space. Next, OS MVT dynamically loads into user space any of the logical access methods (ISAM, etc.). These routines are large and oftentimes repe-titious within the user area. At a given time, there may be many copies of identical routines occupying space.
XOS does not let this happen because they are built into the monitor. Similar routi nes are either encased in the mon i tor for use by a II programs or one copy occupies space and all users can use that routine. A job in XOS can also dy-namically extend its size without being aborted. With sufficient priority, OS MVT allows a program to rollout another program (or region). The rolled out program must then be returned to the i denti cal core space that it occupied before being rolled out. XOS never over allocates. Should a program request core above the limit specified, and core not be available, the program waits unti I it is avai lable.
Scheduling Techniques - OS MVT takes the top job off the priority list and accumu lates core for it. After the job gets core, it then sets about requesti ng files and/or devices - it must accumulate these until its needs are satisfied (no other job can get started during the process of accumulation). Once it does get all necessary resources, it hogs the system if it has highest priority. In other words, it takes all CPU time it needs - if it is compute bound, it gets all the time. Contrast this to the variety of control that XOS offers. If you wish to run with a scheduling algorithm as just discussed, you can with a re-duced efficiency of system utilization. XOS provides other scheduling methods under system generation and/or operator control. For example, in the case above, if the system determined that another job, lower priority, could be com-pleted before the necessary resources were re leased, the other job wou Id be started and be completed in time to prevent holding up the higher priority job.
Many other scheduling features such as time-slicing are available to be selected for a particular installation.
COMPANY PRIVATE
•
OTHER XOS STRENGTHSUtility Routines: XOS supports these within the resident monitor structure (parallel jobs). OS MVT places these in the job stream to occupy user core space.
Symbiont Functions: XOS has these built into the monitor. OS MVT has reader/interpretors (up to 3) that may be resident or transient (between jobs).
During residency (and at least one is usually resident), they occupy either 30KB (7.SKW) or 44KB (ll KW). Optionally, OS MVT may use HASP (about
lOOKB) for a combined spooling, control stream entry, and handling remote job entry (RJE). Remote job entry takes another 80KB when it is resident.
In summary, over 200KB (SOKW) could be devoted to symbionts and RJE by using normal OS support and, usually, the customer will use HASP for lOOKB.
Remember, XOS does all these things as a part of the monitor including the uti I ities.
Real Time: OS MVT has weakness under RTM in the real time area, as pre-viously noted. XOS provides its own external interrupts for real time. Resi-dent and non-resiResi-dent real time are provided as monitor functions underXOS with complete facilities for developing and checking out real time programs from batch, remote batch and time-sharing terminals. Additionally, real time pro-grams can be initiated by the operator, a job in the batch/remote batch stream, or a terminal. RTM programs must be present (at least partially) all the time.
TIME-SHARING SOFTWARE COMPARISON Insta Ilati on Con trol Features
•
Automatic connection to processors*
(Restri cted use)
Automati c connecti on to charge structure * (Unique charges based on usage)
Shared processors (Reentrant)*
Batch control
Controlled resource usage (core, priority, devi ces, etc.) *
Batch priority relation to terminal
UTS
TIME-SHARING SOFTWARE COMPARISON (Continued)
Program/ Appl i cation Development Features
• Terminals
Standard FORTRAN, COBOL - others Other Processors
Terminal job entry (under priority control) Compiling not required for each run (load modules maintained)
Output optionally permanent Terminal must stay connected
Batch/Remote Batch Priority scheduling
Standard system fi les avai lable Non-standard fi les avai lable Pri n ter forms contro I
Checkpoi nt/Restart Real Time
Initiated
by
terminalInitiated by batch/remote batch
UTS
TIME-SHARING SOFTWARE COMPARISON (Continued)
In i ti ated by interrupt Initiated by operator Preempts core
Highest priority
UTS Optional Optional Possible Yes
IBM 360/370 OS MVT/TSO Yes
Unknown Possible Not really
* UTS Reference Manual covers these topics in detail. Additional information is contained in UTS Specification No. 702489.
, XOS COMPARISON
Operating System Classification: Genera I Purpose/Ti me- Shari ng
Operational Modes
• Minimum System Requirements
• Number of Concurrent Programs
SYSTEM PRICES AND POLICIES
•
•
PRICES
IBM's basic rental agreement provides 176 metered hours of usage. Overtime charges average 10% of basic monthly rental per hour of extra usage.
IBM includes maintenance in the basic monthly rental charge. For installa-tions paying extra usage charges round-the-clock, emergency maintenance support is included in the extra usage charges.
IBM has NO long-term lease agreement.
IBM allows a purchase option credit of 50+% of first year's monthly rental.
For Federal, State and Local Governments, a credit is allowed of 50% of the first two year's monthly rental.
IBM has gone to separate pricing of training, systems analyst support, and program produ cts.
POLICIES
IBM is using hardware on the System/370 to enforce their program product's licensing agreement. Built into the CPU and I/O channels are unique ID numbers which, in conjunction with Read ID instructions, will limit program operation to a specific machine.
The System/370 announcement included a unique one-year warrenty including parts and labor on all purchased System/370 equipment. All maintenance per-formed under the warrenty must be accompl ished on standard shift. They wi II charge for emergency mai ntenance performed on an extra sh ift.
a: ..
o CO Ln