Minden nagygépes átállás azzal kezdődik, hogy valaki rákeres a mainframe migrációs eszközökre, és a bemutató, ami ezután következik, meglepően meggyőző. Néhány ezer sor COBOL megy be, olvasható Java jön ki, a tesztkészlet lefut, a diasor pedig hetven vagy nyolcvan százalékos automatizálást ígér. A bemutató általában őszinte. Csak épp általában olyan kódon fut, amely semmiben nem hasonlít az Önére.

Ez az útmutató azokat az eszközkategóriákat írja le, amelyek valóban léteznek, azt, hogy mindegyik miben igazán jó, és azokat a konkrét pontokat, ahol mindegyik hajlamos elbukni valódi terhelésen. Azoknak szól, akiknek alá kell írniuk az üzleti indoklást, nem a szállító szervezeten belüli szószólójának.

Az őszinte álláspont: a mainframe migrációs eszközök rengeteg hasznos munkát elvégeznek, különösen az elemzésben, az adatmozgatásban és a gépies fordításban. Amire nem képesek, az az üzleti szabályok megértése. Az automatizált konverzió megbízhatóan olyan kódot állít elő, amely fut; nem olyat, amelyet a csapata karban akar majd tartani, és ennek a szakadéknak a betemetése viszi el a költségvetés nagy részét.

A mainframe migrációs eszközök négy kategóriája

A piac zsúfoltnak tűnik, amíg aszerint nem rendezi, hogy a termékek valójában mit csinálnak. Szinte minden besorolható négy csoport egyikébe, és egy valódi program legalább háromból használ eszközt.

A feltáró és elemző eszközök beolvassák a forráskódállományt, és megmondják, mije van. Elemzik a COBOL-t, a JCL-t, a copybookokat és az adatbázis-definíciókat, majd hívási gráfokat, adatszármaztatási térképeket és függőségi fákat építenek. Ez a legkevésbé látványos és a legkövetkezetesebben értékes kategória, mert a szervezetben senkinek sincs teljes képe egy olyan rendszerről, amely negyven éve rakódik egymásra.

A rehosting- és emulációs platformok lehetővé teszik, hogy a lefordított nagygépes terhelés szabványos hardveren vagy felhőpéldányokon fusson. A COBOL COBOL marad, a JCL JCL marad, egy kompatibilitási réteg pedig biztosítja azokat a futásidejű szolgáltatásokat, amelyeket korábban a nagygép nyújtott.

Az automatizált fordítóeszközök COBOL forráskódot alakítanak Javára, C#-ra vagy más modern célnyelvre. Ez az a kategória, amelyért a vásárlók a leginkább lelkesednek, és amely a leggyakrabban okoz csalódást, az alább kifejtett okokból.

Az adatmigrációs eszközök magukat az adatokat mozgatják: VSAM-fájlokat, szekvenciális adatállományokat és DB2-táblákat relációs vagy felhőnatív tárolóba. Kezelik a karakterkészlet-konverziót, a pakolt decimális mezőket és azokat a rekordszerkezeteket, amelyeket az általános célú ETL-termékek egyszerűen nem tudnak értelmezni.

A nagy felhőszolgáltatók mindegyike több ilyet csomagol egybe, a szakosodott gyártók pedig az elmúlt években erősen konszolidálódtak felvásárlásokkal. Mielőtt többéves támogatási szerződést írna alá, nézze meg, kié jelenleg a termék, és mennyire elkötelezett az útiterve, mert ezen a piacon a tulajdonos gyakrabban változik, mint a technológia.

Amit az elemzőeszközök tényleg jól csinálnak

Ha csak egy kategóriát vásárol meg, ezt vegye. A feltáró eszközök olyan kérdésekre válaszolnak, amelyekhez egy külsős csapatnak különben több hónapnyi kézi munka kellene.

Egy jó elemzőtermék megmondja, mely programokat hívják valóban élesben és melyek halottak egy évtizede, hogyan folyik az adat egy képernyőmezőből fél tucat programon át egy DB2-táblába, mely copybookok osztottak az alrendszerek között, és hol lakik a valóban veszélyes kód. Ez az utolsó eredmény az, ami terveket ír át. Minden nagygépes állományban van néhány program, amelytől minden más függ, és ritkán azok, amelyekre az üzlet gondol.

A korlát az értelmezés. Egy negyvenezer csomópontos függőségi gráf adathalmaz, nem belátás. Valakinek akkor is végig kell néznie a kimenetet, üzleti képességekbe kell csoportosítania, és el kell döntenie, mi költözik először. Azok az eszközök, amelyek az üzleti szabályok automatikus levezetését ígérik, inkább a kód körülírását adják, mint a szándék leírását, és a kettő pontosan ott tér el, ahol a kódban olyan hiba van, amelyhez az üzlet csendben hozzáidomult.

