MVS - MVS

Další použití najdete v tématu MVS (disambiguation) .

Multiple Virtual Storage (MVS)
Logo IBM.svg
Vývojář IBM
Napsáno Assembler (XF) , PL/S
Rodina OS OS/360
První vydání 1974 ; Před 47 lety ( 1974 )
Marketingový cíl Počítače sálových počítačů IBM
K dispozici v Angličtina
Platformy Systém/370 , Systém/390
Ovlivněn TSS
Licence Proprietární
Zpočátku zdarma
Předchází OS/360 MVT , OS/VS2 (SVS)
Uspěl MVS/SE, MVS/SP , MVS/XA , MVS/ESA , OS/390 , z/OS
Historie operačních systémů sálových počítačů IBM
Počáteční mainframe počítačové OS
Různé OS řady S/360
DOS/360 a nástupci (1966)
OS/360 a nástupci (1966)
Řada VM
Řada TPF
UNIX a podobné Unixu

Multiple Virtual Storage , běžněji nazývaný MVS , byl nejčastěji používaným operačním systémem na sálových počítačích System/370 a System/390 IBM . IBM vyvinula MVS spolu s OS/VS1 a SVS jako nástupce OS/360 . Nesouvisí to s jinými řadami operačních systémů sálových počítačů IBM, např. VSE , VM , TPF .

Přehled

MVS, poprvé vydané v roce 1974, bylo několikrát rozšířeno o programové produkty s novými názvy:

  • první na MVS/SE (MVS/System Extensions),
  • vedle MVS/SP (MVS/systémový produkt) verze 1,
  • vedle MVS/XA (MVS/eXtended Architecture),
  • vedle MVS/ESA (MVS/Enterprise Systems Architecture),
  • poté na OS/390 a
  • konečně do z/OS (když byla u modelů zSeries přidána 64bitová podpora ). IBM přidala podporu UNIX (původně nazývanou OpenEdition MVS ) v MVS/SP V4.3 a získala certifikace POSIX a UNIX ™ na několika různých úrovních od IEEE , X/Open a The Open Group . Jádro MVS zůstává v zásadě stejný operační systém. Podle návrhu běží programy napsané pro MVS na z/OS bez úprav.

Zpočátku IBM popisovala MVS jednoduše jako novou verzi OS/VS2 , ale ve skutečnosti to bylo velké přepsání. Verze 1 OS/VS2 byla aktualizací OS/360 MVT, která zachovala většinu původního kódu a stejně jako MVT byla napsána hlavně v jazyce sestavení . Jádro MVS bylo téměř úplně napsáno v Assembler XF , ačkoli několik modulů bylo napsáno v PL/S , ale ne ty citlivé na výkon, zejména ne Input/Output Supervisor ( IOS ). Použití IBM „OS/VS2“ kladlo důraz na kompatibilitu směrem nahoru: aplikační programy, které běžely pod MVT, ani nepotřebovaly překompilovat, aby běžely pod MVS. Stejné soubory jazyka Job Control Language lze použít beze změny; veřejné služby a jiná než hlavní zařízení, jako je TSO, fungovala beze změny. IBM a uživatelé od začátku téměř jednomyslně nazývali nový systém MVS a IBM nadále používalo termín MVS při pojmenovávání pozdějších hlavních verzí, jako je MVS/XA.

Evoluce MVS

OS/360 MFT (Multitasking with a Fixed number of Tasks) provided multitasking: several memory partitions , each of a fixed size, were set up when the operating system is installed and when the operator redefined them. Například může existovat malý oddíl, dva střední oddíly a velký oddíl. Pokud by byly ke spuštění připraveny dva velké programy, jeden by musel počkat, až druhý dokončí a uvolní velký oddíl.

OS/360 MVT (Multitasking s proměnlivým počtem úkolů) bylo vylepšení, které dále vylepšilo využití paměti. Místo použití oddílů paměti pevné velikosti MVT přiděluje paměť regionům pro kroky úlohy podle potřeby za předpokladu, že je k dispozici dostatek souvislé fyzické paměti . To byl významný pokrok oproti správě paměti MFT, ale měl určité slabiny: pokud úloha přiděluje paměť dynamicky (jak to dělá většina třídicích programů a systémů pro správu databází ), museli programátoři odhadnout maximální požadavek paměti na úlohu a předem ji definovat pro MVT . Pracovní krok, který obsahoval kombinaci malých a velkých programů, plýtval pamětí při běhu malých programů. Nejvážněji by se paměť mohla roztříštit , tj. Paměť nevyužívaná současnými úlohami by mohla být rozdělena na zbytečně malé kousky mezi oblastmi používanými současnými úlohami a jediným řešením bylo počkat, než některé aktuální úlohy skončí, než začnete s novými.

