Переход с VMS на Unix

1. Первый вопрос, который мне нужно задать, это почему, и я бы вел разговор в направлении «Вам действительно нужно перенести это с VMS». Есть ряд вещей, которые стоит упомянуть о VMS:

   -> VMS по-прежнему активно разрабатывается и поддерживается HP. На прошлой неделе они выпустили V8.4 для полевых испытаний (см. http://h71000.www7.hp.com/openvmsft/).

   -> VMS доступна на новом оборудовании; в частности, серверы HP Integrity на базе процессора Itanium.

   -> VMS также доступна на виртуальных платформах через продукты Charon Emulation.

   -> По общепринятым оценкам, сегодня активно используется около 300 000 систем VMS. LMS может быть последним человеком в LargeCo, но он далеко не последний человек в мире.

   -> Много информации, см., например, openvms.org, чтобы увидеть много текущей информации о VMS, все от текущих пользователей.

2. ОК, вы все еще хотите перенести VMS. Как ты делаешь это? Ну, это зависит от многих вещей.

   -> Как уже говорили другие, насколько стандартен код? Скорее всего, не очень. Чем больше VMS-измов, тем сложнее работа. 'достаточно.

   -> Что такое база данных? Если это Oracle, вероятно, не так уж сложно перейти на Oracle на какой-либо другой платформе. Если это какая-то пользовательская БД, основанная на индексных файлах RMS, то вам нужно проделать больше работы, вам нужно будет воссоздать эту псевдо БД или достаточно понять ее, чтобы заменить ее какой-либо реляционной БД.

   -> Кроме C, что еще используется для создания приложения? Что на передке? DECforms? ФМС? Есть ли механизм транзакций, например. ACMS? РТР? Эти вещи окажут огромное влияние на осуществимость и усилия, необходимые для переноса на UNIX.

   -> Какие другие продукты участвуют? Используются ли сторонние библиотеки? Используются ли сторонние продукты, критически важные для приложения или функциональности?

   -> Является ли эта система кластерной? Если да, то почему? Вы должны будете достигнуть тех же самых целей с коробкой UNIX.

   -> Есть компании, которые помогут вам это сделать, и утверждают, что у них есть инструменты, облегчающие эту задачу, но мой опыт показывает, что эти компании, как правило, продают вам больше услуг, чем товаров (т. е. вам нужно нанять их, чтобы использовать инструменты. Это будет дорого).

3. Книга UNIX для пользователей OpenVMS поможет начинающим пользователям VMS в понимании VMS, но, как следует из названия, книга на самом деле предназначена для противоположной цели.

Все, что написано на VMS, использует множество специфичных для VMS вещей, это было так удобно.

Есть несколько компаний, которые продают библиотеки совместимости, чтобы упростить перенос - они не будут дешевыми, хотя VMS, как правило, используется там, где надежность важнее стоимости.

Другой вариант — запустить openVMS на каком-нибудь современном оборудовании, возможно, на виртуальной машине.

Я уверен, что Брайан уже принял решение, но из-за моих грехов многолетней работы в языковой поддержке DEC OpenVMS (да, некоторые люди имели эту сомнительную честь) настоящий вопрос, который я бы задал такому клиенту, как Брайан, таков: это приложение реального времени или нет? Если это первое, то оно будет сильно зависеть от многих системных служб VMS, которые исключат «порт» и укажут на перезапись. Если бы это было последнее, то частота системных служб VMS должна (возможно) быть ограничена и сделать порт жизнеспособным.

Серьезным испытанием для меня будет поиск *.c "SYS$", "LIB$", т.е. поиск во всех исходных файлах C тегов "SYS$" и "LIB$", которые предшествуют системным службам VMS. Если их количество составляет 10, то порт, вероятно, вероятен, от 10 до 100 делает его вполне вероятным, но более 100 делает успешный порт маловероятным.

Надеюсь это поможет

У вас есть несколько вариантов.

1. Получите исходный код OpenVMS и продолжайте поддерживать Open VMS, как если бы это был дистрибутив Linux. Некоторые люди не против идти в ногу с дистрибутивами Linux и дистрибутивами OpenVMS. Это может быть сделано.

2. Попробуйте перекомпилировать VMS C в Linux. Это может быть тривиально, если C использует только стандартные библиотеки. Это может быть очень и очень сложно, если C использует много библиотек VMS.

   Когда у вас под рукой будут факты, вы сможете пересмотреть свой образ действий. Поскольку вы не перечислили кучу методов библиотеки VMS, которые использует эта программа, невозможно сказать, насколько она запутана с ОС.

   Это может быть тривиально или невозможно. Трудно сказать без анализа источника.

3. Напишите промежуточные библиотеки из VMS в Linux. Если ваша программа выполняет только несколько функций VMS, это не очень сложно. Если ваша программа выполняет обширные функции VMS, это сумасшествие.

   Мост — в конце концов — ужасная идея. Однако менеджерам это нравится.

   Альтернативой является замена вызовов библиотеки VMS надлежащими переносимыми вызовами Linux, а не мостами записи. Это лучше в долгосрочной перспективе, потому что исключает непереносимые функции программы.

4. Перепишите его с нуля на Python. Обычно это проще, чем пытаться портировать код C. Он будет короче, чище, проще и портативнее.

Если вы хотите продолжать использовать VMS на виртуальной машине, вы можете заглянуть в CHARON-VAX ( http://www.charon-vax.com/). Как упоминалось ранее, простота переноса действительно во многом зависит от того, сколько расширений VMS было использовано; поиск в исходном коде символов $, встроенных в строки (обычно с 3-символьной начальной подстрокой, такой как lib$gettime или dsc$descriptor или sys$foobar и т. д.), даст вам хотя бы базовое представление о том, как называются системные функции VMS. и насколько вероятно, что они будут переносимыми, если имя достаточно очевидно.

Если не сломалось, не чини! Зачем портировать или переносить приложение, если в этом нет необходимости? Почему бы не запустить его на текущей установке OpenVMS, работающей на сервере HP Itanium; это предполагает, что вы хотите обновить оборудование, что может даже не понадобиться, если ваше оборудование VAX все еще работает.

Чтобы выучить C, вы могли бы просто перетащить его изо рта: «Язык программирования C» его изобретателей, Кернигана и Ритчи.

Я могу порекомендовать «Среду программирования UNIX» (снова) Брайана Кернигана; более авторитетного источника вы вряд ли найдете, и он одновременно учит вас идиомам Unix/C и немного программированию на C.

Для более глубокого и подробного ознакомления с C мне очень понравилась книга Питера ван дер Линдена: "Экспертное программирование на C - секреты глубокого C".

Вы также захотите бороться с LMS за библиотечную документацию функций C, специфичных для VMS, с (конечно) особым акцентом на те, которые фактически используются в приложении. Вот где будут ваши усилия по портированию.

Работа может быть легкой или сложной, в зависимости от того, насколько специфичны для конкретной машины хитрости и манипуляции с битами, а также от того, сколько системных вызовов, специфичных для VMS, используется. Было бы очень хорошо, если бы размер слова был одинаковым (другими словами, если ваш VMS имеет размер слова 32 бита, не запускайте код на 64-битной версии Unix!)

Брайан, я не уверен, что LMS указал/позаботился о переносе C-кода или ВСЕХ процессах. Как слишком часто люди думают о языках вне системы.

Если был процесс, построенный на VMS, скорее всего, он использовал, по крайней мере, средства планирования/пакетной обработки, которые часто написаны на DCL (довольно простой и понятный язык, в отличие от сценариев оболочки или perl).

Таким образом, стоимость переноса всего процесса может быть выше, чем первоначально воспринималась вашей LMS. Добавьте сюда аспект надежности, учитывая ваши хрусты с C, в чем нет ничего невозможного, конечно, с энтузиазмом и решимостью.

Если вы хотите просто попробовать C-код, как было опубликовано ранее, найдите в нем совпадения "$". Или просто скопируйте его со всеми присутствующими заголовками, основ команды compile-link должно быть достаточно.

С другой стороны, это выглядит как призыв консультанта, поскольку действительно таких рабочих мест во время «исхода» было предостаточно. Все сказанное VMS остается довольно надежной платформой (24x7 - это норма!), Если только аппаратное обеспечение не умрет, тогда еще есть тонны "исходных" запасных частей. УДАЧИ!

Примерно через полтора года, возможно, вы уже поняли, что делать. Моя организация недавно решила придерживаться OpenVMS вместо перехода на Linux, несмотря на то, что старая гвардия недавно ушла. Мы просто не могли спорить с тем, что мы считали очень стабильной и надежной системой. В настоящее время мы переходим с серверов Alpha на серверы Integrity по причинам окончания срока службы. HP очень помогла нам с переходом.

Если на то пошло, могут быть поставщики Linux, которые могут помочь с переходом. Спросите у вашего нового поставщика оборудования, есть ли у него какие-либо рекомендации.

В зависимости от того, какие языки вы уже знаете, C не так уж сложно выучить. Я сам выучил C в ходе изучения C++ после того, как окончательно оторвался от Pascal. (VAX Pascal, плюс Rdb/VMS, плюс DCL образовали комбинацию, которую было трудно превзойти.)

Если программа написана на типичном C, вы потратите больше времени на изучение библиотечных функций, чем на изучение языка.

Это довольно легкий материал, но я просмотрел онлайн-учебники по C++, которые Microsoft предоставляет вместе с экспресс-выпуском Visual Studio для C++.

Вот учебник для начинающих:

http://msdn.microsoft.com/en-us/beginner/cc305129.aspx

Вероятно, стоит приложить усилия, чтобы спросить, почему LMS хочет перенести приложение на Unix. Ответ может показаться очевидным, но правильное изучение причин имеет свои преимущества. Я бы предположил:

1. OpenVMS является «ультра устаревшей платформой», и только по этой причине больше не стоит запускать приложение;
2. В наши дни трудно найти любого, кто готов поддерживать приложение, работающее на OpenVMS;
3. Аппаратное обеспечение, на котором работает OpenVMS, угрожает стать умирающий.

У нас похожая проблема, но в нашем случае рассматриваемое приложение не только работает на OpenVMS, но и написано на COBOL. Я должен сказать, что ваша ситуация радужна по сравнению с тем, что ваше приложение написано на кросс-платформенном языке.

В любом случае, я думаю, что если вы собираетесь принять важное решение, такое как переход с OpenVMS на Unix, было бы благоразумно проявить некоторую должную осмотрительность. В вашем случае попытайтесь оценить, насколько переносим код — только тогда вы узнаете, каков масштаб усилий (в худшем случае вполне может быть кратно лучшему). В C переносимость кода в основном зависит от зависимостей — являются ли они «стандартными» или специфичными для VMS?

Наши запросы показали, что HP будет поддерживать OpenVMS на Itanium по крайней мере до 2022 года. Нет необходимости торопиться с переходом на другую платформу — возможно, вы могли бы оставить все на OpenVMS, пока приступите к подготовке приложения к переносу (сделайте это меньше зависит от специфики OpenVMS).

У VMS удивительно здоровое сообщество, и если проблема заключается в отсутствии Unix, то, возможно, GNV поможет преодолеть зазор?

Ну у вас есть несколько вариантов. если этот код нужно портировать довольно быстро, я бы написал библиотеку моста для эмуляции библиотек vms. когда вы вернете его и запустите на * nix, замените вызовы библиотеки vms собственными/переносимыми вызовами для * nix.

Кроме того, если в коде много оптимизаций, т.е. встроенная сборка и битовая перестановка. тогда вам придется переписать этот код, что потребует понимания арки VAX. также. обязательно проверьте разницу в размере слов и различия в порядке следования байтов