Az elemzést még azelőtt futtassa le, hogy elkötelezné magát egy megközelítés mellett. A mainframe-modernizációs stratégiáról szóló útmutatónk végigveszi, hogyan kellene ezeknek a megállapításoknak alakítaniuk a rewrite, refactor vagy replatform döntést.

Rehosting platformok: gyors, valódi, és nem modernizáció

A rehosting a legkiszámíthatóbb elérhető opció, és épp ezért adják el rendre alulértékelve.

Az ajánlat egyszerű. A COBOL-t olyan platformon fordítják újra vagy értelmezik, amely emulálja a nagygép futásidejű szolgáltatásait, így a tranzakciófeldolgozás, a kötegelt ütemezés, a fájlkezelés és a jobvezérlés ugyanúgy viselkedik, mint korábban. Mivel a forrás alig változik, a tesztelési teher jóval kisebb, mint bármely más úton, és a projektek hónapok, nem évek alatt zárulnak.

A megtakarítás valós, és a hardver- és licencmodellből származik, nem a szoftverből. A szervezetek gyakran számolnak be az éves üzemeltetési költségek jelentős csökkenéséről, miután elhagyták a fizikai nagygépet, és ez sokszor elég a munka következő szakaszának finanszírozására.

Amit a rehosting nem old meg, az éppen az, amiért a legtöbb vezetőség jóváhagyja ezeket a programokat. Egy sikeres rehost után továbbra is COBOL kódbázisa van, továbbra is COBOL-fejlesztőkre van szüksége, és a felvételi esélyei nem javultak. Az alkalmazáson semmi nem lett könnyebben módosítható. A rehosting időt és pénzt vásárol, aminek valódi értéke van, de tisztességesen platformváltásként kell megnevezni, nem modernizációként.

Új függőséget is behoz. Az IBM futtatókörnyezetét egy szállító kompatibilitási rétegére cserélte, és az éles rendszere mostantól attól függ, hogy ez a szállító továbbra is támogatja-e. Tekintve, mennyit konszolidálódik ez a piac, ezt a kockázatot érdemes beleírni az üzleti indoklásba.

Automatizált fordítás: itt lakik az igazi baj

Az automatizált COBOL-konverzió működik. Nem ez a probléma. A probléma az, hogy hogyan néz ki a kimenet, és mibe kerül együtt élni vele.

A fordítómotorok általában hűségesek. Megőrzik a viselkedést, köztük azt is, amit senki nem szánt oda, mert a hűség az egyetlen védhető tervezési cél. Egy eszköz nem tudhatja, hogy egy díjszámításban lévő kerekítési furcsaság olyan hiba, amelyet az aktuáriusok 1997 óta kompenzálnak, ezért pontosan reprodukálja. Ez a helyes döntés, és azt jelenti, hogy az új Java rendszer örökli a régi minden felhalmozott furcsaságát.

A kimenetet a bemenet is formálja. Az a COBOL, amely GOTO-láncokból, átfutó PERFORM THRU szerkezetekből, ALTER utasításokból és több irányból belépett bekezdésekből áll, nem bomlik tiszta metódusokra, mert nincs benne tiszta felbontás. Ami kijön, az olyan Java vagy C#, amely a COBOL vezérlési folyamát követi, a COBOL változóneveit használja, és gyakran nehezebben olvasható, mint az eredeti. A szakmában JOBOL-nak hívják, és teljesen lehetséges sikeresen befejezni egy migrációt úgy, hogy a végén olyan kódbázis marad, amelyet egyik nyelven sem tud senki karbantartani.

Néhány konkrét nyelvi szerkezet aránytalanul sok fájdalmat okoz, és érdemes korán rákeresni, mert ezek hajtják a kézi ráfordítás becslését.

Az öt szerkezet, amely a kézi munkát hajtja

A pakolt decimális aritmetika az első. A COBOL COMP-3 mezői és fixpontos decimális szemantikája nem képezhető le lebegőpontosra, és bármely eszköz, amely mégis engedi, olyan pénzügyi eredményeket ad, amelyek a negyedik tizedesjegyen eltérnek a nagygépétől. A helyes konverzió tetszőleges pontosságú decimális típusokat használ, amelyek lassabbak, és amelyeket minden számítási útvonalon következetesen alkalmazni kell.