Na počátku 70. let se IBM snažila tyto potíže zmírnit zavedením virtuální paměti (kterou IBM nazývala „virtuální úložiště“), což umožňovalo programům požadovat adresní prostory větší než fyzická paměť. Původní implementace měly jeden virtuální adresní prostor sdílený všemi úlohami. OS/VS1 byl OS/360 MFT v rámci jednoho virtuálního adresního prostoru; OS/VS2 SVS byl OS/360 MVT v rámci jednoho virtuálního adresního prostoru. OS/VS1 a SVS tedy v zásadě měly stejné nevýhody jako MFT a MVT, ale dopady byly méně závažné, protože úlohy mohly vyžadovat mnohem větší adresní prostory a požadavky vycházely ze 16 MB fondu, i když fyzické úložiště bylo menší.

Adresní prostory MVS - globální pohled
MVS (sdílená část všech adresních prostorů)
Aplikace 1 Aplikace 2 Aplikace 3
Sdílená virtuální oblast (ovládaná MVS)
Pohled jedné aplikace
MVS
Aplikace 1
Sdílená virtuální oblast

V polovině 70. let představila společnost IBM MVS, který nejenže podporoval virtuální úložiště, které bylo větší než dostupné skutečné úložiště, ale také SVS, ale také umožňoval spouštění neomezeného počtu aplikací v různých adresních prostorech. Dva souběžné programy se mohou pokusit získat přístup ke stejné adrese virtuální paměti, ale systém virtuální paměti přesměroval tyto požadavky do různých oblastí fyzické paměti. Každý z těchto adresních prostorů se skládal ze tří oblastí: operační systém (jedna instance sdílená všemi úlohami), oblast aplikace jedinečná pro každou aplikaci a sdílená virtuální oblast používaná pro různé účely, včetně komunikace mezi úlohami. IBM slíbila, že aplikační oblasti budou vždy alespoň 8 MB. Díky tomu bylo MVS dokonalým řešením pro obchodní problémy, které vyplynuly z potřeby spouštět více aplikací.

MVS maximalizoval potenciál zpracování poskytováním možností multiprogramování a vícenásobného zpracování . Stejně jako jeho předchůdci MVT a OS/VS2 SVS , MVS podporovalo multiprogramování ; programové instrukce a související data jsou naplánovány řídicím programem a danými cykly zpracování. Na rozdíl od jednoprogramovacího operačního systému tyto systémy maximalizují využití potenciálu zpracování rozdělením cyklů zpracování mezi instrukce spojené s několika různými souběžně spuštěnými programy. Tímto způsobem řídicí program nemusí čekat na dokončení operace I/O, než bude pokračovat. Provedením pokynů pro více programů je počítač schopen přepínat tam a zpět mezi aktivními a neaktivními programy.

Rané edice MVS (polovina 70. let) patřily mezi první z řady OS IBM na podporu konfigurací více procesorů , ačkoli varianta M65MP OS/360 běžící na modelech 360 a 65 poskytovala omezenou podporu více procesorů. 360 Model 67 hostil také multiprocesorové operační systémy TSS/360 , MTS a CP-67 . Protože systémy s více procesy mohou provádět instrukce současně, nabízejí větší výpočetní výkon než systém s jedním zpracováním. Díky tomu byla společnost MVS schopna řešit obchodní problémy způsobené potřebou zpracovat velké množství dat.

Víceprocesní systémy jsou buď volně propojené, což znamená, že každý počítač má přístup ke společné pracovní zátěži, nebo pevně spojené , což znamená, že počítače sdílejí stejné skutečné úložiště a jsou ovládány jedinou kopií operačního systému . Společnost MVS si ponechala jak volně vázané vícenásobné zpracování připojeného podpůrného procesoru (ASP), tak i úzce spojené víceprocesní vícenásobné zpracování OS/360 Model 65 . V úzce propojených systémech sdílely dva procesory souběžný přístup ke stejné paměti (a kopii operačního systému) a periferním zařízením, což v případě selhání jednoho procesoru poskytovalo vyšší výpočetní výkon a určitý stupeň ladné degradace . Ve volně propojených konfiguracích měl každý ze skupiny procesorů (jeden a / nebo pevně spojený) vlastní paměť a operační systém, ale sdílené periferie a součást operačního systému JES3 umožňovaly správu celé skupiny z jedné konzoly. To poskytlo větší odolnost a umožnilo operátorům rozhodnout, který procesor by měl spouštět které úlohy z centrální fronty úloh. MVS JES3 dal uživatelům možnost do sítě společně dva nebo více systémy zpracování dat přes sdílené disky a Channel-to-Channel adaptéry (CTCA je). Tato schopnost byla nakonec k dispozici uživatelům JES2 jako Multi-Access SPOOL (MAS).

