Перезапис асемблера IBM + COBOL в C ++

Я працюю агентом з оренди / менеджером в компанії з прокату автомобілів, яка працює за системою прокату, яка була написана в 1972 році. Я вирішив, що, можливо, настав час для оновлення. Для короткого перегляду, ось короткий приклад безумства, з яким нам доводиться стикатися з цієї програми щодня:

Агент з оренди повинен пам’ятати, що при друкуванні на одному екрані в полі ACT використовується "MXC" (все базується на коротких кодах), що здивовано означає "MaXimum display on the Contract", а на іншому вимагає PR (для PRint) у поле ДІЇ, але декілька екранів використовують Y у полі PT (для PrinT), ще один екран використовує Y у полі PRT (для PRinT), але інший екран вимагає від користувача натискання клавіші enter (але не введення поруч із літери, оскільки це новий символ рядка, він повинен бути введенням на цифровій клавіатурі), а потім F8, інший, але пов'язаний екран вимагає просто F8, на деяких екранах є поле з написом PRT, яке повинно бути для PRinT, але поле фактично нічого не робить, а друк виконується автоматично після проходження декількох підказок, і на інших екранах все ще є поле з написом PRINT Y / N,що шалено за замовчуванням для Y для операцій, в яких в іншому місці вже доставляється папір, і в N для операцій, в яких інший дилер потребує оформлення документів.

Я вирішив, що можу зробити кращу роботу, ніж це, тому вирішив зв’язатися з людиною в компанії, яка буде приймати рішення про оновлення цього. Я врешті-решт потрапляю до ВП ІТ, який відповідає за цією програмою. Я отримую від нього трохи інформації, і я дізнаюся, що моя компанія з прокату автомобілів має свою програму прокату, написану в асемблері IBM mainframe з трохи змішаним COBOL. Він каже, що зараз немає відкритих посад, але я повинен все-таки надішліть йому електронне резюме (на випадок, якщо щось відкриється).

Це призводить мене до моїх запитань.

Перший - технічний. Ідея поліпшити ремонтопридатність у майбутньому, моя думка полягає в тому, щоб переписати її мовою вищого рівня, ніж мовою збірки. Моя сфера досвіду - це C ++, тому це очевидний вибір для мене. Компанія гостро потребує більш легкого способу оновлення програми, тому що я нещодавно прочитав статтю, де чоловік, з яким я говорив, цитує, що команда наполегливо працювала, і вони з гордістю заявляють, що зараз програма підтримує 5 -значити коди локації (замість 4) та 8-значні номери автомобілів (замість 7). Моя філософія щодо оновлень, навіть у таких жахливих ситуаціях, відповідає Джоелу: http://www.joelonsoftware.com/articles/fog0000000069.html Коротше кажучи, переписування повинно бути поступовим, а не викидати все, що було раніше і починаючи свіжим.

Чи є простий спосіб інтегрувати збірку IBM із C ++, і якщо так, то як це зробити? Я чітко знаю ключове слово asm, але не знаю, чи найкраще це використовувати або робити щось інше. Такий план є необдуманим? Більшу частину своєї роботи в Linux я використовую за допомогою g ++ та GNU, тому відповіді, специфічні для цього, вітаються, але, безумовно, не потрібні (оскільки я поняття не маю, якої системи складання у них немає, але я підозрюю, що майже немає).

Друге питання - більш політичне. Як мені слід переконати цю компанію, що їм потрібно зробити перехід? Теоретична економія витрат величезна (виходячи з моїх оцінок, компанія витрачає зайвий мільйон доларів на рік, лише на збільшення витрат на навчання, щоб навчитися взаємодіяти з програмою), але мої запропоновані зміни, ймовірно, поклали б усі нинішні програмісти не працюють, якщо вони будуть прийняті, тому існує великий структурний опір змінам.

