ABIS Infor - 2012-10
Migratie van een mainframe omgeving
Samenvatting
Je kan allerlei redenen bedenken waarom mensen of bedrijven verhuizen. ABIS heeft de beslissing genomen om te veranderen van mainframe, o.a. omwille van economische motieven. Voor alle duidelijkheid: het gaat over een migratie van mainframe naar mainframe! Maar wat komt er allemaal bij kijken om zo een mainframe omgeving over te zetten?
Wat is een mainframe omgeving?
Toegegeven, de term mainframe klinkt oubollig; men gebruikt steeds vaker de term 'enterprise server'. Maar dit o.a. juist om uitdrukking te geven aan het feit dat de veelheid aan individuele servers - applicatie servers, database servers, mail servers, security servers, web servers - nu geconsolideerd wordt op die ene 'enterprise server'.
Dat betekent dus ook dat het bij een mainframe omgeving niet (alleen) gaat over de hardware, maar ook over het netwerk en de communicatie-infrastructuur, en vooral over de software, operating systeem - subsystemen en applicaties. Om tenslotte zeker de (business) gegevens niet te vergeten.
Hoe pakken we de migratie aan?
Het proces van de keuze van een (andere) mainframe, op basis van de vereisten voor onze omgeving, komt in dit artikel niet aan bod. Maar het is evident dat dit proces niet over een nacht ijs is gegaan.
Een goede inventaris van de bestaande mainframe situatie is alvast noodzakelijk:
- welke hardware configuratie: hoeveel CPU capaciteit (MIPS), real storage (MB), I/O channels en disk storage gebruiken we nu?
- welke versie van z/OS?
- welke (versies van) subsystemen DB2, CICS, IMS, ... ? welke configuratie en customisaties zijn er gebeurd?
- welke (versies van) tools en utilities zoals QMF, SAS, print faciliteiten, RDz, ... met hun configuraties?
- hoe is de ontwikkelomgeving van TSO/ISPF en RDz opgezet?
- welke toepassingen hebben we allemaal gebouwd in COBOL, PL/1, REXX, CLIST, ... ? hoe zit het met de batch verwerking (JCL en scheduling)?
- welke (hoeveel) gegevens hebben we voor onze training business allemaal verzameld in databases, SDS en PDS, VSAM, HFS, of andere filesystemen?
- hoe zit het met de integratie van de mainframe met de gedistribueerde applicaties via DDF, FTP, print, mail, 3270, ...? en dus ook de opzet van het netwerk (internet, intranet, extranet)?
- en last but not least, hoe zit het met de beveiliging in RACF en in de netwerk omgeving?
Stof genoeg voor een halve encyclopedie, want ja, documenteren is belangrijk.
Vervolgens bekijken we natuurlijk de nieuwe omgeving met zijn (nieuwe) mogelijkheden en verschilpunten:
- wat zijn de mogelijkheden van DB2 V10? of van z/OS V1.11?
- hoe kunnen we onze beveiliging anders/beter opzetten in RACF?
- kunnen we de bestaande naamgeving verder gebruiken?
- wat kunnen/moeten we anders implementeren, zoals bijvoorbeeld de logon procedure?
- wat zijn de beperkingen, waarvoor we een andere oplossing moeten zoeken, zoals het printwerk?
- welke customisaties en configuraties moeten er gebeuren, of kunnen we overnemen van de bestaande omgeving?
Dit alles is een hardere noot om te kraken, want de nieuwe omgeving is voorlopig nog te onbekend.
En dan komt de planning en realisatie.
De ABIS-methode
Vermits de nieuwe mainframe omgeving reeds geïnstalleerd is en beschikt over zowel een actieve z/OS omgeving, alsook geconfigureerde subsystemen zoals CICS en DB2, kunnen we ons concentreren op overzetten van de data en de toepassingen. Natuurlijk is ook de communicatie opzet en de beveiliging een belangrijk aandachtspunt.
Data transfer:
Voor het overzetten van de fysische MVS datasets werken we met ADRDSSU om dump datasets te creëren, met een logische groepering. Deze dump datasets worden dan via een TSO XMIT klaargemaakt voor de file transfer. FTP wordt omwille van (netwerk) beveiliging gedaan via een lokale PC. Op de andere mainframe worden de files geconverteerd via een TSO RECEIVE, en uiteindelijk via ADRDSSU gerestored op disk.
En ja, we botsen op allerlei problemen zoals beveiliging, maximum file size, network time-outs, ...
Voor het overzetten van de (logische) DB2 data maken we gebruik van DB2 UNLOAD/LOAD utilities i.p.v. ADRDSSU, maar voor de rest blijft de procedure gelijklopend. Natuurlijk moet er voor DB2 wel eerst een database opzet gebeuren van de nodige objecten in de DB2 cataloog. HIervoor genereren we de nodige DDL vanuit de oorspronkelijke cataloog door middel van de database tooling in Rational Developer voor System z (RDz). Uitvoeren van deze DDL op de nieuwe database omgeving levert (bijna) de juiste omgeving op, met uitzondering van indexen, triggers en stored procedures.
Ook hier worden we geconfronteerd met beveiliging, ontbrekende objecten, en ... verschillen van DB2 versie en van configuratie, zoals bijvoorbeeld de storage groepen.
Toepassingen:
Vermits de ABIS business voornamelijk gebaseerd is op de centrale DB2 voor z/OS, worden alle COBOL toepassingen gehercompileerd, gelinked en gebind. We zorgen voor een goede scheiding tussen test en productie-omgeving. Ook de gedistribueerde applicaties, gebaseerd op Java, C, PHP en Perl, en de communicatie via DRDA worden in orde gebracht.
De cursusomgeving met zijn voorbeelden en demo-toepassingen wordt voor alle cursusdomeinen bijgewerkt waar nodig.
Netwerk:
Overstappen naar een nieuwe mainframe impliceerde voor ABIS ook het opzetten van een nieuwe netwerkomgeving, dit keer in eigen beheer. Firewall en routers configureren, wijziging van netwerk-provider, opzetten van DMZ, internet definities aanpassen, opzetten van gateway voor DRDA, ... Het is ons gelukt, met het welbekende bloed, zweet en tranen. Maar dat is stof voor een ander artikel.
Beveiliging:
Overzetten van RACF definities kan gedeeltelijk door een extract van de bestaande RACF database te nemen (userids en groepen, dataset profielen). Maar daarna moet er nagedacht worden over het bijsturen en dichttimmeren van de openstaande gaten. En dat is een proces dat constant nog wordt gemonitored.
Customisatie
En dan komen we nog een aantal leuke addertjes tegen op weg naar de nieuwe omgeving. Onze nieuwe mainframe staat in een andere tijdzone, spreekt een ander taal (codepage), heeft een verschillende WLM opzet, gedraagt zich anders wat betreft SMS, en er zijn versieverschillen in de subsystemen. Daar moet nog aan gesleuteld worden.
Dus worden ook de configuraties onder de loep genomen; zoals bvb:
- DSNZPARM voor DB2 en een eigen subsysteem
- CSD voor CICS, en een eigen address space, met koppeling naar WebSphere MQ en DB2
- proclibs en procedures voor batch/JCL omgeving
- compile parameters voor COBOL en PL/1
- TSO logon en ISPF customisatie
- scheduling van backup procedures en replicaties
- SAS configuratie en connectie naar DB2
- gedistribueerde applicaties: DRDA (DDF), RDz, FTP, remote print, web services
Besluit
Het avontuur om over te stappen van een oude bekende mainframe omgeving naar een nieuwe (nog) onbekende infrastructuur is een zeer leerrijk proces geweest. Alle mogelijke aspecten zijn hierbij aan bod gekomen die voor een groot deel zijn opgelost dank zij de multidisciplinaire kennis van de ABIS docenten. Natuurlijk is de support van zowel de 'oude' als de 'nieuwe' mainframe ploeg onontbeerlijk geweest.
Maar ABIS staat weer klaar om zijn mainframe (en -kennis) aan te bieden aan al diegenen die de mainframe nog niet afgeschreven hebben.
En voor diegenen die een zelfde avontuur tegemoet gaan, wil ABIS natuurlijk zijn ervaringen delen en bijstaan met raad en daad in advies en opleidingen.