MVS původně podporovalo 24bitové adresování (tj. Až 16 MB). Jak postupoval základní hardware, podporoval 31bitové (XA a ESA; až 2048 MB) a nyní (jako z/OS) 64bitové adresování. Nejvýznamnějšími motivy rychlého upgradu na 31bitové adresování byl růst velkých sítí pro zpracování transakcí, většinou řízených CICS , které běžely v jednom adresním prostoru-a systém správy relační databáze DB2 potřeboval více než 8 MB aplikace adresní prostor, aby fungoval efektivně. (Dřívější verze byly konfigurovány do dvou adresních prostorů, které komunikovaly prostřednictvím sdílené virtuální oblasti, ale to způsobilo značnou režii, protože veškerá taková komunikace se přenášela prostřednictvím operačního systému.)

Hlavní uživatelská rozhraní pro MVS jsou: Job Control Language (JCL), který byl původně navržen pro dávkové zpracování, ale od 70. let minulého století byl také používán ke spouštění a přidělování zdrojů dlouhodobým interaktivním úlohám, jako je CICS ; a TSO (Time Sharing Option), interaktivní rozhraní pro sdílení času , které se používalo hlavně ke spouštění vývojových nástrojů a několika informačních systémů pro koncové uživatele. ISPF je aplikace TSO pro uživatele na terminálech řady 3270 (a později také na virtuálních počítačích ), která umožňuje uživateli provádět stejné úkoly jako příkazový řádek TSO, ale způsobem orientovaným na nabídku a formu a s editorem celé obrazovky a prohlížeč souborů. Základním rozhraním TSO je příkazový řádek , ačkoli zařízení byla přidána později pro rozhraní řízená formuláři.

MVS udělala velký krok vpřed v odolnosti vůči chybám, postavená na dřívějším zařízení STAE, které IBM nazývalo obnova softwaru . IBM se k tomu rozhodla po letech praktických zkušeností s MVT v reálném světě v obchodním světě. Selhání systému nyní mělo zásadní dopad na zákaznické podniky a IBM se rozhodla udělat zásadní skok v návrhu a předpokládat, že navzdory nejlepším technikám vývoje a testování softwaru dojde k „problémům“. Tento hluboký předpoklad byl klíčový pro přidání velkého procenta kódu odolnosti vůči chybám do systému a pravděpodobně přispěl k úspěchu systému v tolerování selhání softwaru a hardwaru. Je těžké získat statistické informace, které by dokázaly hodnotu těchto konstrukčních funkcí (jak můžete měřit problémy, jimž bylo zabráněno nebo které byly obnoveny?), Ale společnost IBM v mnoha dimenzích vylepšila obnovu softwaru odolnou vůči chybám a rychlé řešení problémů. funkce, v průběhu času.

Tento návrh specifikoval hierarchii programů pro zpracování chyb, v režimu systému (jádro/'privilegovaný'), nazývaný Routines pro obnovu funkcí, a v režimu uživatele ('úkol' nebo 'problémový program'), nazývaný "ESTAE" (rozšířená specifikovaná úloha) Abnormal Exit routines), které byly vyvolány v případě, že systém zjistil chybu (chyba hardwaru procesoru nebo úložiště nebo chyba softwaru). Díky každé obnovovací rutině bylo možné funkci „hlavní řady“ znovu vyvolat, zachycená data diagnostiky chyb postačující k ladění způsobujícího problému a buď „opakované“ (znovu vyvolat hlavní řadu), nebo „perkolované“ (eskalované zpracování chyb na další rutinu obnovy v hierarchii).

Při každé chybě tedy systém zachytil diagnostická data a pokusil se provést opravu a udržet systém v chodu. V případě neopravených chyb bylo nejhorší možné odstranit prostor adres uživatelů („úloha“). Ačkoli to byl počáteční bod návrhu, až do nejnovější verze MVS (z/OS), program obnovy měl nejen zaručenou vlastní rutinu obnovy, ale každá rutina obnovy má nyní svou vlastní rutinu obnovy. Tato struktura obnovy byla vložena do základního řídicího programu MVS a programovací zařízení jsou k dispozici a používají je vývojáři aplikačních programů a vývojáři třetích stran.

Prakticky díky obnově softwaru MVS byl problém s laděním snazší i obtížnější. Obnova softwaru vyžaduje, aby programy zanechávaly „stopy“ toho, kde jsou a co dělají, a usnadnily tak ladění - ale skutečnost, že zpracování probíhá i přes chybu, může stopy přepsat. Počáteční sběr dat v době chyby maximalizuje ladění a existují nástroje pro rutiny obnovy (režim úkolů a režim systému), které to umožňují.

