OS/VS2 (SVS)
| Company type | Operating system component |
|---|---|
| Industry | Computer software |
| Predecessor | MVT (Operating System/360) |
| Founded | 1970s |
| Products | Virtual storage management for OS/VS2 |
| Parent | IBM |
Single Virtual Storage (SVS) represents the initial release of Operating System/Virtual Storage 2 (OS/VS2), serving as the successor to the MVT variant of Operating System/360. Although SVS was designed as a transitional platform prior to the introduction of MVS, IBM continued to maintain and enhance SVS even after MVS became available.
SVS provides a consolidated 16MiB address space that is shared among all system processes, independent of the actual physical memory installed.
Differences from MVT
In OS/360, the Interval Timer was utilized for tracking time and triggering events. SVS, leveraging capabilities of the S/370 architecture, relies solely on the TOD Clock, Clock Comparator, and CPU Timer for these functions.
Whereas OS/360 loads error recovery and transient SVC routines from SYS1.SVCLIB into limited transient areas, SVS loads these routines from SYS1.LPALIB into the pageable link pack area (PLPA) during Initial Program Load (IPL) when using the Create LPA (CLPA) option, thereby removing the need for transient areas.
Following the ADR lawsuit, IBM began monetizing several software products, primarily language processors. As a result, SVS excludes sort/merge utilities and most language processors except for the new Assembler (XF), which remains necessary for system generation.
The introduction of the Authorized Program Facility (APF) imposed restrictions on certain privileged services, limiting their use to authorized programs—those link-edited with AC(1) and loaded from designated libraries. MVS later broadened APF to encompass additional authorized data sets.
Due to pageable storage allocated for Reader/Interpreter components, SVS eliminates the Automatic SYSIN Batching (ASB) Reader feature. Similarly, it removes OS/360's Direct SYSOUT (DSO) capability, reflecting reduced reliance on tape storage as DASD became more affordable.
Earlier interactive tools in OS/360 such as CRJE, GJP, ITF, and SGJP were not carried forward; instead, TSO assumed their roles but does not support IBM 2250 terminals. However, batch graphics access through GAM and GSP remains available. The batch debugging utility TESTRAN was discontinued with TSO's introduction.
The Dynamic Support System (DSS), a debugging tool introduced in OS/VS system software, continued to be available until subsequent MVS versions.
SVS’s Machine Check Handler (MCH) enhances error recovery by deallocating defective pages without requiring special handling for refreshable transient SVC routines as was necessary in OS/360.
The Error Recovery Procedure (ERP) transient area is expanded in SVS; however, support for outdated I/O devices and hierarchical structures unnecessary without 2361 Large Core Storage analogs is removed.
In SVS, the Link Pack Area (LPA) is divided into three segments:
- Fixed Link Pack Area (FLPA): modules loaded into virtual storage with real addressing at IPL
- Modified Link Pack Area (MLPA): paged modules loaded during IPL
- Permanent Link Pack Area (PLPA): supported by a dedicated paging data set; modules can be preloaded using the CLPA option
Unlike OS/360’s 360/65 version which supports multiprocessor configurations, SVS does not offer multiprocessing capabilities; users requiring this functionality on System/370 must adopt MVS.
SVS omits QTAM and Remote Job Entry (RJE), with ASP and HASP serving as alternative solutions.
The expanded 16 MiB address space diminishes external fragmentation compared to MVT, thus eliminating the need for Rollin/Rollout mechanisms.
Instead of loading transient SVC routines into small memory regions requiring intricate management as in OS/360, SVS preloads all SVC routines into virtual storage within either the nucleus or LPA areas.
While maintaining compatibility with OS/360’s SPOOL system, most installations preferred ASP or HASP—precursors to JES3 and JES2 respectively.
Storage Management
The approach to storage management in SVS is similar to that found in MVT, though it incorporates notable distinctions. SVS accommodates up to 16MiB of addressable memory within a single address space, regardless of the actual physical memory size. Both the nucleus and FLPA utilize a Virtual=Real (V=R) scheme, where each virtual address corresponds directly to a physical address.
When a job step requests V=R storage, all allocated pages correspond to actual page frames. If a program check occurs with interrupt codes 16 or 17, SVS determines whether the page is assigned; if it is, the system allocates a page frame and loads the page data. If not, SVS initiates an Abnormal End (ABEND) with code 0C4, mirroring MVT’s protection violation response.
Additionally, SVS provides page fixing functionality to keep certain pages resident in memory and prevent their paging out—primarily to facilitate I/O processes.
I/O
S/370 I/O channels do not support address translation. To enable virtual storage operations, IBM introduced the Indirect Data Address (IDA) mechanism: a Channel Control Word (CCW) with the IDA bit set points to an IDA list (IDAL) rather than directly referencing the I/O buffer.
The Execute Channel Program (EXCP) SVC in SVS manages CCW translation by fixing pages in memory, allocating storage for IDA lists, converting virtual addresses into real addresses, and modifying CCWs accordingly. Once the I/O operation completes, EXCP reverses these modifications.
For privileged programs that handle their own page fixing and IDA list management, SVS offers the Execute Channel Program in Real Storage (EXCVR) SVC.
Independent Component Releases (ICRs)
Following its initial release, IBM augmented SVS with several significant components:
- Telecommunications Access Method (TCAM) Release 10
- Virtual Sequential Access Method (VSAM)
- Virtual Telecommunications Access Method (VTAM) Release 2