редагувати: Я повинен пояснити, чому мені модифікація того, що вже є компанією, здається найкращим рішенням. Я все ще відкритий до інших пропозицій, тому що це чудовисько програми. У мене ніколи не було роботи з програмування, тому, будь ласка, виправте мене щодо будь-якого неправильного аналізу, який я міг би дати.

По-перше, є рішення, що не є на полиці.

З моїх розмов з кількома менеджерами середнього рівня про подібні речі, однією з головних проблем при переході на нову систему є велика кількість лояльних співробітників, які вже десятиліттями працюють з компанією і дотепер комфортно працюють із системою. . Якщо у мене є можливість змінювати те, що ми маємо, я можу підтримувати поточний інтерфейс у вигляді «режиму сумісності». Користувачі вже мають увійти, щоб користуватися поточною системою, тому я можу додати можливість активувати налаштування, коли користувачі входять у перший раз (після внесення цієї зміни), де їм надається можливість використовувати або "класичний" інтерфейс або "новий" інтерфейс. Ні в якому разі я не знайду рішення про те, що це дозволяє,

Моя компанія також володіє програмним забезпеченням, яке ми використовуємо; ми не ліцензуємо це. Це означає, що керівництво, з яким я зараз говорю, - це ті самі люди, які насправді могли б дозволити мені внести зміни. Завдяки сторонній рішенню, я маю отримати схвалення від своєї компанії на додаток до забезпечення будь-яких прав, необхідних від компанії, яка розробила продукт, який ми використовуємо, що додає додаткових перешкод. Це також зажадає переконати компанію відмовитися від "свого" продукту і взяти якийсь інший товар, що здається більшим перешкодою, ніж спроба оновити те, що ми маємо, але я цілком можу помилитися з цього питання.

Нарешті, дивлячись у майбутнє, я не просто хочу вдосконалити інтерфейс користувача та виправити кілька помилок. Після того як я оновив ці "нагальні" проблеми, я сподівався оновити фундаментальний спосіб роботи компанії, пов'язаний з технологією. Провівши 1-2 роки на подібні питання, мій план полягав у тому, щоб повернутися до управління та запропонувати більш кардинальні зміни. Існує багато способів управління компанією, які можуть бути кардинально покращені за допомогою технології, яку вони просто зараз не використовують. Наприклад, кожен регіон працює майже однаково. Місцевий головний аеропорт є центральним вузлом для розповсюдження автомобілів. Вони в основному надсилаються за потребою. Однак аеропорт використовується як домашня база для всіх операцій. Вони відправлять двох людей в одному автомобілі до мого місця, щоб забрати одну машину у нас, яка нам не потрібна, потім повертайтеся до аеропорту з машиною, в яку вони приїхали, плюс те, що вони забирають назад (ми в 32 милях від аеропорту). Тоді вони приїдуть до місця в 5 милях від нас у двох автомобілях, щоб скинути одну з них, а потім повернутися в іншому автомобілі до аеропорту. Вони роблять це навіть у тому випадку, якщо машина, яку ми відправили назад, - це той самий автомобіль, який вони потребують біля нас. Я працюю з компанією вже близько двох років, і мені здається, що вони відхиляються від цього в самих надзвичайних надзвичайних ситуаціях з дефіцитом автомобілів (так приблизно втричі). Я б замінив чотирьох людей, що працюють у кожному регіоні, на автоматизовану систему планування, яка визначає, які машини їдуть куди, і спробуйте знайти шлях, який потребує найменшої кількості часу + миль + водіїв, щоб доставити всі машини там, де вони повинні бути, як Приклад виправлень вищого рівня, я сподіваюся, що колись додам.

Однак, перш ніж мені було б зручно пропонувати все це, я вважаю, що було б корисно отримати опору в компанії та базу коду, виконуючи менші завдання, як-от оновлення інтерфейсу. Такі рішення, як аутсорсинг або іншим чином, усунуть цю можливість.

Обмежуючись технічним фронтом ...