IBM zahrnula další kritéria pro hlavní softwarový problém, který vyžadoval servis IBM. Pokud se součásti hlavní řady nepodařilo zahájit obnovu softwaru, bylo to považováno za platné hlášení, které lze nahlásit. Rovněž pokud se rutině obnovy nepodařilo shromáždit významná diagnostická data, takže původní problém byl řešitelný pomocí dat shromážděných touto rutinou obnovy, standardy IBM nařídily, že tuto chybu lze hlásit a vyžaduje opravu. Standardy IBM, pokud byly důsledně uplatňovány, tedy podporovaly neustálé zlepšování.

IBM pokračovala v podpoře hlavního nástroje obslužnosti Dynamic Support System (DSS), který zavedla v OS/VS1 a OS/VS2 Release 1. Toto interaktivní zařízení bylo možné vyvolat k zahájení relace za účelem vytvoření diagnostických procedur nebo vyvolání již uložených procedur . Procedury zachytily speciální události, jako je načtení programu, I/O zařízení, volání systémových procedur a poté spustily aktivaci dříve definovaných procedur. Tyto postupy, které bylo možné vyvolat rekurzivně, umožňovaly čtení a zápis dat a změnu toku instrukcí. Byl použit hardware pro nahrávání událostí programu.

IBM zrušila podporu pro DSS s Selectable Unit 7 (SU7), aktualizaci OS/VS2 Release 3.7 požadovanou programovým produktem OS/VS2 MVS/System Extensions (MVS/SE), číslo programu 5740-XEl. Skupina uživatelů SHARE splnila požadavek, aby IBM obnovila DSS, a IBM poskytla PTF, který umožní použití DSS po instalaci MVS/SE.

IBM opět upustilo od podpory DSS s SU64, aktualizace OS/VS2 verze 3.8 vyžadovaná verzí 2 MVS/SE.

Využití záznamu PER (Program-Event Recording) bylo provedeno vylepšením diagnostického příkazu SLIP se zavedením podpory PER (SLIP/Per) v SU 64/65 (1978).

Více kopií MVS (nebo jiných operačních systémů IBM) by mohlo sdílet stejný počítač, pokud by tento stroj byl řízen VM/370 . V tomto případě byl VM/370 skutečným operačním systémem a považoval „hostující“ operační systémy za aplikace s neobvykle vysokými oprávněními. V důsledku pozdějších hardwarových vylepšení mohla jedna instance operačního systému (buď MVS, nebo VM s hosty, nebo jiné) obsadit logický oddíl (LPAR) namísto celého fyzického systému.

Několik instancí MVS lze organizovat a hromadně spravovat ve struktuře nazývané systémový komplex nebo sysplex , zavedená v září 1990. Instance spolupracují prostřednictvím softwarové komponenty zvané Cross-system Coupling Facility (XCF) a hardwarové komponenty nazývané Hardware Coupling Facility (CF nebo Integrated Coupling Facility, ICF, pokud je umístěna na stejném hardwaru sálového počítače). Více sysplexů lze spojit pomocí standardních síťových protokolů, jako je proprietární Systems Network Architecture (SNA) společnosti IBM, nebo v poslední době prostřednictvím TCP/IP . Operační systém z/OS (nejnovější potomek MVS) má také nativní podporu pro spouštění aplikací POSIX a Single UNIX Specification . Podpora začala s MVS/SP V4R3 a IBM získala certifikaci UNIX 95 pro z/OS V1R2 a novější.

Systém se obvykle používá v podnikání a bankovnictví a aplikace jsou často psány v COBOL . Programy COBOL se tradičně používaly se systémy pro zpracování transakcí, jako jsou IMS a CICS . U programu spuštěného v CICS jsou do zdrojového kódu COBOL vloženy speciální příkazy EXEC CICS. Preprocesor (překladač) nahradí tyto příkazy EXEC CICS příslušným kódem COBOL pro volání CICS před kompilací programu - ne zcela na rozdíl od jazyka SQL používaného k volání DB2 . Aplikace lze také psát v jiných jazycích, jako je C , C ++ , Java , assembler , FORTRAN , BASIC , RPG a REXX . Jazyková podpora je zabalena jako běžná součást s názvem „Jazykové prostředí“ nebo „LE“, která umožňuje jednotné ladění, trasování, profilování a další funkce nezávislé na jazyce.

