IBM-ның 1970-жылдардағы Future Systems жобасы: жаңа бағдарламалық жасақтама мен аппараттық құралдарды жасау, бәсекелестікті күшейту, табысты арттыру мақсатындағы зерттеу.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
1970 жылдардағы ғылыми-зерттеу жобасы. "Болашақ жүйелері" жобасы (FS) – 1970 жылдардың басында IBM компаниясында жүргізілген ғылыми-зерттеу және әзірлеу жобасы. Оның мақсаты – қазіргі заманғы қуатты аппараттық құралдарды пайдалану арқылы бағдарламалық жасақтаманы дамытуды жеңілдететін жаңа бағдарламалық модельдерді, соның ішінде компьютерлік өнімдердің революциялық желісін жасау болды.
1970s research project
The Future Systems project (FS) was a research and development project undertaken in IBM in the early 1970s, aiming to develop a revolutionary line of computer products, including new software models which would simplify software development by exploiting modern powerful hardware.
Өмірбаян
1960 жылдардың соңына дейін IBM өзінің пайдасының көп бөлігін аппараттық құралдар есебінен көріп келді, қолдау бағдарламалық жасақтамалары мен қызметтерін жүйелерімен бірге ұсынып, оларды көбірек тарту үшін жасады. Баға белгісі тек аппараттық жабдыққа қойылды, бірақ бұл бағалар бағдарламалық қамтамасыз ету мен қызметтерге бөлінген қаражатты қамтыды. Басқа өндірушілер IBM-ге қарағанда едәуір арзанға үйлесімді аппараттық құралдарды, негізінен таспалық және дискілік жекпе-жектер сияқты сыртқы құрылғыларды сатуға кірісті, бұл бағдарламалық қамтамасыз ету мен қызметтерге жұмсалған шығынды қайтару мүмкіндігін азайтты. Бұл жағдай Гин Амдал IBM-ден кетіп, IBM ұсыныстарынан жылдамырақ және арзанырақ System/370 үйлесімді жүйелерді жасап шығаратын компания құрғанда күрт өзгерді. 1971 жылдың басында IBM-нің ішкі жұмыс тобы, Project Counterpoint, үйлесімді мейнфрейм бизнесінің өміршең екендігін және бағдарламалық қамтамасыз ету мен қызметтерге аппараттық құралдың бағасының құрамында төленетін ақының негізі тез жойылатынын анықтады. Тағы бір стратегиялық мәселе – есептеу құрылғыларының құны тұрақты түрде төмендеп, бағдарламалау мен операциялардың құны, яғни персоналдық шығындар, тұрақты түрде өсіп жатты. Сондықтан, алдағы жылдары клиенттердің ИТ-бюджетінде аппараттық құралдарға бөлінетін қаражат айтарлықтай азаяды, соның салдарынан IBM-нің кірісі де азаяды. IBM болашақ өнімдерінде қолданбаларды жасау және пайдалану шығындарын төмендету арқылы клиенттерге ИТ-нің жалпы құнын азайтып, сол шығынның үлкен бөлігін иеленуі керек болды. Сонымен қатар, IBM өзінің басымдығы мен аппараттық құралдың бағасына бағдарламалық қамтамасыз ету мен қызметтерді қосу саясаты үшін заңдық шабуылға ұшырады, сондықтан ұсыныстарының бір бөлігін қайта біріктіруге жасалған кез келген әрекет кез келген заңдық шағымға төтеп беру үшін таза техникалық негізде берік негізделуі тиіс болды.
Until the end of the 1960s, IBM had been making most of its profit on hardware, bundling support software and services along with its systems to make them more attractive. Only hardware carried a price tag, but those prices included an allocation for software and services. Other manufacturers had started to market compatible hardware, mainly peripherals such as tape and disk drives, at a price significantly lower than IBM, thus shrinking the possible base for recovering the cost of software and services. This changed more dramatically when Gene Amdahl left IBM and set up a company making System/370 compatible systems that were both faster and less expensive than IBM's offerings. In early 1971, an internal IBM task force, Project Counterpoint, concluded that the compatible mainframe business was indeed a viable business and that the basis for charging for software and services as part of the hardware price would quickly vanish. Another strategic issue was that the cost of computing was steadily going down while the costs of programming and operations, being made of personnel costs, were steadily going up. Therefore, the part of the customer's IT budget available for hardware vendors would be significantly reduced in the coming years, and with it the base for IBM revenue. It was imperative that IBM, by addressing the cost of application development and operations in its future products, would at the same time reduce the total cost of IT to the customers and capture a larger portion of that cost. At the same time, IBM was under legal attack for its dominant position and its policy of bundling software and services in the hardware price, so that any attempt at "re bundling" part of its offerings had to be firmly justified on a purely technical basis, so as to withstand any legal challenge.
Деректерге қол жеткізу
FS-тің бір жобалау принципі "бір деңгейлі сақтау" болды, бұл виртуалды жад (VM) идеясын тұрақты деректерді қамтуға кеңейтті. Дәстүрлі жобаларда бағдарламалар жадыны деректерді білдіретін мәндерді сақтауға бөледі. Бұл деректер әдетте машинаны сөндіргенде немесе пайдаланушы жүйеден шыққанда жоғалады. Бұл деректерді болашақта қолдану үшін оларды тұрақты сақтау үшін қосымша код қажет, мысалы, қатты дискіге жазу, содан кейін болашақта қайта оқу. Осы ортақ операцияларды жеңілдету үшін 1960 жылдары бірқатар деректер базасы қозғалтқыштары пайда болды, олар бағдарламаларға деректерді қозғалтқышқа беруге мүмкіндік берді, содан кейін оны сақтап, қажет болғанда қайтадан алуға мүмкіндік берді. Сол кезде пайда болған тағы бір технология – виртуалды жад. Алғашқы жүйелерде бағдарлама деректерді бөлу үшін қолданатын жадтың мөлшері жүйедегі негізгі жадтың мөлшерімен шектелген, ол бір машинадан екіншісіне жылжыған кезде немесе басқа бағдарламалар өз жадыларын бөліп отырғанда, мұндай факторларға байланысты өзгеруі мүмкін. Виртуалды жад жүйелері бұл мәселені шешіп, барлық бағдарламаларға қол жетімді жадтың ең жоғары мөлшерін, әдетте өте үлкен санды, машинадағы физикалық жадтан әлдеқайда көп деп анықтады. Егер бағдарлама физикалық түрде қол жетімді емес жадыны бөлуді сұраса, негізгі жадтың бөлігі дискіге жазылады және бұл орын жаңа бөлу үшін қолданылады. Егер бағдарлама осы шығарылған ("пажетталған" немесе "ажыратылған") жад аймағынан деректерді сұраса, ол қайтадан негізгі жадқа көрінбестен жүктеледі. Бір деңгейлі сақтау – виртуалды жадтың барлық жадқа, ішкі немесе сыртқы, кеңейтілуі. VM жүйелері жадыны дискіге көрінбестен жазады, бұл файл жүйесінің міндетімен бірдей, сондықтан оны файл жүйесі ретінде пайдалануға болады. Бағдарламалар "негізгі жадтан" жадыны бөлемейді, одан кейін VM оны басқа резервтік сақтауға жібереді, барлық жады VM жүйесімен бірден бөлінеді. Бұл деректерді сақтау мен жүктеудің қажеті жоқ дегенді білдіреді, жадыға бөлу ғана ВМ жүйесі оны жазып шығарған кезде осы әсерге ие болады. Пайдаланушы қайта кіргенде, сол деректер және оны орындаған бағдарламалар, олар да бір жадқа енгізілгендіктен, бірден бұрынғы күйінде қол жетімді болады. Жүктеу мен сақтаудың барлық тұжырымдамасы алынып тасталады, бағдарламалар мен бүкіл жүйелер тіпті машинаны қайта іске қосқаннан кейін де олар тұрған жерден алады. Бұл тұжырымдама Multics жүйесінде зерттелді, бірақ өте баяу болып шықты, бірақ бұл негізгі жадтың ядрода іске асырылған және қатты диск немесе барабан түрінде әлдеқайда баяу қосалқы сақтау орны бар қол жетімді аппараттың жанама әсері болды. Жаңа түрдегі ұшпалы емес жадтың, әсіресе бұршақ жадтың енгізілуімен, симуляция жоғары деңгейдегі машинада FS нұсқауларының орындалуы сол машинадағы System/370 эмуляторына қарағанда баяу екенін көрсетті. FS жобасы ақырында IBM клиенттердің қабылдауын бастапқыда болжағаннан әлдеқайда шектеулі болатынын түсінгенде тоқтатылды, өйткені 360 архитектурасы клиенттері үшін қолайлы қосымша көшіру жолы болмады. Нағыз революциялық жүйені жобалау үшін максималды еркіндікті қалдыру үшін, қолданбалардың көшіруін жеңілдету FS жобасының негізгі жобалау мақсаттарының бірі емес, бірақ жаңа архитектураны берілген ретінде қабылдайтын бағдарламалық көшіру құралдарымен қарастырылуы керек еді. Соңында, COBOL және ассемблерлік тілдегі қолданбаларға негізделген пайдаланушылардың инвестициясын FS-ке көшірудің құны көптеген жағдайларда жаңа жүйені сатып алудың құнынан жоғары болуы мүмкін екендігі анықталды.
One design principle of FS was a "single level store" which extended the idea of virtual memory (VM) to cover persistent data. In traditional designs, programs allocate memory to hold values that represent data. This data would normally disappear if the machine is turned off, or the user logs out. In order to have this data available in the future, additional code is needed to write it to permanent storage like a hard drive, and then read it back in the future. To ease these common operations, a number of database engines emerged in the 1960s that allowed programs to hand data to the engine which would then save it and retrieve it again on demand. Another emerging technology at the time was the concept of virtual memory. In early systems, the amount of memory available to a program to allocate for data was limited by the amount of main memory in the system, which might vary based on such factors as it is moved from one machine to another, or if other programs were allocating memory of their own. Virtual memory systems addressed this problem by defining a maximum amount of memory available to all programs, typically some very large number, much more than the physical memory in the machine. In the case that a program asks to allocate memory that is not physically available, a block of main memory is written out to disk, and that space is used for the new allocation. If the program requests data from that offloaded ("paged" or "spooled") memory area, it is invisibly loaded back into main memory again. A single level store is essentially an expansion of virtual memory to all memory, internal or external. VM systems invisibly write memory to a disk, which is the same task as the file system, so there is no reason it cannot be used as the file system. Instead of programs allocating memory from "main memory" which is then perhaps sent to some other backing store by VM, all memory is immediately allocated by the VM. This means there is no need to save and load data, simply allocating it in memory will have that effect as the VM system writes it out. When the user logs back in, that data, and the programs that were running it as they are also in the same unified memory, are immediately available in the same state they were before. The entire concept of loading and saving is removed, programs, and entire systems, pick up where they were even after a machine restart. This concept had been explored in the Multics system but proved to be very slow, but that was a side effect of available hardware where the main memory was implemented in core with a far slower backing store in the form of a hard drive or drum. With the introduction of new forms of non volatile memory, most notably bubble memory, Moreover, simulations showed that the execution of native FS instructions on the high end machine was slower than the System/370 emulator on the same machine. The FS project was finally terminated when IBM realized that customer acceptance would be much more limited than originally predicted because there was no reasonable application migration path for 360 architecture customers. In order to leave maximum freedom to design a truly revolutionary system, ease of application migration was not one of the primary design goals for the FS project, but was to be addressed by software migration aids taking the new architecture as a given. In the end, it appeared that the cost of migrating the mass of user investments in COBOL and assembly language based applications to FS was in many cases likely to be greater than the cost of acquiring a new system.