Ajatuksia DB2:n multiskema ympäristöstä z/OS alustalla

1. Ajatuksia DB2:n multiskema ympäristöstä z/OS alustalla Sovellusaluekohtaiset - toisistaan riippumattomat testikannat samaan järjestelmään Matti Ståhl Eläkeläinen Tieto, matti.stahl@wippies.fi

2. Mitä tarkoitetaan DB2:n multiskema ympäristöllä? • On mahdollista, että olen vain itse ryhtynyt käyttämään tuota nimeä • Tarkoitan sillä UDB for z/OS –ympäristöä, jossa staattista(kin) SQL:ää toteutetaan samalla ohjelmalla eri qualifiereilla kohdennettuihin resursseihin. • Ympäristössä • Ohjelmat ja moduulit ovat ’yhteisiä’, eli esiintyvät vain yhdellä nimellä • Taulusta voi olla eri tarkentimilla useita ilmentymiä, joissa on eri sisältö, mutta normaalisti sama rakenne • Paketti voi esiintyä monessa kokoelmassa eri tarkentimella bindattuna • Synonymejä on usealle tarkentimelle, ja useampi synonymi voi viitata samaan tauluun. (Voisi varmaankin olla myös alias). DB2 multiskema

3. Suppeassa muodossa käytetty (Tieto)Ilmarisessa jo pitkään • Alimmalla testitasolla on testattu eräohjelmia ja IMS:n MPP-ohjelmia sovelluskehittäjän henkilökohtaisessa ympäristössä. • Sovelluskehittäjän henkilökohtainen ”varustsus” • Kokoelma • Synonymit • Taulut ainakin ne, joita hän testatessaan päivittää. • Plani • On kehitetty välineet synonymien kohdistamiselle ja oman pakettikokoelman sisällön ajantasaistamiseksi. • Henkilökohtainen plani käyttää paketteja ainoastaan henkilökohtaisesta kokoelmasta • Paketit on bindattu tuohon kokelmaan kohdistamalla resurssit henkilökohtaisilla synonymeillä • Kun testaaminen suoritetaan henkilökohtaista plania käyttäen (MPP-ohjelmat testataan BTS:llä), niin testidatakin on henkilökohtainen DB2 multiskema

4. Saattaa olla tarve päästä pidemmälle. • Yhdessä ympäristössä testattavilla sovelluskokonaisuuksilla voi olla ristiriitaisia tarpeita testidatan suhteen • Näkökulma koko dataan (tästäenemmän toisella kalvolla) • Datan ajantasaistamisen rytmi • Uusien testitapausten tuominen ympäristöön • Regressiotestit • Datan pysyvyys tietyssä tilassa (laskentahetki, maksatushetki, suoritusten kirjaamishetki) DB2 multiskema

5. Sovellusten ristiriitaiset näkökulmat dataan • Näiden esiintyminen riippuu yrityksen bisneksestä • Työeläkeyhtiön järjestelmissä se on hyvin vahvasti mukana • Tietyllä hetkellä työsuhde kuuluu yhteen eläkevakuutukseen ja toisaalta se on yksi pala henkilön työhistoriaa ja muut palat ovat toisissa vakuutuksissa. • Useimmat sovellukset näkevät sovellusdatan joko vakuutus- tai henkilön työhistorian näkökulmasta. • Vakuutusmaksun laskenta • Eläkkeen laskenta • Jos tuotantoympäristön kaltaisesta ympäristöstä otetaan otos testiympäristöön, jossa on vain yksi skema, niin data ei voi olla ehyt molemmista näkökulmista katsottuna • Vakuutukselta puuttuu henkiöiden työsuhteita tai • Henkilön työhistoriasta puuttuu osia • Kun data ei ole eheätä, niin tulokset ovat väärin tai ohjelmat eivät toimi lainkaan. DB2 multiskema

6. Ristiriitojen ratkaisemisen haasteita • DB2-järjestelmien monistaminen edellyttäisi myös IMS/CICS –järjestelmien monistamista • Ilman näppäriä kikkailuja tämä vielä kertautuu jos ympäristöt on kahdennettu CF:llä. (Data Sharing ympäristö). • Järjestelyn täytyy toimia ohjelmien kaikissa toimintaympäristöissä • IMS:n MPP-ohjelmat • CICS-ohjelmat • Eräajot (TSO-batch, DL/I-batch, IMS:n BMP) • DB2 stored procit • On olemassa ohjelmia, joita useampi sovellusalue käyttää • Yleensä ei ole mahdollista käyttää samalle ohjelmalle eri nimistä plania eri sovellusalueilla. DB2 multiskema