Systémy MVS jsou tradičně přístupné pomocí terminálů 3270 nebo počítačů s emulátory 3270. Mnoho dnešních sálových aplikací však má vlastní webové nebo GUI rozhraní. Operační systém z/OS má integrovanou podporu pro TCP/IP . Správa systému, prováděná v minulosti s terminálem 3270, se nyní provádí prostřednictvím konzoly HMC (Hardware Management Console) a stále častěji i webových rozhraní. Operátorské konzoly jsou poskytovány prostřednictvím emulátorů 2074, takže je nepravděpodobné, že uvidíte jakýkoli procesor S/390 nebo zSeries, ke kterému je připojen skutečný 3270.

Nativní schéma kódování znaků MVS a jeho periferií je EBCDIC , ale instrukce TR usnadnila překlad do dalších 7- a 8bitových kódů. Postupem času IBM přidala hardwarově akcelerované služby k provádění překladu do a mezi většími kódy, hardwarově specifické služby pro transformace Unicode a softwarovou podporu např. ASCII , ISO/IEC 8859 , UTF-8 , UTF-16 a UTF-32 . Služby softwarového překladu berou jako vstupy zdrojové a cílové kódové stránky.

Souborový systém MVS

Soubory jiné než soubory Unixu se v MVS správně nazývají datové sady . Názvy těchto souborů jsou uspořádány v katalozích, které jsou samy soubory VSAM .

Názvy datových sad (DSN, mainframe výraz pro názvy souborů) jsou organizovány v hierarchii, jejíž úrovně jsou odděleny tečkami, např. „DEPT01.SYSTEM01.FILE01“. Každá úroveň v hierarchii může mít až osm znaků. Celková délka názvu souboru je maximálně 44 znaků včetně teček. Podle konvencí se součásti oddělené tečkami používají k uspořádání souborů podobně jako adresáře v jiných operačních systémech. Existovaly například obslužné programy, které plnily podobné funkce jako Průzkumník Windows (ale bez GUI a obvykle v režimu dávkového zpracování ) - přidávání, přejmenovávání nebo mazání nových prvků a hlášení veškerého obsahu zadaného prvku. Na rozdíl od mnoha jiných systémů však tyto úrovně nejsou obvykle skutečné adresáře, ale pouze konvence pojmenování (jako původní systém souborů Macintosh , kde hierarchie složek byla iluzí udržovanou Finderem). TSO podporuje výchozí předponu pro soubory (podobně jako koncept „aktuálního adresáře“) a RACF podporuje nastavení řízení přístupu na základě vzorů názvů souborů, analogicky k řízení přístupu v adresářích na jiných platformách.

Stejně jako u ostatních členů rodiny OS byly datové sady MVS orientovány na záznamy . MVS zdědila tři hlavní typy od svých předchůdců:

  • Soubory sekvenčních dat byly normálně čteny po jednom záznamu od začátku do konce.
  • V sadách dat BDAM (přímý přístup) musel aplikační program určit fyzické umístění dat, ke kterým chtěla přistupovat (obvykle zadáním offsetu od začátku datové sady).
  • V sadách dat ISAM byla zadaná část každého záznamu definována jako klíč, který by mohl být použit jako klíč k vyhledání konkrétních záznamů. Klíč poměrně často sestával z více polí, ale tato musela na sebe navazovat a ve správném pořadí; a klíčové hodnoty musely být jedinečné. Z tohoto důvodu soubor IBM ISAM může mít pouze jeden klíč, což odpovídá na primární klíč části databáze relační tabulky; ISAM nemohl podporovat cizí klíče .

Sekvenční a ISAM datové sady mohly ukládat záznamy s pevnou nebo proměnnou délkou a všechny typy mohly zabírat více než jeden svazek disku.

Všechny tyto jsou založeny na struktuře disku VTOC .

Dřívější systémy správy databází IBM používaly různé kombinace datových sad ISAM a BDAM - obvykle BDAM pro skutečné ukládání dat a ISAM pro indexy.

Na začátku sedmdesátých let představily operační systémy virtuální paměti IBM novou komponentu pro správu souborů VSAM , která poskytovala podobná zařízení:

  • Entry-Sequenced Datasets (ESDS) poskytovaly zařízení podobná těm sekvenčním i BDAM datovým sadám, protože je bylo možné číst buď od začátku do konce, nebo přímo zadáním offsetu od začátku.
  • Datové sady seřazené podle klíčů (KSDS) představovaly zásadní upgrade od ISAM: umožňovaly sekundární klíče s nejedinečnými hodnotami a klíče tvořené zřetězením nesouvislých polí v libovolném pořadí; výrazně snížily problémy s výkonem způsobené záznamy o přetečení v ISAM; a výrazně snížily riziko, že selhání softwaru nebo hardwaru uprostřed aktualizace indexu může index poškodit.

Tyto formáty VSAM se staly základem systémů pro správu databází IBM , IMS/VS a DB2 - obvykle ESDS pro skutečné ukládání dat a KSDS pro indexy.