Я пропоную вам почати з визначення середовища, в якому працює програма. "Mainframe" може означати кілька різних речей, враховуючи вік програми, це може бути CICS або IMS . Можливо також, що оригінальні автори написали власне розпочате завдання.

Залежно від того, де працює програма, вона, швидше за все, використовуватиме API для цього середовища, зараз CICS використовує інтерфейс, помітно відрізняється від своїх перших днів, я не можу говорити за IMS. Якщо додаток - це власне розпочате завдання, то, можливо, він може мати власний внутрішній API - я витрачаю десь сім років на підтримку такого звіра, написаного в ту саму епоху.

Інше, що слід врахувати, враховуючи вік програми, полягає в тому, що Асемблер, з яким ви хочете інтегрувати C ++, передує існуванню Мовного середовища (LE). Таким чином, якщо Ассемблер не було оновлено на відповідність LE, у вас виникнуть певні труднощі, оскільки C і C ++ сумісні з LE і вимагати, щоб їхні абоненти та позиції також відповідали.

Ще один момент, який слід врахувати, якщо ця програма працює на основній системі, що перебуває у стані спокою, можливо, ви намагаєтеся інтегруватись із додатком, який працює на непідтримуваному апаратному та програмному забезпеченні. Це було б не на відміну від спроб інтеграції із додатком, написаним у 1989 році, який працює на DOS 4.01 на своєму оригінальному апаратному забезпеченні.

Ти стрибаєш пістолет. З вашого опису виглядає, що ви не повністю зрозуміли поточне технічне середовище (яка саме ОС, де і як зберігаються дані, чи існують інтерфейси для інших систем тощо). Але ще важливіше: серйозний план повинен розглянути альтернативи частковому або повного перезапису програмного забезпечення, а саме позапрограмного забезпечення, перенасичення перезапису, програмного забезпечення як послуги тощо.

Яким би способом компанія нарешті не пішла, спочатку потрібен ґрунтовний аналіз того, що робить програмне забезпечення сьогодні та які вимоги до нового рішення.

То чому б вам не запропонувати зробити цей аналіз?

Я здивований, що ти отримав таку ввічливу відповідь!

Давайте розглянемо це з їх точки зору.

Вони успішно керують тридцятирічною системою, мабуть, сотнями тисяч рядків коду, інтерфейсом для, можливо, двадцяти інших систем, що втілює бізнес-процеси, що розвивалися протягом сорока років.

Вони, мабуть, / сподіваємось, є експертами у своїй галузі, і, як такий, вважають C ++ відступ від IBM "Мова високого рівня асемблера", щоб дати їй повну назву. Мова асемблера IBMs надзвичайно потужна, а мова "MACRO" - найкраща реалізація мови попередньої обробки / шаблонів.

Була б пропозиція замінити їх систему приблизно кожні п’ять років з моменту її впровадження. Деякі були б відхилені після дослідження техніко-економічного обґрунтування, деякі зайшли до стадії проектування, перш ніж вони втратили там бюджет, деякі, можливо, навіть потрапили до коду і, можливо, етапу тестування, перш ніж потраплять у проблеми з роботою та отримати консерви.

C ++ просто не допоможе. У середовищі, де працює програма, немає графічної бібліотеки. (Існує 3270 графічна бібліотека, але її навряд чи можна підтримувати в C ++, оскільки ніхто не використовує її, і, існує повна "X" клієнтська бібліотека, але для її використання вам потрібно бути в іншому середовищі.)

У них є інтерфейс користувача, який далеко не ідеальний, але добре відомий і швидкий. Досвідчений оператор заповнить форму приблизно в три рази швидше, використовуючи зелений екран, а не еквівалентний графічний інтерфейс. Крім того, вони можуть звернути увагу на клієнта, коли вони торкаються типу.

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

