Проект IBM «Будущие системы»

Проект IBM «Будущие системы» (англ. Future Systems project, FS) представлял собой научно-исследовательскую и опытно-конструкторскую разработку, начатую в IBM в начале 1970-х годов. Целью проекта было создание революционной линейки компьютерных продуктов, включая новые программные модели, которые должны были упростить разработку программного обеспечения за счёт использования современного мощного оборудования. Предполагалось, что новые системы заменят на рынке модель System/370 к концу 1970-х годов.

Было два ключевых компонента FS. Первый — это использование одноуровневого хранилища, которое позволяло обращаться к данным, хранящимся во вторичной памяти, такой как жёсткие диски, в программе так, как если бы они находились в основной памяти. Переменные в коде могли указывать на объекты в хранилище, и они автоматически загружались бы в память, устраняя необходимость писать код для обработки файлов. Второй компонент заключался во включении в систему инструкций, соответствующих операторам языков программирования высокого уровня, Это позволяло системе напрямую выполнять программы без необходимости использования компилятора для преобразования языка в машинный код. Таким образом, можно было, например, написать программу в текстовом редакторе и машина смогла бы выполнить её напрямую.

Объединение этих двух концепций в единую систему за один шаг оказалось невыполнимой задачей. Инженеры с самого начала указывали на эту проблему, но руководители проекта игнорировали её по многим причинам. Официально начатый осенью 1971 года, к 1974 году проект заглох, а в феврале 1975 года был официально отменён. Одноуровневая память была реализована в System/38 в 1978 году и впоследствии перенесена на другие системы в линейке, но концепция машины, непосредственно работающей с языками высокого уровня, так и не появилась ни в одном продукте IBM.

System/360 анонсирована в апреле 1964. Всего через шесть месяцев IBM начала исследовательский проект, посвященный тенденциям на рынке и тому, как их следует использовать при создании серии машин, которые в будущем должны были заменить модель 360. Одним из значительных изменений стало внедрение интегральных схем (ИС), которые позволили заменить множество отдельных компонентов модели 360 меньшим количеством ИС. Это позволило бы создавать более мощные машины по той же цене, что и существующие модели^[1].

К середине 1960-х годов модель 360 стала чрезвычайно популярной и хорошо продавалась. Это повлияло на разработку новых машин, поскольку возникла потребность в полной обратной совместимости с серией 360. Когда в 1970 году были представлены новые машины 1970, теперь известные как System/370, они, по сути, представляли собой модифицированные 360-е, в которых использовались интегральные схемы малой степени интеграции для логики, значительно увеличенный объём внутренней памяти и другие незначительные изменения^[2]. Было добавлено несколько новых инструкций и улучшены существующие, но с точки зрения программиста система осталась практически неизменной^[3].

Экономический спад 1969–1970 годов привёл к замедлению продаж в период 1970-71 годов и гораздо меньшим заказам на 370 по сравнению с быстрым успехом 360 пятью годами ранее^[4]. Впервые за десятилетия рост IBM остановился. В то время как некоторые сотрудники компании начали работать над внедрением полезных улучшений в 370 как можно скорее, чтобы сделать их более привлекательными, другие считали, что в долгосрочной перспективе сработает только полное переосмысление системы^[3].

За два месяца до анонса серии 370 компания вновь начала анализировать изменения на рынке и их влияние на будущие разработки^[3]. В 1965 году Гордон Мур предсказал экспоненциальный рост числа транзисторов в интегральных схемах, что сегодня известно как Закон Мура. Джерриер А. Хаддад из IBM написал служебную записку на эту тему, предположив, что стоимость логических элементов и памяти будет стремиться к нулю быстрее, чем её можно будет измерить^[3].

Внутреннее исследование Корпоративного технологического комитета (англ. Corporate Technology Committee, CTC) показало, что в течение следующих пяти лет цена на память снизится в 30 раз, а в последующие пять лет — ещё в 30 раз. Чтобы сохранить свои объёмы продаж, IBM должна была бы продавать в пять раз больше памяти через пять лет и в 900 раз больше — через десять лет. Аналогично, ожидалось, что стоимость жёстких дисков снизится в десять раз за следующие десять лет. Для поддержания традиционного роста продаж на 15% в год, к 1980 году компании пришлось бы продавать в 40 раз больше дискового пространства и в 3600 раз больше памяти^[4].