VSAM také zahrnoval komponentu katalogu používanou pro uživatelské katalogy a hlavní katalog MVS.

Rozdělené datové sady (PDS) byly sekvenční datové sady rozdělené na „členy“, z nichž každý mohl být zpracován jako sekvenční soubory samostatně (jako složka v hierarchickém systému souborů). Nejdůležitější použití PDS bylo pro programové knihovny - správci systému použili hlavní PDS jako způsob alokace místa na disku projektu a projektový tým poté vytvořil a upravil členy. Další použití PDS byly knihovny často používaných postupů řízení úloh (PROC) a „kopie knih“ příkazů programovacího jazyka, jako jsou definice záznamů používané několika programy.

Generation Data Groups (GDGs) jsou skupiny podobných pojmenovaných datových sad, na které lze odkazovat absolutním číslem generace nebo offsetem od nejnovější generace. Původně byly navrženy tak, aby podporovaly postupy zálohování dědeček-otec-syn -pokud byl soubor upraven, změněná verze se stala novým „synem“, předchozí „syn“ se stal „otcem“, předchozí „otec“ se stal „dědečkem“ “a předchozí„ dědeček “byl smazán. Dalo by se však nastavit GDG s více než 3 generacemi a některé aplikace používaly GDG ke shromažďování dat z několika zdrojů a podávání informací do jednoho programu - každý sběrný program vytvořil novou generaci souboru a konečný program přečetl celou skupinu jako jeden sekvenční soubor (neuvedením generace v JCL ).

Moderní verze MVS (např. Z/OS) používají datové sady jako kontejnery pro unixové souborové systémy spolu se zařízením pro jejich částečnou integraci. To znamená, že unixové programy používající fopen () mohou přistupovat k datové sadě MVS a uživatel může přidělit unixový soubor, jako by to byla datová sada, s určitými omezeními. Hierarchical File System (HFS) (neplést s Apple Hierarchical File System ) využívá jedinečný typ datové sady, zatímco novější z / OS File System (ZFS) (neplést s Sun ZFS ) používá VSAM data lineární Nastavte (LDS).

Programy běžící na počítačích připojených k síti (jako je AS/400 ) mohou pomocí místních rozhraní pro správu dat transparentně vytvářet, spravovat a přistupovat k souborům orientovaným na záznam VSAM pomocí produktů klient-server implementovaných podle architektury DDM ( Distributed Data Management Architecture ) . DDM je také základní architekturou pro server MVS DB2, který implementuje architekturu DRDA ( Distributed Relational Database Architecture ).

Upgrady na MVS

Kromě nových funkcí, které IBM přidala s verzemi a dílčími verzemi OS/VS2, poskytla IBM řadu bezplatných přírůstkových změn (ICR) a volitelných jednotek (SU) a účtovatelné programové produkty a programy vyvinuté v terénu, které IBM nakonec spojila jako část z/OS. Tyto zahrnují:

  • ACF/TCAM (5735-RCl)
  • ACF/VTAM (5746-RC3, 5735-RC2)
  • Podpora datového zařízení/zařízení (DF/DS), 5740-AM7
  • Rozšířená funkce datového zařízení (DF/EF), 5740-XYQ
  • Data Facility/Data Set Services (DF/DSS), 5740-UT3.
  • Řazení datových zařízení, 5740-SM1
  • Metoda rozšířeného sekvenčního přístupu OS/VS2 MVS (SAM-E), 5740-AM3
  • Nahrazuje produkt MVS/370 Data Facility Product (DFP), 5665-295
    • Podpora zařízení 5740-AM7 Data Facility Device (DFDS)
    • Rozšířená funkce 5740-XYQ Data Facility (DFEF)
    • Rozšířená metoda sekvenčního přístupu 5740-AM3 (SAM-E)
    • Kryptografická možnost přístupových služeb 5740-AM8
    • Offline 3800 Utility 5748-UT2
  • Produkt MVS/XA Data Facility, verze 1, vydání 1, 5665-284
  • Produkt MVS/XA Data Facility, verze 2, vydání 1, 5665-XA2
  • Produkt MVS/ESA Data Facility verze 3, 5665-XA3
  • Subsystém pro správu úložiště datových zařízení (DFSMS), 5695-DF1
    nahrazuje DFP, DF/DSS a DF/HSM
  • Balíček příkazů OS/VS2 MVS TSO (5740-XT6)
  • TSO Command Processor - FDP 5798 -AYF (příkaz PRINT)
  • Zařízení pro řízení programování TSO/VS2 - FDP 5798 -BBJ
  • TSO Programming Control Facility - II (PCF II), FDP 5798 -CLW,
  • TSO Extensions
    Nahrazuje TSO Command Package, TSO Command Processor a PCF
    • 5665-285 pro MVS/370
    • 5665-293 pro MVS/XA
    • 5685-025 pro MVS/XA
      První verze s REXX
  • Rozšíření OS/VS2 MVS/System, 5740-XEl
  • MVS/systémový produkt
    • JES3 verze 1 5740-XYN
    • JES2 verze 1 5740-XYS
    • Produkt MVS/System-JES2 verze 2, 5740-XC6
    • MVS/System Product-JES3 verze 2, 5665-291
    • MVS/System Product-JES2 verze 3, 5685-001
    • MVS/System Product-JES3 verze 3, 5685-002
    • Systémový produkt MVS/ESA: JES2 verze 4, 5695-047
    • Systémový produkt MVS/ESA: JES3 verze 4, 5695-048
    • Systémový produkt MVS/ESA: JES2 verze 5, 5655-068
    • Systémový produkt MVS/ESA: JES3 verze 5, 5655-069