A karakterkódolás a második. Az EBCDIC-ről ASCII-ra váltás gépies, a rendezési sorrend viszont nem ugyanaz, így minden megváltozhat, ami a sorrendtől függ. A riportok más sorrendben állnak elő, a tartományellenőrzések másképp viselkednek, a kulcsösszehasonlítások pedig olyan eredményt adnak, amely az új rendszerben helyes, a régihez mérve viszont hibás.

A REDEFINES és a változatos rekordok a harmadik. Egyetlen tárterület, amelyet többféleképpen értelmeznek, erősen típusos nyelvben nem rendelkezik természetes megfelelővel. A generált kód jellemzően bájttömb-műveleteket állít elő, hozzáférő metódusokba csomagolva, ami működik, és rendkívül kellemetlen karbantartani.

A tranzakciós szemantika a negyedik. A CICS pszeudokonverzációs programozása, ahol az állapot a képernyő-interakciók között egy kommunikációs területen utazik, semmilyen modern web- vagy szolgáltatásmintának nem felel meg. Emulálni furcsa eredményt ad; rendesen újratervezni a megjelenítési réteg újraírását jelenti.

Az Assembly rutinok az ötödikek, és őket becsülik alá a legmegbízhatóbban. Szinte minden hosszú életű állomány tartalmaz néhány Assembly modult, amelyeket rendszerint valaki írt, aki évekkel ezelőtt nyugdíjba ment, és amelyek valami teljesítménykritikusat vagy platformspecifikusat csinálnak. Ezeket egyetlen eszköz sem konvertálja. Kézzel írják újra, a megfigyelt viselkedésből, tesztek alatt.

Ha célnyelvek között mérlegel, a COBOL-ról Javára migrálás és a COBOL-ról C#-ra migrálás részletes útmutatóink bemutatják, hogyan csapódnak le ezek a szerkezetek az egyes ökoszisztémákban.

Adatmigrációs eszközök és a részletek, amelyek harapnak

Az adatmozgatás kevesebb figyelmet kap, mint a kódkonverzió, és legalább annyi csúszást okoz.

A szakosodott eszközök itt kiérdemlik a helyüket, mert a nagygépes adatformátumok valóban kényelmetlenek. Ismerik a copybook-elrendezéseket, a pakolt és zónázott decimális mezőket, az előjel-átütéseket, az OCCURS DEPENDING ON záradékokat, és azt a tényt, hogy egyetlen VSAM-fájl több különböző rekordtípust is tartalmazhat, amelyeket a tizenkettedik pozícióban lévő bájt különböztet meg. Az általános célú ETL-termékek ezt nem ismerik, és azok a csapatok, amelyek mégis rájuk erőltetik, rendszerint ugyanennek a képességnek egy rosszabb változatát építik újra.

A nehezebb probléma nem technikai, hanem jelentésbeli. A nagygépes fájlok gyakran úgy kódolnak jelentést, ahogy azt egy relációs séma közvetlenül nem tudja kifejezni: újrahasznosított kitöltőmezők, hatjegyű egészként tárolt dátumok ablakozási szabállyal, státuszjelzők, amelyek érvényes értékei egy programban és nem egy kódtáblában élnek, és duplikált kulcsok, amelyeket az alkalmazás eltűr. Eldönteni, hogy ezekből mi legyen a célsémában, elemzői munka, és nem automatizálható, mert a válaszok csak emberek fejében léteznek.

Az egyeztetéssel kezdettől számoljon. Minden migrált adatállományhoz kellenek rekordszámok, kontrollösszegek és mezőszintű összehasonlítás a forrással, nem egyszer, hanem ismételten lefuttatva. A legtöbb programnak párhuzamos üzemre is szüksége van, ahol mindkét rendszer ugyanazt a bemenetet dolgozza fel, és a kimeneteket bájtról bájtra hasonlítják, amíg az eltérések meg nem szűnnek vagy magyarázatot nem kapnak. Ez az összehasonlító keretrendszer valódi szoftver, saját fejlesztési költséggel, és a tervbe tartozik, nem a tartalékkeretbe.

Hogyan válasszon mainframe migrációs eszközöket megbánás nélkül

Néhány alapelv a földön tartja ezeket a döntéseket.

Ragaszkodjon egy koncepcióbizonyításhoz a saját legrosszabb kódján, ne a szállító mintáján. Válassza azt a modult, amelyet mindenki kerül, azt az Assembly-hívással és a hétszintű REDEFINES-szal, és kérje meg őket, hogy konvertálják. Az eredmény többet mond bármelyik referenciaügyfélnél.