В терминах самого компьютера, если бы компания продолжила развитие от 360-й к 370-й и далее к гипотетической System/380, то новые машины были бы основаны на крупномасштабной интеграции и значительно упростились бы в плане сложности и стоимости. Продавать такую машину по текущим ценам было невозможно. Если бы они попытались, другая компания представила бы гораздо более дешёвые системы^[3] Вместо этого они могли бы производить гораздо более мощные машины по тем же ценам, но их клиенты уже недостаточно использовали существующие системы. Чтобы предоставить разумный аргумент для покупки новой высокопроизводительной машины, IBM должна была придумать причины, по которым клиентам понадобится эта дополнительная мощность^[5][6].

Другой стратегической проблемой было то, что, хотя стоимость вычислений неуклонно снижалась, затраты на программирование и эксплуатацию, состоящие из затрат на персонал, неуклонно росли. Следовательно, доля ИТ-бюджета клиента, доступная для поставщиков оборудования, в ближайшие годы значительно сократится, а вместе с ней и база доходов IBM. Было крайне важно, чтобы IBM, решая проблему стоимости разработки и эксплуатации приложений в своих будущих продуктах, одновременно снизила общую стоимость ИТ для клиентов и захватила большую часть этих затрат^[6].

В 1969 году президент подразделения разработки систем IBM (англ. IBM System Development Division), занимавшегося созданием крупнейших мейнфреймов компании, Боб Овертон Эванс, обратился к Эриху Блоху из лаборатории IBM в Покипси с просьбой рассмотреть, как компания могла бы использовать более дешевые компоненты для создания машин, которые при этом сохранили бы прибыльность. Блох, в свою очередь, поручил Карлу Конти разработать концепцию таких систем. Увидев термин «future systems», Эванс назвал эту группу «Advanced Future Systems» (AFS, рус. Продвинутые Будущие Системы). Группа собиралась примерно раз в две недели.

Среди множества разработок, изначально изучавшихся в рамках AFS, одна концепция выделялась особенно. В то время появлялись первые системы с виртуальной памятью (англ. virtual memory, VM), а основополагающий проект Multics развил эту идею, положив ее в основу одноуровневого хранилища. Согласно этой концепции все данные в системе как будто находятся в основной памяти и если данные физически находятся во вторичной памяти, система виртуальной памяти автоматически загружает их в память, когда программа к ним обращается. Вместо того чтобы писать код для чтения и записи данных в файлы, программист просто сообщал операционной системе, какие данные он собирается использовать. Эти данные затем появлялись в памяти программы в виде объектов и могли обрабатываться как любые другие переменные. Система виртуальной памяти обеспечивала синхронизацию данных с хранилищем по мере необходимости^[7].

В то время эта концепция считалась особенно полезной, поскольку появление магнитоэлектронных запоминающих устройств предполагало, что будущие системы не будут иметь отдельной памяти на магнитных сердечниках и жёстких дисках, а всё будет храниться в большом объеме магнитоэлектронной памяти^[7]. Физически, системы будут одноуровнемыми хранилищами, так что идея наличия еще одного уровня для «файлов», представляющих отдельное хранилище, не имела смысла. Указатели на одно большое хранилище не только позволяли бы обращаться к любым данным так, как если бы они были локальными, но и устраняли бы необходимость в отдельных интерфейсах программирования приложения (англ. application programming interface, API) для одних и тех же данных в зависимости от того, были ли они загружены или нет^[7].

Эванс также попросил Джона Макферсона из штаб-квартиры IBM в Армонке возглавить другую группу, чтобы рассмотреть, как IBM будет предлагать эти новые разработки в различных своих подразделениях. Группа из двенадцати участников, представляющих три подразделения, подготовила «Отчет о системе более высокого уровня», (англ. Higher Level System Report, HLS), который был представлен 25 февраля 1970 года. Ключевым компонентом HLS была идея о том, что программирование обходится дороже, чем аппаратное обеспечение. Если бы система могла значительно снизить стоимость разработки, то такую систему можно было бы продавать дороже, поскольку общая стоимость эксплуатации все равно была бы ниже, чем у конкурентов^[8].