7. Pakettikokoelman asetus ohjelman toteutusvaiheessa • Oletuksena DBRM:t haetaan MEMBERLIST:n tai/ja PACKAGELIST:n perusteella. • SET CURRENT PACKAGESET asettaa kokoelman, josta lataamatonta pakettia haetaan ensisijaisesti • Näin voidaan asettaa vain yksi kokoelma kerrallaan, joista viimeisin on voimassa • SET CURRENT PACKAGEPATH (DB2 v9) voidaan asettaa polku, jossa määritellään monta kokoelmaa • Muuten se toimii kuten SET CURRENT PACKAGESET • Nämä tekevät pakettien hakupolkuun vaikuttamisen toteutusaikana erittäin helpoksi. • COMMIT ei pura asetusta DB2 multiskema

8. Multiskema ympäristön rakentamisen edellytyksistä • Vaatii automatiikkaa • Ympäristössä pitää olla käytössä jonkin tasoinen kokoonpanohallinta esim. Kehikko (tällä on eri nimi eri ympäristöissä), jonka varaan automatiikkaa voidaan rakentaa. • Hyvä nimistandardi helpottaa huomattavasti • Jos nimeämisestä johdettava implisiittinen päättely ei ole mahdollista, tarvitaan todennäköisesti johonkin tauluun pohjautuva eksplisiittinen ohjaus DB2 multiskema

9. Menettely, jota on kokeiltu • Sovelluskenttä jaetaan osa-alueisiin, joissa näkökulma dataan on mahdollisimman sama, eli osa-alueen sisällä ei ole ristikkäisiä vaatimuksia • Lukumäärä mahdollisimman pieni • Kullekin osa-alueelle luodaan oma skema sen tarvitsemassa laajuudessa • Lisäksi kaikkien sovellusten käyttämä perusdata on oma skemansa • Voidaan myös rakentaa skemoja erillisille hankkeille, jolloin niillä on hankeen keston mukainen elinkaari DB2 multiskema

10. Käyttäjä valitsee osa-alueen, jolla hän testaa. • Luodaan taulu, jossa käyttäjä ilmoittaa sen osa-alueen, jossa hän ohjelmia toteuttaa. • Ohjelma kutsuu moduulia, joka asettaa CURRENT PACKAGESET:n tämän ohjauksen perusteella. • Polkuun liitetään myös muita kokoelmia, jotta kaikki paketit löytyvät ilman että, ne ovat tässä kyseisessä kokoelmassa • Näiden moduulikutsujen lisääminen ohjelmiin on koko homman ehkä suurin työ. • Ympäristöissä, joissa ei käytetä multiskemaa, ohjaustaulu on tyhjä tai moduulista käytössä dummy –versio. DB2 multiskema

11. Synonyymien rooli • Jos jokaisen skeemaan luodaan synonymi kaikille tauluille, niin asia ei mene turhan monimutkaiseksi • Synonymi on aika ’kevyt’ ja harmiton ötökkä. • Aika helppo luoda automaatti, joka tarkistaa, että kaikki synonymit ovat olemassa. • Jos skemalla on oma taulu, niin synonymi kohdistetaan siihen. • Muussa tapauksessa se kohdistetaan yhteiselle alueelle • Osa skeman synonymeistä on tarpeettomia DB2 multiskema

12. Yksittäisen paketin kannalta on kolme erilaista tilannetta • Kaikki paketin käyttämät taulut löytyvät skemasta • Kaikki synonymit osoittavat skeman omiin tauluihin. • BIND tehdään skemaa vastaavaan kokoelmaan • Osa paketin käyttämistä tauluista löytyy skemasta • Osa synonymeistä osoittaa skeman omiin tauluihin ja osa yhteisiin. • BIND tehdään skemaa vastaavaan kokoelmaan • Mitään paketin käyttämää taulua ei löydy skemasta • Tämä paketti voidaan toteutusaikana ottaa polulle lisätystä yhteisestä kokoelmasta. • Myös sille voidaan tehdä BIND skemaa vastaavaan kokoelmaan. • Synonymit osoittavat yhteisen alueen tauluihin • Automatiikka voi päätellä, kuinka paketin BIND tehdään DB2 multiskema

13. POC -testin laajuus • Automatiikkaa ei rakennettu • Synonymit ja BIND:it tehtiin ’täsmätyönä’ yhdelle sovellukselle • Testausta tehtiin erilaisissa ympäristöissä • IMS MPP • IMS BMP • CICS • DL/I batch • DB2 Stored procedure • Päätökset laajasta käyttöön otosta antavat odottaa itseään DB2 multiskema