Kérdezze meg kifejezetten, hogyan kezeli az eszköz a decimális aritmetikát és a rendezési sorrendet, és kérje el a generált kimenetet összefoglaló helyett. Ha a szállító csúnya bemenetből nem tud olvasható kódot mutatni, feltételezze, hogy a kézi utómunka becslése nagyobb az ajánlottnál.

Az automatizálási százalékokat a sorok, nem a ráfordítás mérőszámaként kezelje. Egy eszköz, amely az utasítások kilencven százalékát konvertálja, még mindig meghagyhatja azt a tíz százalékot, amelyben az összes kockázat lakik, és ez a tíz százalék rendszeresen a menetrend több mint felét emészti fel.

Végül tervezzen költséget arra, amit egyetlen eszköz sem érint: a tesztkeretre, az egyeztetésre, a párhuzamos üzemre, az üzemeltetési kézikönyvekre és az átképzésre. A COBOL-migráció költségéről és ütemezéséről szóló útmutatónk bemutatja, hogyan oszlanak meg ezek a tételek egy programon belül.

Kérjen független véleményt, mielőtt elkötelezi magát

A Mecanik örökölt nagygépes migrációs és COBOL-migrációs programokon mérnökként dolgozik, nem eszközviszonteladóként, vagyis semmilyen jutalék nem függ attól, melyik platformot választja. Lefuttatjuk a feltárást, egy valóban nehéz modult kézzel és eszközzel is konvertálunk, és megmutatjuk a különbséget, mielőtt bárki bármit aláírna.

Ha az állománya kisebb, vagy a kérdése inkább a célnyelvről szól, mint az eszközökről, a COBOL-modernizációs szolgáltatásunk oldalai leírják, hogyan méretezzük ezt a munkát. Bármelyik eset áll fenn, a hasznos első lépés egy rövid beszélgetés arról, mi van valójában a kódbázisában, mert az eszközkérdésre adott válasz teljes egészében ettől függ.

Kapcsolódó bejegyzések: COBOL-ról Pythonra migrálás , COBOL-Go migráció: útmutató UK vállalatoknak és COBOL-Rust migráció - Útmutató UK vállalatoknak ., COBOL-modernizáció: hogyan válasszon szállítót

Gyakran ismételt kérdések

Automatizálhatják a mainframe migrációs eszközök a teljes projektet? Nem. Az automatizált fordítás jellemzően az utasítások túlnyomó többségét konvertálja, a maradékban viszont Assembly modulok, tranzakciós állapotkezelés, változatos rekordszerkezetek és dokumentálatlan üzleti szabályok vannak, amelyek kézi munkát igényelnek. A tesztelést, az egyeztetést és a párhuzamos üzemet az elért automatizálási szint egyáltalán nem érinti.

Melyik a jobb: a rehosting vagy az automatizált kódkonverzió? Más problémát oldanak meg. A rehosting gyorsan leveszi a terhelést a nagygépes hardverről és csökkenti az üzemeltetési költséget, de COBOL marad a kezében. A kódkonverzió nyelvet és munkaerőpiacot vált, jóval nagyobb költséggel és kockázattal. Sok szervezet előbb rehostol, hogy ebből finanszírozza a szakaszos konverziót.

Miért néz ki ilyen olvashatatlanul a konvertált COBOL kód? A fordítómotorok hűen megőrzik a viselkedést, köztük a COBOL vezérlési folyamát, elnevezéseit és adatszerkezeteit. A GOTO-láncokra és közös tárterületekre épülő kódnak nincs tiszta megfelelője Javában vagy C#-ban, így a kimenet az eredeti szerkezetet tükrözi. Karbantartható kódhoz emberi refaktorálás kell a konverzió után.

Milyen adatproblémákat hagynak ki a mainframe migrációs eszközök? A formátumkonverziót jól kezelik, a jelentést viszont nem tudják feloldani. Az újrahasznosított kitöltőmezők, az ablakozási szabállyal használt hatjegyű dátumok, a csak programban definiált státuszkódok és az eltűrt duplikált kulcsok mind emberi döntést igényelnek, mielőtt a célséma helyesen megtervezhető lenne.

Hogyan igazolható, hogy a migrált rendszer ugyanúgy viselkedik? Futtassa mindkét rendszert ugyanazokon az éles bemeneteken egy meghatározott ideig, és hasonlítsa össze a kimeneteket mezőről mezőre, minden migrált adatállományra vett rekordszámokkal és kontrollösszegekkel alátámasztva. Az összehasonlító keretrendszert önálló szállítandóként építse meg, mert az eltérések folyamatosan bukkannak elő, nem egyszerre.