Основная идея серии System/360 заключалась в создании единой архитектуры набора команд (англ. instruction set architecture, ISA) которые могли бы понадобиться программисту на ассемблере. В то время как предыдущие системы могли быть ориентированы на научные вычисления или расчеты с валютой и имели соответствующие инструкции, модель 360 предлагала инструкции для этих задач, а также практически для любых других. Затем были разработаны отдельные машины, ориентированные на конкретные рабочие нагрузки, которые выполняли эти инструкции непосредственно в аппаратном обеспечении, а остальные реализовывались с помощью микрокода. Это означало, что любая машина семейства 360 могла запускать программы с любой другой, просто с разной скоростью в зависимости от задачи. Это оказалось чрезвычайно успешным, поскольку клиент мог приобрести машину начального уровня и в будущем всегда перейти на более быструю, зная, что все его приложения будут продолжать работать.

Несмотря на обширный набор инструкций 360, эти инструкции оставались низкоуровневыми, представляя собой отдельные операции, выполняемые центральным процессором (ЦП), такие как «сложить два числа» или «сравнить это число с нулем». Языки программирования и их связи с операционной системой позвлоляли пользователям вводить программы, используя высокоуровневые понятия, такие как «open file» (открыть файл) или «add these arrays» (сложить эти массивы). Компиляторы реобразовывали эти высокоуровневые абстракции в последовательность инструкций машинного кода.

В HLS инструкции напрямую представляли бы эти задачи более высокого уровня. То есть, в машинном коде существовали бы инструкции для «open file». Если программа вызывала такую инструкцию, не было необходимости преобразовывать ее в код более низкого уровня, машина выполняла бы это внутренне с помощью микрокода или даже прямой аппаратной реализации^[8]. Это работало в сочетании с одноуровневым хранилищем. Для реализации HLS каждый бит данных в системе сопровождался дескриптором — записью, содержащей тип данных, их местоположение в памяти, а также точность и размер. Поскольку дескрипторы могли указывать на массивы и структуры записей, это позволяло машинному языку обрабатывать их как атомарные объекты^[8].

Прямое представление этих объектов более высокого уровня в системе сделало бы пользовательские программы значительно меньше и проще. Например, чтобы сложить два массива чисел, хранящихся в файлах, в традиционных языках программирования, обычно пришлось бы открыть оба файла, прочитать по одному элементу из каждого, сложить их, а затем сохранить результат в третьем файле. В подходе HLS достаточно было бы просто открыть файлы и вызвать команду сложения. Операционная система отобразила бы их в памяти, создала бы дескрипторы, указывающие, что оба объекта являются массивами, и тогда инструкция сложения увидела бы, что это массивы, и сложила бы все значения. Присвоение этого значения новому массиву привело бы к его записи обратно в хранилище. Программа, которая могла занимать страницу кода, теперь сократилась до нескольких строк. Более того, поскольку это был естественный язык машины, командная оболочка сама по себе была программируемой таким же образом, и не было бы необходимости «писать программу» для такой простой задачи, как эта. Её можно было бы просто ввести как команду^[8].

В заключение отчета говорится:

До конца 1960-х годов IBM получала основную прибыль от аппаратного обеспечения, предлагая в комплекте с системами программное обеспечение и услуги поддержки, чтобы сделать их более привлекательными. Цена указывалась только на оборудование, но в эту цену включалась и стоимость программного обеспечения и услуг^[7].

Другие производители начали продавать совместимое оборудование, в основном периферийные устройства, такие как ленточные и дисковые накопители, по значительно более низкой цене, чем IBM, тем самым сокращая возможную базу для возмещения затрат на программное обеспечение и услуги. В ответ IBM отказалась обслуживать машины с этими сторонними дополнениями, что почти сразу же привело к масштабным антимонопольным расследованиям и многочисленным последующим судебным разбирательствам. В 1969 году компания была вынуждена прекратить практику комплексных предложений и объявила о раздельной продаже программных продуктов^[9]

Джин Амдал увидел возможность продавать совместимые машины без программного обеспечения. Клиенты могли приобрести оборудование у Амдала, а операционную систему и другое ПО — у IBM. Если бы IBM отказалась продавать им ПО, это было бы нарушением их юридических обязательств. В начале 1970 года Амдал уволился из IBM и объявил о своем намерении выпустить совместимые с System/370 машины, которые были бы быстрее топовых моделей IBM, но при этом стоили бы дешевле в покупке и эксплуатации^[10]