Data Facility Product (DFP)

Koncem sedmdesátých a počátkem osmdesátých let společnost IBM oznámila:

  • Podpora zařízení 5740-AM7 Data Facility Device (DF/DS)
  • Rozšířená funkce 5740-XYQ Data Facility (DF/EF)
  • Rozšířená metoda sekvenčního přístupu 5740-AM3 (SAM-E)
  • Kryptografická možnost přístupových služeb 5740-AM8
  • Offline 3800 Utility 5748-UT2

DF/DS přidala novou podporu zařízení a IBM oznámila, že již nebude přidávat podporu zařízení do volné základny. DF/EF přidal vylepšenou strukturu katalogu (ICF) jako alternativu k katalogům VSAM a řídicím svazkům (CVOL), ale byla plná problémů se spolehlivostí.

Když IBM oznámila MVS/SP verze 2 (MVS/XA), oznámila také Data Facility Product ™ (DFP ™) jako náhradu a upgrade na dalších pět výše uvedených produktů, které podle ní budou staženy z trhu s účinností od 1. prosince , 1984. DFP/370 Release 1 (číslo programu 5665-295), oznámený 7. června 1983, byl pro MVS/SP verze 1, MVS/SE a OS/VS2 R3.8 a byl volitelný, ale MVS/Extended Architecture Data Facility Product (5665-284) byl základním předpokladem pro MVS/SP verze 2 (MVS/XA). Kromě vylepšení zařízení pro správu dat nahradil DFP bezplatné verze editoru propojení a nástrojů.

Moderní MVS

MVS běžící na emulátoru Hercules

MVS se nyní vyvinul do z/OS; starší vydání MVS již IBM nepodporuje a od roku 2007 jsou podporována pouze 64bitová vydání z/OS. z/OS podporuje běh starších 24bitových a 31bitových aplikací MVS spolu s novějšími 64bitovými aplikacemi.

Verze MVS až 3,8j (24bitové, vydané v roce 1981) byly volně dostupné a nyní je možné spouštět vydání MVS 3.8j v emulátorech sálových počítačů zdarma.

MVS/370

MVS/370 je obecný termín pro všechny verze operačního systému MVS před MVS/XA. Architektura System/370 v době vydání MVS podporovala pouze 24bitové virtuální adresy, takže architektura operačního systému MVS/370 je založena na 24bitové adrese. Kvůli této délce 24bitové adresy mají programy spuštěné pod MVS/370 každý 16 MB souvislého virtuálního úložiště.

MVS/XA

MVS/XA , neboli Multiple Virtual Storage/Extended Architecture , byla verze MVS, která podporovala architekturu 370-XA , která rozšířila adresy z 24 bitů na 31 bitů a poskytla adresovatelnou paměťovou oblast o velikosti 2  gigabajty . Podporoval také režim 24bitového staršího adresování pro starší 24bitové aplikace (tj. Ty, které ukládaly 24bitovou adresu do spodních 24 bitů 32bitového slova a využívaly horních 8 bitů tohoto slova pro jiné účely) .

MVS/ESA

MVS/ESA: Architektura podnikového systému MVS. Verze MVS, poprvé představená jako MVS/SP verze 3 v únoru 1988. Nahrazena/přejmenována na OS/390 koncem roku 1995 a následně jako z/OS .