У мене була аналогічна проблема кілька років тому в BellSouth. Я просто написав код COBOL для сканування байтових програм мови асемблера, байт, відокремлення опкодів та операндів, перетворення інструкцій гілок для переходу до точок та перетворення інструкцій порівняння в ІФ. Ця програма перетворила інструкції постійного струму в еквівалентний код відділу даних COBOL та перетворила ходи, запси та ін.

Як тільки це було зроблено, я написав другу програму для перетворення IF та GOTO в IF-THEN, з переміщеннями і подібними в рядках між цими кластерами (це насправді не все так складно зробити - секрет полягає в тому, щоб вставити IF і ELSEs, коли ви перечитуєте коду з "підгіном" 1-ї фази ззаду наперед).

IF-THEN-ELSER шукав ситуації, коли він знайшов посилання GOTO в безпосередній близькості до мітки, яку можна було б безпечно видалити (зменшивши кількість її посилань на 1). Ви запускаєте цю програму IF-THEN-ELSER повторно (тобто ви запускаєте її знову і знову, зупиняючись лише тоді, коли ваш останній пропуск не може знайти способу змінити більше). Більшість найважливіших робіт виконується цим "епілятором", чий продукт COBOL повинен ретельно переглядати та перевіряти досвідчений, компетентний програміст на мові асемблера (а саме я). З мого досвіду, мій "якщо-то-ельзер" зміг усунути більше 90 відсотків ПЗ, що випливають з оригінальних інструкцій галузей.

Я припускаю, що з цього моменту можна рухатись вперед шляхом прямого перетворення на C (або C ++) - мови, з якими я також розмовляю. Однак у BellSouth нашою цільовою мовою вибору була COBOL / II. Завжди є деяка складність, яка виникає в ситуаціях, коли на решті мітки є кілька посилань GO TO (багато разів ці ситуації обробляються COBOL PERFORMs, але іноді можуть бути просто представлені конструкціями OR і AND).

Я думаю, що приємно створювати код у елегантно структурованому блоці COBOL / II, з ОЦІНЮВАННЯ (конструкти випадків) та назви умов 88 рівнів. Додавання цих завершальних штрихів призвело до появи ще однієї пари програм, що виявилося зручним для програм COBOL, що не походять з програм, перетворених з асемблера.

Я не знаю, чи це допомагає.

Як зауважили інші, ви повинні ретельно проводити цей процес. Це допомагає мати 10-12 років досвіду кодування асемблера, що інформує ваші процеси прийняття рішень. Нам, хто має такий досвід, важко знайти більше.

Як остаточне зауваження: ми писали в ассемблері ще тоді, оскільки компілятори для мов високого рівня створювали громіздкий, неефективний об'єктний код. Сьогоднішні «оптимізуючі» компілятори COBOL не мають таких самих поганих звичок. ----------

Порада Джоела, як правило, слушна, але в цьому випадку повна перезапис прострочена. В ідеалі перепишіть биткою, тому що ви тут маєте справу - це монстр.

Я не впевнений, що саме додати, оскільки ви вже зробили досить хороший аргумент для цього переписування. Моя єдина рекомендація - повністю пропустити C ++ та перейти безпосередньо до веб-інтерфейсу для системи оренди, оскільки це, мабуть, буде ще простішим для навчання працівників, і заощадить вам багато роботи над інтерфейсом (а також зробити набагато простіше отримати нову кров у проекті, а то й просто передати всю аутсорсинг).

Що стосується існуючих програмістів COBOL - можливо, вони можуть допомогти як із документуванням існуючої системи, так і з процесом міграції.

Що стосується технічного аспекту, то багато залежить від якості - модульності коду асемблера. Деякі програмісти розуміли важливість створення модулів із конкретною, обмеженою функцією та чітким, простим параметризованим інтерфейсом, використовуючи стандартні умови підключення підпрограми IBM. Однак переважна більшість прагнула створити монолітні жахливості.