Сначала IBM не проявляла беспокойства. Основную прибыль компания получала от программного обеспечения и технической поддержки, и эти доходы продолжали поступать. Тем не менее, чтобы убедиться в этом, в начале 1971 года была сформирована внутренняя рабочая группа IBM, получившая название «Project Counterpoint» (Проект «Контрапункт»), для изучения данной концепции. Они пришли к выводу, что бизнес совместимых мейнфреймов действительно жизнеспособен, и что основа для взымания платы за программное обеспечение и услуги в составе цены оборудования быстро исчезнет. Эти события породили в компании желание найти решение, которое вновь заставило бы клиентов приобретать всё у IBM, но при этом не нарушало бы антимонопольное законодательство^[7].

Если бы IBM последовала рекомендациям отчета HLS, это означало бы, что другие поставщики должны были бы скопировать микрокод, реализующий огромное количество инструкций. Поскольку это было программное обеспечение, в случае такого копирования эти компании нарушили бы авторские права^[7]. В этот момент концепции AFS/HLS вновь обрели актуальность в компании.

В мае-июне 1971 года в Армонке под руководством Джона Опеля, тогдашнего вице-президента IBM, собралась международная рабочая группа. Перед ней стояла задача изучить возможность создания новой линейки компьютеров, которая, используя технологические преимущества IBM, сделала бы устаревшими все предыдущие компьютеры — как совместимые модели других производителей, так и собственные продукты IBM. Группа пришла к выводу, что проект стоит дальнейшей разработки, но ключевым фактором для его успешного внедрения на рынке станет десятикратное снижение затрат на разработку, эксплуатацию и поддержку прикладного программного обеспечения.

Основные цели проекта FS были сформулированы следующим образом:

• полностью вывести из эксплуатации всё существующее вычислительное оборудование, включая оборудование IBM, за счет максимального использования новейших технологий
• значительно снизить затраты и трудоемкость разработки и эксплуатации приложений
• создать технически обоснованную базу для максимально возможного объединения предложений IBM (аппаратного обеспечения, программного обеспечения и услуг)

Предполагалось, что новая архитектура, более активно использующая аппаратные ресурсы, стоимость которых снижалась, сможет существенно упростить разработку программного обеспечения и сократить расходы как для IBM, так и для клиентов.

Одним из принципов проектирования файловой системы было «одноуровневое хранилище», которое расширяло концепцию виртуальной памяти, распространяя её на постоянные данные. В традиционных системах программы выделяют память для хранения значений, представляющих данные. Эти данные обычно исчезали при выключении машины или выходе пользователя из системы. Чтобы эти данные были доступны в будущем, требовался дополнительный код для их записи в постоянное хранилище, такое как жёсткий диск, а затем для их считывания обратно. Для упрощения этих распространенных операций в 1960-х годах появилось множество механизмов СУБД, которые позволяли программам передавать данные системе, которая затем сохраняла их и извлекала по запросу.

В то время также набирала популярность концепция виртуальной памяти. В ранних системах объём памяти, доступный программе для размещения данных, ограничивался объёмом основной памяти в системе. Этот объём мог меняться в зависимости от таких факторов, как перемещение программы на другую машину или выделение памяти другими программами. Системы виртуальной памяти решали эту проблему, определяя максимальный объём памяти, доступный всем программам, как правило, очень большое число, значительно превышающее объём физической памяти машины. Если программа запрашивала память, которая физически отсутствовала, блок основной памяти выгружался на диск, и это пространство использовалось для нового выделения. Если программа запрашивала данные из этой выгруженной («страничной» или «свопированной») области памяти, они незаметно загружались обратно в основную память^[11].

Одноуровневое хранилище — это, по сути, расширение виртуальной памяти на всю память, как внутреннюю, так и внешнюю. Системы виртуальной памяти незаметно записывают содержимое памяти на диск, что является той же задачей, что и файловая система, поэтому нет причин, по которым её нельзя было бы использовать в качестве файловой системы. Вместо того чтобы программы выделяли память из «основной памяти», которая затем, возможно, отправляется в какое-то другое хранилище подкачки системой виртуальной памяти, вся память сразу же выделяется системой виртуальной памяти. Это означает, что нет необходимости сохранять и загружать данные; простое их выделение в памяти приведет к такому эффекту, поскольку система виртуальной памяти запишет их. Когда пользователь снова входит в систему, эти данные и программы, которые их использовали, поскольку они также находятся в той же унифицированной памяти, немедленно доступны в том же состоянии, в котором они были до этого. Полностью устраняется концепция загрузки и сохранения; программы и целые системы продолжают работу с того места, где остановились, даже после перезапуска машины.