MVS/ESA OpenEdition: upgrade na verzi 4 Release 3 MVS/ESA oznámený v únoru 1993 s podporou POSIX a dalších standardů. Zatímco původní vydání mělo pouze certifikaci National Institute of Standards and Technology (NIST) pro shodu s Federal Information Processing Standard (FIPS) 151, následná vydání byla certifikována na vyšších úrovních a jinými organizacemi, např. X/Open a jeho nástupcem, The Open Group . Zahrnoval asi 1 milion nových řádků kódu, které poskytují prostředí API, nástroje a rozšířené uživatelské rozhraní. Funguje s hierarchickým souborovým systémem poskytovaným DFSMS (Data Facility System Managed Storage). Plášť a nástroje jsou založeny na produktech InterOpen společnosti Mortice Kerns . Nezávislí specialisté odhadují, že vyhovuje více než 80% otevřených systémů-více než většina unixových systémů. Podpora DCE2 byla oznámena v únoru 1994 a mnoho nástrojů pro vývoj aplikací v březnu 1995. Od poloviny roku 1995, kdy se všechny otevřené funkce staly standardní součástí vanilla MVS/ESA SP verze 5, vydání 1, IBM přestala odlišovat OpenEdition od operačního systému. Pod OS/390 V2R6 se stal UNIX System Services a toto jméno ponechal pod z/OS .

OS/390

Hlavní článek: OS/390

Na konci roku 1995 IBM spojila MVS s několika programovými produkty a změnila název z MVS/ESA na OS/390.

z/OS

Hlavní článek: z/OS

Aktuální úroveň MVS je prodávána jako z/OS.

Úzce související operační systémy

Japonští výrobci sálových počítačů Fujitsu a Hitachi opakovaně i nelegálně získali zdrojový kód MVS a interní dokumentaci IBM v jednom z nejslavnějších případů průmyslové špionáže 20. století . Společnost Fujitsu do značné míry spoléhala na kód IBM v hlavním operačním systému MSP a stejně tak Hitachi udělala totéž pro svůj operační systém VOS3 . MSP a VOS3 byly silně prodávány v Japonsku, kde stále drží podstatný podíl instalované základny sálových počítačů, ale také do určité míry v jiných zemích, zejména v Austrálii. I chyby společnosti IBM a překlepy v dokumentaci byly věrně zkopírovány. IBM spolupracovala s americkým federálním úřadem pro vyšetřování při operaci bodnutí a neochotně dodávala společnostem Fujitsu a Hitachi proprietární hardwarové technologie MVS a mainframe v průběhu víceletých vyšetřování kulminujících počátkem 80. let 20. století-vyšetřování, která zapletla vedoucí manažery společností a dokonce i některé japonské vládní představitelé. Amdahl se však nepodílel na krádeži duševního vlastnictví společnosti Fujitsu . Veškerá komunikace od společnosti Amdahl do společnosti Fujitsu byla prováděna prostřednictvím „Specifikací pouze společnosti Amdahl“, které byly důkladně očištěny od jakékoli IP IBM nebo jakýchkoli odkazů na IP IBM.

V návaznosti na vyšetřování dosáhla IBM mnohamilionových vypořádání se společnostmi Fujitsu i Hitachi a po mnoho let sbírala značné zlomky zisků obou společností. Spolehlivé zprávy uvádějí, že osady přesáhly 500 000 000 USD.

Tyto tři společnosti se již dlouho smířlivě dohodly na mnoha společných obchodních podnicích. Například v roce 2000 IBM a Hitachi spolupracovaly na vývoji mainframového modelu IBM z900.

Kvůli tomuto historickému kopírování jsou MSP a VOS3 řádně klasifikovány jako „vidlice“ MVS a mnoho dodavatelů softwaru třetích stran s produkty kompatibilními s MVS dokázalo vyrobit verze kompatibilní s MSP a VOS3 s malou nebo žádnou úpravou.

Když IBM v roce 2000 představila své 64bitové mainframy z/Architecture , představila IBM také 64bitový operační systém z/OS, přímý nástupce OS/390 a MVS. Společnosti Fujitsu a Hitachi se rozhodly nelicencovat architekturu IBM z/Architecture pro své kvazi-MVS operační systémy a hardwarové systémy, a tak MSP a VOS3, i když jsou stále nominálně podporovány svými dodavateli, zachovávají většinu architektonických omezení MVS z 80. let až do současnosti. Vzhledem k tomu, že z/OS stále podporuje aplikace a technologie z období MVS-z/OS stále obsahuje většinu kódu MVS, i když během desetiletí vývoje výrazně vylepšený a vylepšený-aplikace (a operační postupy) běžící na MSP a VOS3 se mohou přesunout do z/OS mnohem snadněji než u jiných operačních systémů.

Viz také

Poznámky

Reference

  • Bob DuCharme: „Příručka operačních systémů, část 06: MVS“ (k dispozici online zde )
  • Přehled OS/VS2 MVS (PDF) . První vydání. IBM. Červen 1978. GC28-0984-0. Archivováno z originálu (PDF) dne 16. března 2011.

externí odkazy