З першим можливе повторне використання, і це не повинно бути важко розробити "клей" між C ++ та асемблером, якщо ваші модулі асемблера використовують стандартні (або принаймні послідовні) послідовності виклику. Однак, швидше за все, код асемблера буде безлад. Хоча це було можливо для запису структурованого асемблера, дуже мало хто зробив, і це буде майже неможливо виділити якийсь - або «дизайн» , з якою початку копіювання.

З іншого боку, асемблер 360/370 досить високого рівня в порівнянні з сьогоднішніми мікропроцесорами, і набагато простіший, і C іноді вважається "асемблером високого рівня". Я працював у компанії СУБД, продуктом якої був повністю асемблер 370, і наш головний архітектор вважав, що можливо перекласти код асемблера в машину на C (для подальшої мобільності). Я скептично налаштований, але справа в тому, що відстань не така велика, як ви могли б подумати.

Не знаю, чи корисне щось із цього. Як я кажу, я думаю, що це сильно залежить від якості та розміру оригінального коду.

Я не можу сказати, чи це жарт чи ні - ваша компанія серйозно працює з кодом, спочатку написаним 39 років тому? Якщо він працює на System / 360, вам доведеться компілювати g ++ з джерела ...

Чесно кажучи, я б навіть не думав про використання будь-якого старого коду; вам потрібно по-новому підійти, сісти і подумати, що потрібно зайти в дизайн, і зробити це з нуля. Так, це потребуватиме неабиякого планування, але я не думаю, що навіть Джоел сказав, що це стосується поступових змін.

Що стосується переконання компанії в тому, що вам потрібно перейти, вам потрібно вказати на конкретні причини, які підвищуватимуть ефективність, призводять до зниження витрат та / або показують, що те, що ви зараз використовуєте, наносить певний шкоду прямому підсумку.

Ще один коментар - я думаю, що інші компанії з прокату автомобілів приєдналися до решти нас у 21 столітті; Я хотів би трохи переосмислитись, щоб побачити, як вони це роблять (на веб-основі, я думаю,) і, можливо, моделюю його після однієї з цих систем (тобто не заново вигадуйте колесо).

Удачі!

Теоретично не повинно бути переконати вище керівництво замінити стару систему, якщо ви зможете їх показати, це дозволить заощадити їх мегабукси. І буде. Знайти програмістів для підтримки цієї системи стає все складніше, і ці програмісти будуть дорожчати. Це не питання "якщо", це питання "коли". Це дійсно має бути оновлено.

Однак питання полягає в тому, чи можете ви переконати їх не просто в тому, що воно потребує оновлення (і вони, напевно, це знають у будь-якому випадку), а в тому, що це повинен бути власний проект. Особливо, якщо команда - тільки ти. Досить часто така основна заміна піддається аутсорсингу. Можливо, навіть є якесь позапрограмне забезпечення, доступне для розгляду. Ці варіанти потрібно вивчити, і ваші менеджери наполягатимуть, що це станеться, якщо вони є розумними.

Щодо завдання, якби ви його виконали, я фактично вважаю, що переписання бульдозу може бути доречним у цьому випадку. Аргумент Джоеля застосовується не в кожному випадку. Однак я не міг насправді знати, не побачивши цього.

1. Про додаткові зміни не йдеться.

2. Ймовірно, є доступне рішення, що не продається. Є багато підприємств з прокату автомобілів.

3. Якщо в крайньому випадку вам потрібно це переписати, спочатку витратьте деякий час на роздуми про те, як буде працювати нова система.
   Визначивши функціональність та інтерфейси, ви можете вибрати інструменти розробки, які найкраще відповідають потребам (та вашим навичкам).

Однією з стратегій мінімізації стресу для кінцевих користувачів є початок емуляції старого потворного інтерфейсу, який користувачі знають, з кількома приємностями, такими як випадаючі списки для некрасивих мнемоніків, а потім поступово додавати функціональність інтерфейсу та відлучати їх до сучасного інтерфейсу.

Напевно, ви не хочете зберігати один і той же формат файлу даних, тому після їх перемикання назад не буде.