Эта концепция исследовалась в системе Multics, но оказалась очень медленной. Однако это было следствием ограничений доступного оборудования: основная память была реализована на магнитных кольцах, а гораздо более медленное вспомогательное хранилище представлял собой жёсткий диск или барабан. С появлением новых видов энергонезависимой памяти, главным образом магнитоэлектронная память^[7], работавшей на скоростях, сравнимых со скоростью магнитных сердечников, но обладающей плотностью хранения, аналогичной жёсткому диску, стало ясно, что одноуровневое хранилище больше не будет иметь недостатков в производительности.

В Future Systems планировалось сделать одноуровневое хранилище ключевой концепцией своих новых операционных систем. Вместо отдельного движка базы данных, к которому обращались бы программисты, в программном интерфейсе приложений (API) системы были бы просто вызовы для получения данных из памяти. Эти вызовы API основывались бы на конкретных аппаратных или микропрограммных реализациях, доступных только в системах IBM, тем самым достигая цели IBM по тесной интеграции аппаратного обеспечения с работающими на нём программами^[7].

Одним из принципов было использование очень высокоуровневых сложных инструкций, которые должны были реализовываться в микрокоде. Например, одна из таких инструкций, CreateEncapsulatedModule, представляла собой компоновщик. Другие инструкции предназначались для поддержки внутренних структур данных и операций языков программирования, таких как FORTRAN, COBOL и PL/I. По сути, FS был спроектирован как крайне сложный набор команд (CISC)^[7].

Существовал и другой способ представления той же концепции — вся совокупность функций, ранее реализованных в виде аппаратного обеспечения, программ операционной системы, программ баз данных и прочего, теперь рассматривалась как единая интегрированная система. Каждая элементарная функция реализовывалась на одном из множества уровней, включая схемы, микрокод и обычное программное обеспечение. Предполагалось наличие более чем одного уровня микрокода и кода, иногда называемого пикокодом или милликодом. В зависимости от собеседника, само понятие «машины» варьировалось от функций, реализованных на уровне схем (для специалистов по аппаратному обеспечению), до полного набора функций, предлагаемых пользователям, независимо от их реализации (для системных архитекторов).

Общая концепция также предусматривала создание «универсального контроллера» для выполнения в основном операций ввода-вывода вне основного процессора Этот универсальный контроллер имел бы очень ограниченный набор инструкций, предназначенный только для операций ввода-вывода, что стало пионерским шагом в разработке концепции компьютера с редуцированным набором команд (англ. reduced instruction set computer, RISC).

Тем временем, Джон Кок, один из ведущих разработчиков ранних компьютеров IBM,начал исследовательский проект по созданию первого компьютера с редуцированным набором команд (RISC)^[12]. В долгосрочной перспективе RISC архитектура IBM 801, которая впоследствии развилась в архитектуры POWER, PowerPC и Power ISA, оказалась значительно дешевле в реализации и способной достигать гораздо более высоких тактовых частот.

Проект FS был официально запущен в сентябре 1971 года, после выполнения рекомендаций специальной рабочей группы, сформированной во втором квартале того же года. Со временем несколько других исследовательских проектов, проводившихся в различных подразделениях IBM, были объединены с проектом FS или стали с ним связаны.

На протяжении всего своего существования проект FS осуществлялся в условиях строгих мер безопасности. Проект был разбит на множество подпроектов, порученных различным командам. Документация также была разделена на множество частей, и доступ к каждому документу требовал подтверждения необходимости его получения со стороны проектного офиса. Документы отслеживались и могли быть отозваны в любое время.

В своей служебной записке Сова (Sowa, см. Ссылки ниже) отметил, что заявленная цель всей этой бюрократии — не дать никому понять всю систему; эта цель, безусловно, была достигнута.

В результате большинство людей, работавших над проектом, имели крайне ограниченное представление о нём, ограниченное тем, что им нужно было знать для внесения ожидаемого вклада. Некоторые команды даже работали над FS, не зная об этом. Это объясняет, почему, когда их просят дать определение FS, большинство людей дают очень частичный ответ, ограниченный пересечением FS с их областью компетенции.

Было запланировано три варианта реализации архитектуры FS

1. флагманская модель разрабатывалась в Покипси, штат Нью-Йорк, где производились самые крупные и быстрые компьютеры IBM
2. следующая по уровню модель проектировалась в Эндикотте, штат Нью-Йорк, который отвечал за компьютеры среднего класса
3. модель ниже этой разрабатывалась в Бёблингене, Германия, а самая маленькая модель — в Хёрслe, Великобритания^[13].

Непрерывный диапазон производительности мог быть обеспечен за счет варьирования количества процессоров в системе на каждом из четырёх уровней реализации.

В начале 1973 года общее управление проектом и команды, ответственные за более «внешние» слои, общие для всех реализаций, были объединены в лаборатории Mohansic ASDD (расположенной на полпути между штаб-квартирой в Армонке/Уайт-Плейнс и Покипси).

Проект FS был закрыт в 1975 году. Причины его завершения назывались разные, в зависимости от того, кого спрашивали. каждый ссылался на проблемы в той области, с которой был знаком. На самом деле, успех проекта зависел от множества прорывов во всех сферах – от проектирования и производства схем до маркетинга и обслуживания. Хотя каждую отдельную проблему, взятую саму по себе, можно было бы решить, вероятность того, что все они будут решены вовремя и согласованно, была практически нулевой.

Одним из признаков была низкая производительность самой масштабной реализации, но проект также был омрачен затяжными внутренними спорами о различных технических аспектах, включая дебаты внутри IBM о преимуществах RISC и CISC архитектур. Сложность набора команд была еще одним препятствием. Этот набор команд считался «непостижимым» даже для инженеров IBM , и были веские основания полагать, что единое хранилище данных на уровне всей системы не может быть частично скопировано, что предвосхитило разделение единого хранилища System/38 в IBM AS/400^[14]. Более того, моделирование показало, что выполнение собственных FS-инструкций на высокопроизводительной машине было медленнее, чем работа эмулятора System/370 на той же машине^[15].

Проект FS был окончательно прекращен, когда IBM осознала, что принятие системы клиентами будет гораздо более ограниченным, чем первоначально предсказывалось, поскольку для клиентов с архитектурой 360 не существовало разумного пути миграции приложений. Чтобы предоставить максимальную свободу для разработки поистине революционной системы, простота миграции приложений не была одной из основных целей проектирования проекта FS, а должна была быть решена с помощью средств миграции программного обеспечения, принимающих новую архитектуру как данность. В итоге оказалось, что стоимость миграции значительных пользовательских инвестиций в приложения, написанные на COBOL и ассемблере на FS во многих случаях, вероятно, превысит стоимость приобретения новой системы.

Несмотря на то, что проект FS в целом был прекращен, упрощенная версия архитектуры для самой маленькой из трех машин продолжала разрабатываться в Рочестере. В итоге она была выпущена как IBM System/38, которая оказалась удачной разработкой с точки зрения простоты программирования, но ей катастрофически не хватало мощности. Машина AS/400 унаследовала ту же архитектуру, но с улучшенной производительностью. В обеих машинах набор инструкций высокого уровня, генерируемый компиляторами, не интерпретируется, а транслируется в набор инструкций более низкого уровня и выполняется; первоначальный набор инструкций низкого уровня представлял собой CISC-набор с некоторыми сходствами с набором инструкций System/360^[16]. В более поздних машинах набор инструкций низкого уровня представлял собой расширенную версию набора инструкций PowerPC, который развился из разработок RISC IBM 801 Джона Кокка. Специализированная аппаратная платформа была заменена в 2008 году платформой IBM Power Systems под управлением операционной системы IBM i.

Помимо System/38 и AS/400, унаследовавших значительную часть архитектуры Future Systems, отдельные элементы технологии Future Systems были интегрированы в следующие продукты IBM:

• мейнфрейм IBM 3081, который представлял собой топовую модель, разработанную в Покипси, использовавшую микрокод эмулятора System/370, а микрокод FS был удален и использован отдельно
• лазерный принтер 3800 и некоторые машины, которые впоследствии привели к созданию терминала IBM 3279 и GDDM
• автоматическая магнитная ленточная библиотека IBM 3850
• среднеуровневый компьютер IBM 8100, основанный на центральном процессоре Universal Controller (Универсальный контроллер), который изначально предназначался для обработки ввода-вывода в рамках Future Systems.
• усовершенствования сетевых технологий, касающиеся VTAM и NCP

• Архивировано 29 июня 2016 года.
• An internal memo by John F. Sowa. This outlines the technical and organizational problems of the FS project in late 1974.
• Overview of IBM Future Systems