REXX-scripting voor IBM-mainframe bij ING

Departement Handelswetenschappen en Bedrijfskunde Gegradueerde in Toegepaste Informatica

REXX-scripting voor IBM-mainframe bij ING

CAMPUS Geel

Tijl Van den Broeck

Academiejaar 2004-2005 De houder van dit diploma is gerechtigd tot het voeren van de titel van Bachelor

2

WOORD VOORAF Tijdens mijn stage bij ING Insurance in Antwerpen heb ik 12 weken lang praktijkervaring opgedaan met een IBM-mainframe omgeving. Hier werd mij de mogelijkheid geboden om te tonen wat ik werkelijk waard ben in het bedrijfsleven. Ik heb daarbij verschillende mensen ontmoet en dankzij hen heb ik mijn stageopdrachten tot een succesvol einde kunnen brengen. Eerst en vooral wens ik Filip Van Gorp, mijn externe stagebegeleider, te bedanken om mij op te vangen en te begeleiden gedurende mijn stageperiode. Ik kon bij hem steeds terecht met vragen en problemen. Ondanks de verhuis van zijn werk naar Brussel maakte hij toch steeds tijd voor me vrij. Tevens wens ik mijn interne stagebegeleidster Kristine Mangelschots te bedanken voor haar hulp. Zij stond steeds ter beschikking om vragen te beantwoorden, teksten te controleren, … Verder wil ik ook nog alle collega’s bij ING Insurance danken. In het bijzonder Dirk Thys en Lily Craps. Daarnaast wens ik de Katholieke Hogeschool Kempen en de docenten Fons Baetens en Jef Verhaegen te bedanken om deze stageplaats voor mij te regelen. Ik dank ook alle andere docenten die mij met mijn opleiding hebben geholpen. Als laatste dank ik ook mijn ouders om mij de kans te geven de opleiding Toegepaste Informatica te volgen en mijn vriendin voor de steun tijdens het schrijven en het kritische nalezen.

3

SAMENVATTING Dit eindwerk is een verslag van mijn ervaringen met het IBM-mainframe platform (z/Series) bij ING Insurance te Antwerpen. Mijn stageopdracht bestond uit het schrijven van verschillende REXX-programma’s voor de productieomgeving. Een eerste programma hield verband met de omzetting van hun back-up proces naar REXXscripts. Het proces was oorspronkelijk in SAS geschreven. SAS is een programmeertaal in licentie door de bank, terwijl REXX in scripting voorziet voor IBM-mainframe. De hele backupketen moest herschreven worden tot en met de recoverystappen. Het tweede programma betrof een tool maken die de verplaatsing van meerdere volumes kon uitvoeren. Hierbij heb ik rekening gehouden met eventuele rollback mogelijkheden voor als er iets verkeerd gaat. Mijn laatste opdracht omvatte het in samenspraak creëren van een procedure om het nieuwe printersysteem van ING België op het mainframe werkende te krijgen, zonder bestaande programma’s daarvoor te moeten aanpassen. In dit verslag zal u na een snelle introductie in de mainframe wereld kunnen lezen over de verschillende programma’s en procedures die ik heb ontworpen.

4

ALFABETISCHE LIJST GEBRUIKTE AFKORTINGEN EN SYMBOLEN BBL BCD CEDS CICS CIDS CLI CMOS CSV DASD DAT DB2 DD DRP DSN ESCON FICON GB HCD I/O IBM IIB ING IPL ISPF JCL JES JVM LAN LPAR LRU MB MCM MIPS OPS/IT PAE PD PDS PDTIME POR PR/SM RAID RAM REXX SAN SAS SDSF SNA SRDF

Bank Brussel Lambert Binary Coded Decimal Common European Desktop Services Customer Information Control System Common Insurance Desktop Services Command Line Interface Complementary Metal-Oxide-Semiconductor Comma Separated Value Direct Access Storage Device Dynamic Address Translation Database Management System 2 Data Definition Disaster Recovery Procedure Dataset Name Enterprise Systems Connection Fibre Connection Gigabyte Hardware Configuration Definition Input/Output International Business Machines Corporation ING Insurance België Internationale Nederlanden Groep Initial Program Load Interactive System Productivity Facility Job Control Language Job Entry System Java Virtual Machine Local Area Network Logical Partition Least Recently Used Megabyte Multiple Chip Module Miljoen Instructies Per Seconde Operations/Information Technology Physical Address Execution Packed Decimal Partitioned Dataset Packed Decimal Time Power On Reset Processor Resource/System Manager Redundant Array of Independant Disks Random Access Memory Restructured Extended Executor Storage Area Network Statistical Analysis System System Display and Search Facility Systems Network Architecture Symmetrix Remote Data Facility

5

TSO/E TWS VM VPS VS VSE VTAM VTOC zAAP z/OS

Time Sharing Option/Extensions Tivoli Workload Scheduler Virtual Machine VTAM Printer Support System Volume Serial Virtual Storage Extended Virtual Telecommunications Access Method Virtual Table Of Contents zSeries Application Assist Processor zSeries Operation System

6

INHOUDSOPGAVE WOORD VOORAF SAMENVATTING .................................................................................................................... 3 ALFABETISCHE LIJST GEBRUIKTE AFKORTINGEN EN SYMBOLEN......................... 4 INHOUDSOPGAVE.................................................................................................................. 6 INLEIDING ............................................................................................................................... 8 1

PROFIEL STAGEBEDRIJF ..................................................................................... 9

1.1 1.2 1.3 1.4

INLEIDING .................................................................................................................. 9 ING GROEP ................................................................................................................ 9 ING INSURANCE......................................................................................................... 9 ORGANIGRAM IBM MAINFRAME ENGINEERING ...................................................... 10

2

HET “HOE EN WAT?” VAN EEN MAINFRAME .............................................. 11

2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 2.4

INLEIDING ................................................................................................................ 11 OVERZICHT VAN DE INFRASTRUCTUUR..................................................................... 12 EMC² Symmetrix 8830 ........................................................................................... 13 IBM z/890 type A04................................................................................................ 14 IBM 3494 Tape Library .......................................................................................... 16 Z/OS EXPLAINED ...................................................................................................... 17 Inleiding .................................................................................................................. 17 Logical Partitions (LPAR) ...................................................................................... 17 z/OS......................................................................................................................... 18 Datasets ................................................................................................................... 20 VTOC en CATALOG ............................................................................................. 21 TSO/E...................................................................................................................... 21 ISPF......................................................................................................................... 21 JCL en JES .............................................................................................................. 22 SDSF ....................................................................................................................... 24 IPL........................................................................................................................... 26 TIMEFINDER PRINCIPES............................................................................................. 27

3

TAAKOMSCHRIJVING OPDRACHT DRP......................................................... 29

3.1 3.2 3.2.1 3.2.2

ACHTERGRONDINFORMATIE ..................................................................................... 29 UITWERKING VAN DIT PROCES.................................................................................. 31 Stap 1: 16u............................................................................................................... 31 Stap 2: 0u → 2u....................................................................................................... 32

7

3.3 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.4.9 3.4.10 3.4.11 3.4.12 3.4.13 3.4.14 3.4.15

CONCRETE OPDRACHTOMSCHRIJVING ...................................................................... 34 UITWERKING OPDRACHT .......................................................................................... 34 Overzichtsschema.................................................................................................... 34 B8D300A ................................................................................................................ 37 B8D300B................................................................................................................. 37 B8D300C................................................................................................................. 38 B8D300D ................................................................................................................ 39 B8D300E................................................................................................................. 40 B8D300F ................................................................................................................. 40 B8D300G ................................................................................................................ 40 B8D300H ................................................................................................................ 40 B8D310x-Reeks ...................................................................................................... 40 B8D320A ................................................................................................................ 41 B8D320B................................................................................................................. 46 B8D320C................................................................................................................. 46 B8D320D ................................................................................................................ 46 B8D320E................................................................................................................. 47

4

TAAKOMSCHRIJVING OPDRACHT VOLSMIGR............................................ 48

4.1 4.2 4.3

ACHTERGRONDINFORMATIE ..................................................................................... 48 CONCRETE OPDRACHTOMSCHRIJVING ...................................................................... 48 UITWERKING VAN DE OPDRACHT ............................................................................. 49

5

TAAKOMSCHRIJVING OPDRACHT VPS ......................................................... 54

5.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4

ACHTERGRONDINFORMATIE ..................................................................................... 54 CONCRETE OPDRACHTOMSCHRIJVING ...................................................................... 55 UITWERKING VAN DE OPDRACHT ............................................................................. 56 CEDS-IIB_printing.xls............................................................................................ 56 Converteren naar CSV ............................................................................................ 56 Uploaden via FTP.................................................................................................... 57 VPSGENER ............................................................................................................ 57

BESLUIT ............................................................................................................................... 60 LITERATUURLIJST............................................................................................................... 61 BOEKEN ............................................................................................................................... 61 LOSBLADIGE WERKEN ............................................................................................................... 61 ELEKTRONISCHE BRONNEN ....................................................................................................... 61 MONDELINGE BRONNEN ............................................................................................................ 62

8

INLEIDING Gedurende drie maanden heb ik stage gelopen bij ING Insurance te Antwerpen in de afdeling IBM Mainframe System Engineering. Ik heb de mogelijkheid gekregen om verschillende ervaringen op te doen met een mainframe omgeving. In het eerste hoofdstuk schets ik het profiel van mijn stagebedrijf alsook de afdeling waar ik stage heb gelopen. Vervolgens geef ik een overzicht van de IT-infrastructuur waarmee ik in contact kwam. Ik bespreek hierbij uitgebreid alle facetten van de hardware en software. In dit eindwerk maak ik gebruik van de terminologie die eigen is aan het mainframe. Ik licht dit in dit hoofdstuk zoveel mogelijk toe. De volgende drie delen gaan over mijn verschillende stageopdrachten en de uitwerking daarvan. Ik beschrijf hierin de automatisatie van het back-up proces, het verplaatsen van volumes en het printerbeheer onder mainframes. Zet u al maar schrap om te leren dat mainframes heel wat anders zijn dan stoffige archaïsche machines uit de jaren ’60!

9

1

PROFIEL STAGEBEDRIJF

1.1

Inleiding

Dit deel beschrijft in het kort mijn stagebedrijf en de afdeling waar ik stage heb gelopen.

1.2

ING Groep

ING Groep is een wereldwijd opererende financiële instelling van Nederlandse oorsprong. Zij heeft meer dan 115.000 medewerkers in dienst. Ze heeft vestigingen in 50 landen en ongeveer 60 miljoen klanten over heel de wereld waaronder particulieren, bedrijven en overheden. Lang niet alle instellingen die onder de ING Groep vallen werken met de naam “ING” maar dit is slechts een kwestie van tijd. In de bankwereld zijn er namelijk altijd fusies en samenwerkingen aan de gang. De ING Groep streeft vooral het ‘click-call-face’ principe na. Dit principe houdt in dat een klant altijd contact moet kunnen opnemen via Internet, telefoon of rechtstreeks met een kantoor of medewerker. Zo kan men aan de klant onbeperkte toegang, optimaal gemak, onmiddellijke en nauwkeurige uitvoering, persoonlijk advies, maatwerk en competitieve tarieven aanbieden. Met deze strategie probeert ING een stabiele groei met behoud van winstgevendheid te bereiken. Dit wordt eveneens ondersteund door de enorme financiële kracht van de Groep en de variëteit aan producten en diensten. Het missiestatement van ING Groep is dan ook niet voor niets: “ING wil een vooraanstaande, wereldwijd opererende, klantgerichte, innovatieve en kostenefficiënte financiële dienstverlener zijn, die haar klanten diensten aanbiedt via het distributiekanaal van hun keuze, in markten waar ING waarde kan creëren.” (ING GROEP, 2004)

1.3

ING Insurance

ING Insurance is één van de topverzekeraars in de Belgische markt. Ze heeft een ruim aanbod van schade-, levens- en beleggingsverzekeringen. Jarenlange ervaring van de grondleggers van ING Insurance is hiervan de oorzaak. ING Insurance is ontstaan uit de Vaderlandsche, RVS en BBL Verzekeringen. ING beschikt nu over het vermogen om de ervaring om te zetten in goed afgestemde verzekeringsproducten. ING Insurance maakt deel uit van de ING Groep en daardoor kunnen de producten worden verdeeld door één van de 900 ING kantoren in België of door professionele verzekeringsmakelaars. Ik heb de mogelijkheid gekregen om mijn stageopdracht tot stand te brengen in één van de hoofdzetels van ING Insurance, namelijk in Antwerpen. (ING INSURANCE, 2004)

10

1.4

Organigram IBM Mainframe Engineering

Hieronder vindt u een beknopt organigram van de afdeling waarin ik mijn stage liep. ING Belgium OPS/IT …

Business Information Systems Marc Boghe

…

IT Services Louis Mahy

…

Systems Engineering Eric Van Isterdael

…

IBM MF Engineering Luc Van den Bulck

…

System Administrator Filip Van Gorp

System Engineer Lily Craps

System Engineer Dirk Thys

Stagair Tijl Van den Broeck

Figuur 1-1Organigram IBM Mainframe Engineering (ORGANIGRAM, 2005) De afdeling IBM Mainframe Engineering staat in voor het dagelijkse beheer van de IBMmainframe bij de verschillende centra van ING België.

11

2

HET “HOE EN WAT?” VAN EEN MAINFRAME

2.1

Inleiding

In dit hoofdstuk zal ik het eerst hebben over de infrastructuur die bij ING Insurance gebruikt wordt. Vooral over de hardware zal ik in detail treden om zo goed mogelijk de omgeving te schetsen waarin dit eindwerk tot stand kwam. Vervolgens zal ik zo kort mogelijk de essentie van de software voor mainframes schetsen. Daaronder vallen bijvoorbeeld de verschillende begrippen van het besturingssysteem. Ook de werking van enkele back-upsystemen wordt al even aangeraakt. Dit omdat een deel van mijn opdracht over het back-upproces ging.

12

2.2

Overzicht van de infrastructuur

Hieronder geef ik een kort overzicht van de IT-infrastructuur waarmee ik in contact kwam tijdens mijn stage. De volledige IT-infrastructuur van ING is natuurlijk véél uitgebreider dan dit.

4 x FICON

EMC² Symmetrix 8830 Disk Subsystem

2 x 1GBit OSA Express (Ethernet)

IBM z/890 A04 Mainframe @ 350 MIPS

10 x ESCON ING Netwerk

Ethernet IBM 3494 Tape Library

IP Based Xerox printers

Figuur 2-1 ING Insurance Core IT-infrastructuur

13

2.2.1

EMC² Symmetrix 8830

De EMC² Symmetrix 8830 is een high end Disk Subsystem dat aangesloten is op een SAN. Een Disk Subsystem is een soort server die enkel en alleen beheer en opslag van data uitvoert. Een SAN is een speciaal soort netwerk dat specifiek gecreëerd is om de opslag van data en de toewijzing van een dataopslagplaats centraal te organiseren. Door gebruik te maken van fiberoptische verbindingen - tussen verschillende servers en de Symmetrix machine - kunnen de servers hun toegewezen opslagplaats benaderen alsof het één van hun harde schijven was. Naast het voordeel van centraal beheer is er ook een enorm snelheids- en afstandsvoordeel dankzij een SAN. Dankzij de snelle fibre channel (100MB/s, zie “Figuur 2-2 Vergelijking snelheden harde schijf verbindingen”) connecties kan men genieten van snelle en lange afstandsverbindingen. Een server hoeft dus niet vlak naast zijn dataopslagsysteem te staan, maar kan gerust enkele honderden meters of zelfs kilometers verder staan (zie “Figuur 2-3 Vergelijking afstanden verbindingstypes”).

Figuur 2-2 Vergelijking snelheden harde schijf verbindingen

Figuur 2-3 Vergelijking afstanden verbindingstypes

Het snelheidsvoordeel van een Disk Subsystem aan een SAN is niet alleen te wijten aan zijn verbindingen maar vooral aan zijn cache. Deze cache gebruikt het Least Recently Used (LRU) algoritme om recent gebruikte informatie te stockeren in supersnel intern geheugen. De responstijden zijn hierdoor heel laag en er is geen dataverlies bij het uitvallen van de elektriciteit. Als de elektriciteit uitvalt zal het systeem toch nog alle data weg kunnen schrijven dankzij een batterij-systeem. Het is ook mogelijk om een zogenaamde “permacache” te creëren. Hierbij kan een harde schijf - of een deel ervan - permanent in de cache bijgehouden worden, zonder dat het verwijderd wordt door het LRU-algoritme Één van de belangrijkste taken van het IT-personeel in eender welk bedrijf is het voorzien van back-ups. Dankzij dit Symmetrix systeem kan men het merendeel van de back-ups van de data centraal maken. Dit geld zowel voor open systemen (AIX, NT, SUN, Linux, …) als voor mainframes. Een deel van mijn stageopdracht gaat over het back-up proces bij ING Insurance van de IBM-mainframe omgeving.

14

Naast centrale back-ups is er nog het voordeel dat een Disk Subsystem op termijn kostenbesparend werkt, ondanks de hoge aankoopprijzen. Er wordt namelijk minder capaciteit verkwist met een Disk Subsystem. Als je 40GB nodig hebt op server A en 60GB op server B terwijl ze beiden harde schijven hebben van 80GB dan kunt u zich afvragen wat u met de overige capaciteit moet doen. Bij een SAN-server kunt u met een simpele webinterface de ruimte kostenbesparend beheren zoals u in “Figuur 2-4 Beheren SAN” kunt zien.

SAN

EMC² Symmetrix

Tape Library Server

LAN

Mainframe Webbrowser

Workstation

Server 1: 256 GB Server 2: 662 GB Server 3: 129 GB Mainframe: 2.6 TB

Figuur 2-4 Beheren SAN De verschillende harde schijven die in de Symmetrix machine zitten kunnen ook ingesteld worden om RAID (Redundant Array of Independant Disks) te gebruiken. Zo wordt er binnen ING Insurance gebruik gemaakt van RAID 1, dat ook bekend staat als “mirroring”. Dit principe zorgt ervoor dat elk volume eveneens op een ander volume terug te vinden is. Er worden steeds twee kopieën bijgehouden van de data zodat er niets verloren gaat als een harde schijf stuk gaat. (DATA-MANAGEMENT, 2003, p. 14, 17, 20-25, 46-52) 2.2.2

IBM z/890 type A04

De IBM z/890 is een compatibele evolutie van de oude S/390-serie waarin vele hardware- en softwarematige verbeteringen zijn in aangebracht. De eerste z/Series werden geïntroduceerd in 2000. Ik zal kort enkele van de belangrijkste kenmerken schetsen van de z/890. Geheugenadressering van de z/890 gebeurt met 64 bit waarbij virtuele geheugenadressering wordt gebruikt. Dit laatste is vooral nuttig binnen LPAR’s, waarover later meer. Dankzij deze adressering kan er aanspraak gemaakt worden op maximaal 32 GB RAM-geheugen, terwijl dit bij traditionele 32 bit adressering slechts 4GB is.

15

De z/890 beschikt over meerdere processors van het type Power 5 van IBM. Net zoals in de consumentenmarkt tussen Intel, AMD, VIA en Apple valt de snelheid hier niet te vergelijken in het aantal megahertz. Een vergelijking maken is haast onmogelijk want ook het aantal miljoen instructies per seconde is geen vergelijkingsbron vanwege de RISC architectuur. Misschien kan toch een vergelijking gemaakt worden met een Apple G5, de PPC970 die Apple gebruikt is gebaseerd op de Power 4 (de voorganger van de Power 5). Wanneer Linux op beide systemen wordt gebruikt als besturingssysteem is de snelheid van een mainframe vele malen groter. De processoren zijn superscalair ontwikkeld. Een scalaire processor kan één instructie per cyclus afwerken. Superscalair houdt in dat er meerdere instructies per cyclus afgewerkt kunnen worden, dit staat ook bekend als parallel processing. Er zitten vijf processors op de MCM (Multiple Chip Module). Dit is de kaart waarop de processors geplaatst zijn. Van deze processors zijn er maximaal vier actief met hun eigen instructies. Van deze vijf is er altijd één als back-up voorzien, in het geval dat één van de andere processors het begeeft. Het aantal MIPS van een IBM-mainframe wordt overigens niet bepaald door wat erin zit, maar door wat IBM ervan “activeert”. Afhankelijk van hoeveel je betaald wordt de rekenkracht verhoogd of verlaagd. Het verhogen of verlagen van de rekenkracht kan over het algemeen dynamisch gebeuren zonder een reset van het systeem. De z/890 van ING België is ingesteld op 350 MIPS (miljoen instructies per seconde). Om de recente ontwikkelingen in webapplicaties en de programmeertaal Java te volgen heeft IBM de z/890 uitgebreid met enkele speciale onderdelen, zoals de zSeries Application Assist Processor (zAAP). Dit is een processor die ingesteld wordt om uitsluitend gebruikt te worden voor het geoptimaliseerd uitvoeren van JVM (Java Virtual Machine) instructies. Ook voor DB2 en CICS, het relationele database beheersysteem en online transactiesysteem van IBM, is er hardwarematige ondersteuning ingebouwd. Dagelijks gebruikte encryptiesystemen kunnen eveneens rekenen op hardware ondersteuning. Zelfs voor taken zoals debugging zijn er door de hardware ondersteunde trace-commando’s voorzien. De rekenkracht van dit alles lijkt dan wel indrukwekkend, in praktijk is deze van minder belang want het grootste en meest onderkende voordeel van een mainframe is het vermogen om veel I/O (Input/Output) operaties uit te voeren. De opslagapparaten (in dit geval de Symmetrix) zijn per definitie aangesloten met een FICON aansluiting. FICON is een ESCON (het datatransportprotocol van IBM) implementatie via fiberoptische aansluitingen en kabels die een snelheid van 100MB/s kunnen leveren. Er kunnen maximum 40 FICON kanalen aangesloten worden via uitbreidingskaarten in de I/O sloten. Met de FICON aansluitingen is de z/890 gekoppeld aan de Symmetrix 8830. Een IBMmainframe gebruikt meestal volumes (harde schijven) van het type 3390. Deze volumes worden geëmuleerd op de Symmetrix machine. De z/890 ziet dan een 1500tal 3390-3 volumes die elk ongeveer ± 2,8Gb groot zijn. Dit geeft een totale capaciteit van ± 4 TB. De verschillende 3390-3 volumes zijn meestal gemirrored (RAID 1). Enkel de test KLOON LPAR volumes staan niet in een mirror (later meer over het begrip LPAR). (WHITE, e.a., 2004:2, 3, 5, 7, 9-11, 18-21, 23-27, 31, 39, 44, 46, 49; VAN GORP, 2005:Mondelinge mededelingen)

16

2.2.3

IBM 3494 Tape Library

De IBM 3494 is een taperobotsysteem dat uitbreidbaar is en verschillende tapes kan stockeren. Er kunnen tot 16 blokken (frames) toegevoegd worden om tapes in op te slagen. De tape drives zelf worden eveneens in de IBM 3494 geplaatst, zo kunnen er 12 drives in een blok (frame) geplaatst worden. De robot kan daardoor naar verschillende tapes tegelijk schrijven en lezen. Op één tape (type magstar) kan 40 GB data ongecomprimeerd opgeslagen worden, gecomprimeerd tot zelfs 120 GB per tape. Bij de IBM 3494 van ING Insurance zijn er vijf frames bijgeplaatst zodat er in totaal 1493 tapes kunnen bewaard en benaderd worden. (DATA-MANAGEMENT, 2003, p. 40-42, 63-64)

17

2.3

z/OS explained

2.3.1

Inleiding

In dit gedeelte probeer ik zo simpel mogelijk enkele concepten van de z/890 en zijn besturingssystemen uit te leggen. 2.3.2

Logical Partitions (LPAR)

Een deel van mijn stageopdracht gaat over back-ups van de productie LPAR van de IBMmainframe. Een LPAR is een “Logical Partition”. Aan deze LPAR kunt u resources van het mainframe toewijzen. Onder resources verstaan we hier bijvoorbeeld het maximum percentage van de processors dat een LPAR mag gebruiken. Zelfs één processor toewijzen aan een LPAR is mogelijk. Ook kunnen de FICON kanalen toegewezen worden aan een van de LPAR’s. De LPAR’s werken zelfstandig als een volledig alleenstaand systeem binnen de mainframe. Het concept valt te vergelijken met het principe van een virtuele machine (bijvoorbeeld VMWare), maar bij een LPAR gebeurt de scheiding reeds op microcode niveau. De microcode (ook PR/SM genaamd in de mainframe wereld) is vergelijkbaar met het CMOS in een gewone computer. Bij systeemupgrades, aanpassingen van LPAR’s en dergelijke moeten de instellingen toegepast worden bij de Power On Reset (POR). De POR is een volledige reset van het systeem. De parameters die u kunt wijzigen worden op voorhand klaargezet, in tegenstelling tot de CMOS bij de gewone computers. Bij ING Insurance België vinden we vier LPAR’s terug: productie, kloon, test en IFSA. Zie ook “Figuur 2-5 Verdeling LPAR resources z/890”. (WHITE, e.a., 2004:126-129)

18

Symmetrix

IBM z/890 Processors @ 350 MIPS

Geheugen

I/O-sloten (oa. FICON,…)

Microcode (PR/SM) 86 %

PROD

KLOON

5%

4%

TEST

5%

IFSA

Figuur 2-5 Verdeling LPAR resources z/890

2.3.3

z/OS

z/OS is één van de mogelijke besturingssystemen voor de z/Series machines van IBM. Ik ga hier dieper op in omdat dit het besturingssysteem is dat door ING Insurance wordt gebruikt. z/OS is een zeer stabiel besturingssysteem dat de verschillende aspecten van moderne besturingssystemen op een efficiënte manier afhandelt. z/OS ondersteunt multiprogramming en multiprocessing. Multiprogramming biedt de mogelijkheid om een proces te “pauzeren”, de informatie ervan op te slagen, vervolgens een ander proces uit te voeren en dan weer verder gaan met het gepauzeerde proces. Multiprocessing laat toe om dit alles te doen met verschillende processors gelijktijdig. Dat brengt natuurlijk enige problemen mee die z/OS opvangt met Control Blocks. Terwijl het systeem instructies uitvoert, wordt alle uitvoerinformatie van de instructies daarin opgeslagen. Het geheugen wordt in z/OS geregeld op een manier die vergeleken kan worden met Physical Address Execution (PAE) bij MS Windows. PAE is alleen mogelijk als Windows gestart wordt met de parameter /PAE in boot.ini om meer dan 4GB geheugengebruik toe te laten. Het echte werkgeheugen, dat bij mainframes real storage wordt genoemd, wordt gekoppeld aan virtuele geheugenadressen. (MADDEN, 2004) Per gebruiker wordt er een address space gemaakt. Deze address space bestaat uit een virtuele versie van het volledige 64 bit bereik van het geheugen (ongeveer 16 exabytes, zie Figuur 2-6 Evolutie adressering bij IBM Mainframe Operating Systems). Het z/OS besturingssysteem koppelt met behulp van DAT (Dynamic Address Translation) deze adressen weer door aan het échte adres, en beheert de toewijzingen van het geheugen.

19

Dit DAT-systeem was nodig om compatibiliteit te bewaren met oudere programma’s. Vele programma’s uit de jaren ’60 - die nog steeds gebruikt worden - zijn geschreven om uitgevoerd te worden in de eerste 16 MB van het geheugen (zie “Figuur 2-6 Evolutie adressering bij IBM Mainframe Operating Systems”). Met behulp van virtuele adressering is het perfect mogelijk deze programma’s nog steeds te gebruiken zonder problemen. In alle address spaces zijn ook “common areas” aanwezig. Dit zijn uitwisselingsgebieden in het geheugen die andere applicaties van andere gebruikers kunnen benaderen. Zo kan er gemakkelijk informatie in het geheugen tussen programma’s uitgewisseld worden. (EBBERS, e.a., 2005:54, 61-65)

Figuur 2-6 Evolutie adressering bij IBM Mainframe Operating Systems Zelfs een IBM-mainframe heeft behoefte aan een virtueel geheugen bij een tekort aan real storage (werkgeheugen). Het virtuele geheugen wordt in z/OS geregeld door het indelen van de instructies en de data. Dat gebeurt met frames bij de real storage (werkgeheugen) en met slots bij de auxiliary storage (DASD volumes gebruikt als geheugen). Net zoals bij alle andere besturingssystemen noemt het verplaatsen van deze slots en frames “paging”. Voor het verwijderen van frames is gekozen voort het Least Frequently Used algoritme. (EBBERS, e.a., 2005:55-61)

20

Enkele alternatieven voor z/OS zijn: ♦

VSE (Virtual Storage Extended) die de evolutie is van het oude Disk Operating System van de IBM S/360. ♦ Linux for zSeries, dit is een aangepaste versie van Linux die werkt op de z/Series. ♦ z/TPF, een speciaal besturingssysteem om extreem hoge hoeveelheden van transacties te kunnen verwerken. Dit systeem werd ontwikkeld voor luchtvaartmaatschappijen en stond vroeger ook bekend als Airline Control Program. ♦ z/VM, dit is een OS dat het dynamisch aanmaken en verwijderen van virtuele machines softwarematig toelaat. z/VM verschilt van LPAR’s met het feit dat z/VM softwarematig werkt en LPAR’s ingesteld worden in de microcode. (EBBERS, e.a., 2005:42-44) 2.3.4

Datasets

Een dataset is een collectie van logisch gerelateerde records die bewaard worden op één volume of een set van volumes. Een dataset is vergelijkbaar met een bestand op een PC. Bij het aanmaken van een dataset moeten we vooraf opgeven hoe groot de dataset maximaal gaat worden. Dit kan gebeuren aan de hand van het aantal bytes, het aantal tracks of zelfs het aantal cylinders van één of meerdere volumes. Één track staat hierbij gelijk aan 56664 bytes en één cylinder bestaat uit 15 tracks. Een volume is hierbij ook bekend als een DASD (Direct Access Storage Device), meestal van het type 3390-3. De adressering van een volume gebeurt hexadecimaal. Een volume dat STORMGT als volumenaam heeft kan bijvoorbeeld het adres 3A28 hebben. Bij z/OS wordt er niet gewerkt met een “New Line” of “Carriage Return” teken op het einde van een regel zoals bij andere besturingssystemen het geval is. Er wordt gewerkt met fixed of variable lengtesysteem. Hierbij wordt bepaald wat de lengte van één regel (of record) is. Bij het variable systeem wordt er voor elke regel een record descriptor geplaatst waarin de lengte staat. In praktijk werkt men vaak met vaste lengte van 80 tekens. De naamgeving van een dataset gaat als volgt: XXXXXXXX.YYYYYYYY.ZZZZZZZZ.AAAAAAAA.BBBBBBBB

Een dataset kan dus maximaal uit vijf delen bestaan en elk deel mag maximaal acht tekens groot zijn en niet beginnen met een cijfer of een speciaal teken zoals /, \, %, _, … Enkele voorbeelden van correcte namen zijn dan ook: VINF3CUC.UITWIJK.CODE, STORMGT.JCLCODE, … Een traditionele structuur met mappen is niet gekend en er is ook geen equivalent onder z/OS. Een uitzondering hierop is een PDS (Partitioned Dataset), ook soms een library genaamd. Een PDS is een deel dat voorzien wordt om er sequentiële deelbestanden (members) in te plaatsen. Er kan slechts één niveau van members in een PDS zitten, een PDS in een PDS is niet mogelijk. Een member wordt aangeduid tussen ronde haken, bijvoorbeeld: XXXXXXXX.PDS(MEMBER)

(EBBERS, e.a., 2005:115-123)

21

2.3.5

VTOC en CATALOG

Het eerste record van elk volume bevat de Volume Table of Contents (VTOC) waarin de namen van alle datasets van het volume staan. De grootte en de locatie van de VTOC wordt bepaald met het programma ICKDSF. Dit programma wordt onder andere gebruikt in het back-up proces dat verder in mijn eindwerk beschreven staat. Het spreekt voor zich dat meerdere datasets op een volume een grotere VTOC vragen. (EBBERS, e.a., 2005:123-124) Om een dataset te vinden moet je de naam weten van de dataset, het volume waarop het zich bevindt en welk type volume (meestal 3390-3). In z/OS is er een systeem ontwikkeld om te weten waar een dataset staat door het in een speciale database te plaatsen. Deze database is bekend als “the catalog”. Dankzij het CATALOG-systeem kunt u met alleen de naam een dataset benaderen. Men kan ook datasets bewust niet opnemen in deze catalogus wanneer dat niet nodig is. (EBBERS, e.a., 2005:124-126) 2.3.6

TSO/E

Het Time Sharing Option/Extensions (TSO/E) systeem laat gebruikers toe om een interactieve sessie met het z/OS besturingssysteem op te starten. Het z/OS besturingssysteem kent namelijk twee manieren om programma’s uit te voeren en te verwerken. Enerzijds online door middel van TSO/E, anderzijds met behulp van batch jobs (hierover later meer). De TSO/E-omgeving is een Command Line Interface (CLI). Het aanmaken, openen en benaderen van datasets gebeurt hier. In praktijk wordt TSO/E echter zelden gebruikt. Men werkt vaak met programma’s die een interface naar TSO/E aanbieden zoals ISPF. (EBBERS, e.a., 2005:79-84) 2.3.7

ISPF

ISPF (Interactive System Productivity Facility) is een programma dat een interface aanbiedt naar TSO/E toe en alles transparant regelt. Alle acties van de gebruiker in ISPF worden vertaald naar TSO/E en vice-versa. ISPF is een bijzonder uitgebreid en zeer functioneel programma. Het biedt onder meer ondersteuning voor het bekijken, aanmaken, bewerken, verwijderen, hernoemen, kopiëren, verplaatsen en aanpassen van parameters van datasets. De werking van ISPF kan verduidelijkt worden aan de hand van “Figuur 2-7 Overzicht ISPF menu”.

22

Figuur 2-7 Overzicht ISPF menu Het schrijven van alle code voor dit eindwerk gebeurde met de editor van ISPF. (EBBERS, e.a., 2005:84-101) 2.3.8

JCL en JES

Zoals eerder vermeld is het naast het werken met een interactieve sessie via TSO/E ook mogelijk om met batch jobs te werken. Een batch job is vaak een job die dagelijks, wekelijks of maandelijks dient te gebeuren en die zo min mogelijk draait wanneer er reeds interactieve sessies bezig zijn. De overschotten aan berekeningskracht worden gebruikt voor het uitvoeren van deze batch jobs. Vaak gebeuren deze jobs ook ’s nachts.

23

JES (Job Entry System) is een spooling systeem voor alle jobs. Elke batch job komt hier terecht. De Initiator van z/OS bepaalt een aantal zaken: ♦ ♦ ♦ ♦

Welke jobs eerst uitgevoerd moeten worden aan de hand van prioriteiten. Hoeveel cyclussen elke job toegewezen krijgt. Wanneer datasets toegewezen kunnen worden en wanneer ze terug vrijkomen. …

Om al deze beslissingen te kunnen nemen wordt er JCL-code gebruikt. In deze Job Control Language (JCL) vertelt u aan het systeem op voorhand welke datasets u nodig hebt en welke programma’s gebruikt worden en hun parameters. z/OS gebruikt bij het koppelen van datasets aan programma’s een symbolisch systeem (zie “Figuur 2-8 Symbolische koppeling dataset namen”). Het zorgt voor automatische hernoeming en naamkoppeling van datasets in het programma tegenover de echte datasets.

Figuur 2-8 Symbolische koppeling dataset namen Hieronder geef ik enkele labels die vaak gebruikt worden in JCL-code en hun betekenis. ♦

♦

♦

JOB: Het label JOB specificeert het beginnen van een job. Mogelijke parameters zijn bijvoorbeeld de gebruiker waaronder de job moet uitgevoerd worden (USER), de klasse van de job (CLASS) en de uitvoerklasse (MSGCLASS). EXEC: Het label EXEC wordt gebruikt om het programma dat gebruikt wordt in een stap van een job aan te duiden. Parameters zoals PARM, voor parameters aan het programma door te geven, zijn mogelijk. DD: Data Definition is de label die gebruikt wordt om de fysieke datasets te koppelen aan die van het programma (zie “Figuur 2-8 Symbolische koppeling dataset namen”). Er zijn verschillende parameters zoals de dataset naam (DSN), het volume (VOL=SER), de aard van gebruik zoals alleen lezen of schrijven(DISP) en nog veel meer mogelijk.

24 000001 000002 000003 000004 000005 000006

//TEST JOB ,'STG0917',NOTIFY=&SYSUID,CLASS=L,MSGCLASS=T //REXX EXEC PGM=IKJEFT01 //SYSTSPRT DD DSN=STG0917.DEMO,DISP=SHR //SYSTSIN DD * EXEC 'STG0917.REXTEST' /*

Figuur 2-9 Voorbeeld JCL-code Een voorbeeld van JCL-code ziet u in “Figuur 2-9 Voorbeeld JCL-code”. Op de eerste regel vindt u het label JOB terug. De job heet “TEST” en wordt uitgevoerd door STG0917 met CLASS L en MSGCLASS T. Daaronder staat de naam van de stap “REXX” en het programma IKJEFT01. Hier ziet u een duidelijk praktijkvoorbeeld van de symbolische koppeling van datasets. Het programma IKJEFT01 heeft namelijk de dataset SYSTSPRT nodig, maar op regel 3 koppelt u SYSTSPRT simpelweg aan STG0917.DEMO. Met als parameter DISP=SHR, dit wil zeggen SHaRe. Een dataset met SHR kan gedeeld en gelezen worden door verschillende processen tegelijk, zolang deze allemaal de dataset met de SHR parameter oproepen. (EBBERS, e.a., 2005:157-162; INTERNATIONAL BUSINESS MACHINES CORPORATION, 2004: 47-83) 2.3.9

SDSF

SDSF (System Display and Search Facility) is een interface naar JES toe. Met behulp van SDSF kunnen we de JES uitvoer bekijken en bewerken. Net zoals ISPF werkt SDSF met een handige menu interface. (EBBERS, e.a., 2005:165-169).

25 Display Filter View Print Options Help ------------------------------------------------------------------------------SDSF DA PROD PROD PAG 0 SIO 737 CPU 45/ 44 LINE 1-19 (316) COMMAND INPUT ===> SCROLL ===> CSR NP JOBNAME CPU% ASID ASIDX EXCP-Cnt CPU-Time SR Status SysName SPag SCP *MASTER* 0.37 1 0001 56,532 2213.41 PROD 0 PCAUTH 0.00 2 0002 16 0.04 PROD 0 RASP 0.05 3 0003 2 128.40 PROD 0 TRACE 0.00 4 0004 29 0.05 PROD 0 DUMPSRV 0.00 5 0005 310 0.13 PROD 0 XCFAS 0.05 6 0006 793,676 479.25 PROD 0 GRS 0.00 7 0007 22 101.35 PROD 0 SMSPDSE 0.00 8 0008 4,860 94.52 PROD 0 CONSOLE 0.14 9 0009 36,147 351.65 PROD 0 WLM 0.55 10 000A 28 1772.31 PROD 0 ANTMAIN 0.00 11 000B 199 5.59 PROD 0 ANTAS000 0.00 12 000C 284 0.21 PROD 0 OMVS 0.00 13 000D 488 16.02 PROD 0 JESXCF 0.00 15 000F 389 13.17 PROD 0 ALLOCAS 0.00 16 0010 5 0.11 PROD 0 IOSAS 0.00 17 0011 128 27.20 PROD 0 IXGLOGR 0.00 18 0012 645,716 4854.17 PROD 0 ACF2 0.00 19 0013 14,347 2.83 PROD 0 SMF 0.05 20 0014 821 44.15 PROD 0

Figuur 2-10 Overzicht processen in SDSF U kunt in “Figuur 2-10 Overzicht processen in SDSF” duidelijk zien dat SDSF een directe interface vormt naar JES2. Als u details opvraagt van een job krijgt u uitvoer te zien zoals “Figuur 2-11 Voorbeeld JES2 uitvoer in SDSF”. ********************************* TOP OF DATA ********************************** J E S 2 J O B L O G -- S Y S T E M P R O D -- N O D E 1 //A1130LEI JOB (V902320,3344), /* ACCOUNT# OF USER ADDED */ // 'LEVEN INDIVIDUEEL',CLASS=S,MSGCLASS=T //* $ACFJ219 ACF2 ACTIVE VADJES2 //******************************************************************** //*** ALLOCEREN BIJKOMENDE TESTPUNTEN //******************************************************************** 2 //LAND OUTPUT PAGEDEF=C06181,FORMDEF=B00110 //******************************************************************** //* ALLOCEREN PERMANENTE DATASETS //******************************************************************** 3 //IEFBR14P EXEC PGM=IEFBR14,TIME=(,10) 4 //DD1 DD DSN=&&LEVEN,DISP=(,PASS), // UNIT=SYSDP,SPACE=(TRK,(5,5),RLSE), // DCB=(RECFM=FB,LRECL=100,BLKSIZE=27800) 5 //CULPRIT1 EXEC CULPROD 6 XXCULPROD PROC REG=3072K,CV=DC, XX PRMSP6=20,SECSP6=10,PRMSP8=20,SECSP8=10,SRTSP=15 XX* 7 XXCULPRIT EXEC PGM=CULPRIT,REGION=® IEFC653I SUBSTITUTION JCL - PGM=CULPRIT,REGION=3072K 8 XXSTEPLIB DD DSN=IDMS&CV..DBA.LOADLIB,DISP=SHR IEFC653I SUBSTITUTION JCL - DSN=IDMSDC.DBA.LOADLIB,DISP=SHR 9 XX DD DSN=IDMS.G4.LOADLIB,DISP=SHR ...

Figuur 2-11 Voorbeeld JES2 uitvoer in SDSF

26

2.3.10

IPL

IPL of Initial Program Load is het laden van systeem instellingen van z/OS van een vooraf gedefinieerd volume. IPL is vergelijkbaar met een warme herstart van het systeem.

27

2.4

Timefinder principes

Om een exacte kopie van data te kunnen maken op één bepaald moment in de tijd zijn verschillende oplossingen bedacht, zowel binnen IBM (FlashCopy) als bij EMC (TimeFinder) en Hitachi (Shadow-Image). De Symmetrix 8830 machine gebruikt in combinatie met de z/890 het Timefinder systeem om back-ups te nemen op één bepaald moment in de tijd. Een deel van mijn stageopdracht gaat over het back-up proces. Ik leg hierbij alvast enkele principes van Timefinder uit. De Symmetrix 8830 heeft twee keer zoveel opslagcapaciteit als er nodig is. We kunnen de harde schijven binnen de Symmetrix machine virtueel koppelen door middel van een ESTABLISH commando. Dit commando zal een verbinding tussen de twee schijven leggen en de data synchroniseren zodat op beide harde schijven identieke data terug te vinden is. Als één schijf wijzigt, wijzigt de andere onmiddellijk mee. Als een ESTABLISH gedaan is en de schijven zijn volledig gesynchroniseerd kunnen we een SPLIT commando sturen. De gekoppelde schijven zullen elkaar “loslaten”. De originele schijf wordt nu verder gebruikt en de andere heeft een kopie van de data op een vast moment in de tijd. Zie ook “Figuur 2-12 TIMEFINDER principes”. Origineel

Back-up volume

Opmerkingen

ESTABLISH

Origineel ≠ Back-up volume

SPLIT

Origineel = Back-up volume

RE-ESTABLISH

Origineel ≠ Back-up volume na de SPLIT

Figuur 2-12 TIMEFINDER principes De kopie kunnen we nu gebruiken om de data op tape te schrijven. Synchroniseren met een andere site gedurende de nacht kan even goed. Dit kan gebruikt worden als er een trage verbinding tussen de verschillende sites ligt die een “live-synchronisatie” niet zou aankunnen. Dit principe noemt Symmetrix Remote Data Facility (SRDF) en wordt verduidelijkt in “Figuur 2-13 Symmetrix Remote Data Facility”.

28

EMC Symmetrix 8830 1

EMC Symmetrix 8830 2

TimeFinder origineel

kopie Trage WANverbinding

Remote kopie

Figuur 2-13 Symmetrix Remote Data Facility Een dag later kan het commando RE-ESTABLISH uitgevoerd worden om de verbinding tussen de twee harde schijven te herstellen en verder te synchroniseren. Dit gaat vrij snel indien er weinig data veranderd is tegenover de vorige dag. (EMC CORPORATION, 2004:80-88)

29

3

TAAKOMSCHRIJVING OPDRACHT DRP

3.1

Achtergrondinformatie

Het Disaster Recovery Plan van IIB (ING Insurance) voorziet dat, in het geval van een ramp (disaster), binnen de 48u het systeem terug operationeel moet zijn op een alternatieve locatie. In het ING-gebouw ”Sint-Michielswarande” in Brussel bevindt zich de z/890 IBM-mainframe van ING België die gebruikt wordt door IIB. Elke nacht worden op de mainframe back-up jobs uitgevoerd die alle data van de IIBomgeving op tape zet. De LPAR (Logical Partition) waarin IIB werkt op het mainframe noemt: “Prod”. De tapes worden bewaard in de tapekluis. Ze kunnen gebruikt worden om binnen de 48u een volledige system restore in het ING-gebouw “Wilgenplas” te Rotterdam uit te voeren. Wilgenplas wordt in dit eindwerk ook het uitwijkcentrum genoemd. De Belgische IBM-mainframe is point-to-point aangesloten met de EMC² 8830 Symmetrix voor zijn dataopslag (zie paragraaf 2). Aan het mainframe is eveneens een IBM-tapelibrary aangesloten voor de dagelijkse back-ups. Het probleem van de dagelijkse back-ups is dat men hiervoor de Prod-omgeving moet stoppen. Anders is er sprake van inconsistente data als er naar tape wordt gekopieerd terwijl de Prod-data nog volop wijzigt. Het kopiëren op tape neemt ongeveer vijf uren in beslag en deze downtime is onaanvaardbaar.

IBM Mainframe Kloon

Test

IFSA

Prod EMC² Symmetrix 8830

IBM Tapelibrary 3494

timefinder

... Address range: 8xx xxx Tapedrives: IBM 3590-E

± 1 TB (Prod) (350x3390-3) Address range: 3xxx Vol. Names: xxxxxx

± 1 TB (Backup) (350x3390-3) Address range: 5xxx Vol. Names: BCVxxx

...

Figuur 3-1 Werking back-up systeem IBM-mainframe

30

Het kopiëren gebeurt daarom vanuit een andere verzameling van volumes (back-up volumes). Omstreeks 16u wordt er een back-up-link gelegd (ESTABLISH) tussen de productie- en back-upvolumes. De Symmetrix 8830 synchroniseert de data van productie met die van backup (enkel wijzigingen worden aangepast, niet alles wordt volledig gekopieerd). Tussen 0u en 2u zal de mainframe alle processen en batch jobs die draaien stoppen om vervolgens de backup-link los te koppelen(SPLIT). Dit alles werkt met de Timefinder software van EMC². Op dat moment is er een exacte gesynchroniseerde kopie van productie van één bepaald moment op de backup-volumes. Het mainframe zal dan een IPL uitvoeren en alle processen en batch jobs opnieuw starten. Dit gebeurt in een zo kort mogelijke tijd om de downtime van het systeem beperkt te houden. Daarna wordt alle data van de backup-volumes gekopieerd naar de IBM-tapelibrary.

31

3.2

Uitwerking van dit proces

Het proces wordt praktisch uitgevoerd door een verzameling batch jobs. 3.2.1

Stap 1: 16u

3.2.1.1

Inventarisatie volumes

Met het DCOLLECT-commando wordt de volume-informatie opgevraagd van het systeem. Er zijn ongeveer 350 x IBM 3390-3 (± 2,8Gb = één volume) productie volumes geëmuleerd op de Symmetrix machine. Het DCOLLECT-commando geeft dan alle volumes weer, ook die van bijvoorbeeld de backupvolumes. Dit wordt uitgevoerd door job B8D200A. 3.2.1.2

Selectie volumes en generatie commando’s

De DCOLLECT informatie wordt ingelezen in het SAS-programma B8D20010 door job B8D200B. Hierna worden de volumes geselecteerd waarvan een back-up dient gemaakt te worden. Van lege volumes hoeft bijvoorbeeld geen back-up gemaakt te worden. Voor elk van de volumes worden vervolgens commando’s gegenereerd om de relatie met het overeenkomstige back-upvolume te leggen en te verbreken. Ook commando’s om de volumes te activeren en te deactiveren worden eveneens aangemaakt (VARY OFFLINE en VARY ONLINE). Dit gebeurt omdat de koppeling alleen maar kan gelegd en verbroken worden als het back-upvolume niet beschikbaar is voor andere gebruikers buiten het systeem zelf. 3.2.1.3

Wegschrijven commando’s

De commando’s die door B8D20010 werden aangemaakt worden door job B8D200C (en bijhorend programma B8D20020) weggeschreven in een PDS (Partitioned Data Set) met 50 commando’s per PDS-member. Hierna wordt door het tweede programma B8D20030 van job B8D200C de JCL (Job Control Language) code aangemaakt om de back-ups naar tape te zetten. Al deels bestaande REXX varianten bij het beginnen van de opdracht: ♦ B8D30020 (vergelijkbare functionaliteit met B8D20010) ♦ B8D30030 (voor het aanmaken van de mapping tussen de verschillende back-up en productie volumes) ♦ B8D30040 (commando’s aanmaken voor de relaties te leggen tussen productie en backup, de commando’s en de JCL code voor de back-ups wegschrijven)

32

3.2.2

Stap 2: 0u → 2u

3.2.2.1

Systeem stoppen

Het systeem, alle draaiende processen en batch jobs worden afgesloten. Nu komt er geen data meer bij in het systeem en is de synchronisatie tussen productie en back-up volledig. Op dit moment wordt ook de SPLIT van de volumes uitgevoerd. 3.2.2.2

IPL (Initial Program Load) wordt uitgevoerd

Dit is vergelijkbaar met het systeem herstarten zoals in paragraaf 2.3.10 werd uitgelegd. 3.2.2.3

Kopiëren van back-upvolumes naar tape

De back-upvolumes worden in hun geheel naar tape gekopieerd. Er worden geen volumes gesplitst (spanned) over verschillende tapes. Per dag is er één set van ongeveer tien tapes nodig voor een back-up. De TLMS-database houdt bij welke volumes zich op welke tape bevinden en fungeert als index. CADynam/TLMS is een product van Computer Associates dat voor tapemanagement dient. Deze informatie wordt bewaard in een VMF dataset met bijvoorbeeld volgende data erin: 800 001 → Backup.USR001 (corresponderend met BC2391) 17/04/2004 → Backup.USR002 (corresponderend met BC1215) 17/04/2004 → Backup.USR003 (corresponderend met BC0116) 17/04/2004 →… 800 002

→ Backup.USR017 (corresponderend met BC0124) →…

17/04/2004

Job B8D050A voert twee SAS-programma’s uit, genaamd B8D05010 en B8D05020. B8D05010 zorgt voor het inlezen van het VMF dataset en het selecteren van de recentste back-up. B8D05020 maakt de JCL code voor de herstellingsjobs aan. 3.2.2.4

Wegschrijven JCL herstellingsjobs

De JCL-code voor de herstellingsjobs wordt eveneens weggeschreven op een tape. Job B8D050B zorgt hiervoor. 3.2.2.5

Opzoeken tape met herstellingscode

Het SAS-programma B8D05030 (van Job B8D050C) leest de VMF-dataset in en zoekt naar de tape waarop de JCL-code voor de herstellingsjobs staat. Deze tape heeft meestal de naam VINF3CUC.UITWIJK.

33

3.2.2.6

Opsturen bericht naar beheerders

Via job B8D050D wordt een mail gestuurd naar de beheerders om te melden dat de back-up afgelopen is. Hierbij zit een rapportje met informatie over de uitgevoerde IPL, de nummers van de tapes die gebruikt werden en ook het nummer van de tape met de JCL code voor de herstellingsjobs.

34

3.3

Concrete opdrachtomschrijving

Controleren en optimaliseren van de eerste reeks REXX-programma’s (B8D30020, B8D30030, B8D30040) en aanmaken van REXX programma’s en hun bijhorende JCL’s om de SAS-programma’s B8D05010, B8D05020 en B8D05030 te vervangen.

3.4

Uitwerking opdracht

In dit gedeelte wordt de uitwerking van de opdracht rond de Disaster Recovery Procedure (DRP) beschreven. De volledige broncode van de bijhorende scripts en JCL-codes vindt u terug in de bijlagen. 3.4.1

Overzichtsschema

Hierbij vindt u in “Figuur 3-2 Overzicht DRP-ketting”een overzichtsschema van de REXXbatch jobs zoals ze nu in productie draaien samen met hun resources en programma’s.

35

36

VINF0PRD.BLVB04.B8D300.BACKVOLS

B8D310-reeks

B8D320A VINF3WVB.BATCH.REXX(B8D32010)

BACKUP_PFX = ‘BACKUP.’ BACK = ‘8’ HOUR_NOW = ‘NOW’ REQ_DATE = ‘NOW’ REQ_LOC = ‘CZ’

SYS4.CAI.TLMS.VMF

VINF0PRD.BLVB04.B8D320.VOLSER1

B8D320B VINF3WVB.BATCH.REXX(B8D32020)

VINF0PRD.BLVB04.B8D320.RSTORJCL

NUMBER_VOLS_TAPE = ‘35’ JOBCONTROLPARAMS = ‘JOB T,JC,CLASS=N, MSGCLASS=T,TYPRUN=HOLD’

B8D320C VINF3CUC.JCLDUMP

B8D320D VINF3WVB.BATCH.REXX(B8D32010)

BACKUP_PFX = ‘VINF3CUC.JCLDUMP’ BACK = ‘10’ HOUR_NOW = ‘NOW’ REQ_DATE = ‘NOW’ REQ_LOC = ‘CZ’

VINF0PRD.BLVB04.B8D320.VOLSER2

VINF0PRD.BLVB04.B8D320.VOLSER

B8D320E SENDMAIL E-Mail header + body

Figuur 3-2 Overzicht DRP-ketting Zoals u ziet is deze batch job ketting zeer lang en complex. In de volgende hoofdstukken wordt verder ingegaan op de jobs. Ik zal eveneens een korte omschrijving geven van de jobs waar ik niet voor verantwoordelijk was.

37

3.4.2

B8D300A

Dit is de eerste job die omstreeks 16u wordt uitgevoerd. B8D300A zal met een DCOLLECT commando de volume informatie van alle volumes voor de PROD-LPAR opvragen en in de dataset VINF0PRD.BLBV04.B8D300.DCOLLECT plaatsen. 3.4.3

B8D300B

B8D300B start het REXX-programma VINF3WVB.BATCH.REXX(B8D30020) op. Dit programma zal VINF0PRD.BLVB04.B8D300.EXCLDATA inlezen om te kijken welke volumes er niet moeten meegenomen worden voor de back-up. In EXCLDATA bevindt zich een hele structuur om aan te duiden welke volumes (of eventueel een heel bereik van verschillende volumes) niet mee in de back-up geplaatst moeten worden. Dit uitsluiten kan ook gebeuren op basis van de naam van volumes of op basis van een deel van hun naam (zie “Figuur 3-3 Structuur EXCLDATA”) 000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020 000021 000022 000023 000024 000025 000026 000027 000028 000029 000030 000031 000032 000033 000034 000035 000036 000037 000038 000039

/* THIS MEMBER PROVIDES A SAMPLE CONFIGURATION FOR THE DRP-BACKUP /* EXCLUSION LIST, WHICH IS BEING READ BY THE BACKUPJOB GENERATION REXX. /* --------------------------------------------------------------------/* EXCLUSION SYNTAX /* COLUMN 1 : INDICATES WHAT TYPE OF EXCLUSION IS DONE /* / = TREAT THIS LINE AS COMMENTS /* - = TREAT THE NEXT 6 CHARACTERS AS THE VOLSER TO /* BE EXCLUDED /* * = TREAT THE NEXT 1 UP TO 6 CHARACTERS AS A MASK OF /* ALL THE VOLUMES TO BE EXCLUDED /* S = TREAT THE NEXT 30 CHARACTERS AS THE NAME OF A /* SMS STORAGEGROUP /* D = TREAT THE NEXT 8 CHARACTERS AS THE HEXADECIMAL /* DEVICE NUMBER RANGE TO EXCLUDE /* !!! THE USE OF OTHER CHARACTERS IN COLUMN 1 AS THE ONES SPECIFIED /* WILL BE TREATED AS FAULTY. THIS CONSEQUENCES THE FAULTY LINE /* TO BE SKIPPED. /* COLUMN 2-31: CAN BE USED TO INDICATE THE VOLSER, OR A PART OF IT /* DEPENDING ON THE TYPE OF EXCLUSION. /* COLUMN 32-80:CAN BE USED FOR ADDITIONAL COMMENTS. /* /* EXAMPLES: COLUMN /* 123456789012345 /* ||||||||||||||| /* 1) /TEST ==> WILL BE TREATENED AS COMMENTS /* 2) -VTEST1 ==> VOLUME TO BE SKIPPED: VTEST1 /* 3) *USR ==> ALL VOLUMES STARTING WITH USR WIL /* BE SKIPPED. /* 4) SSGUSR ==> STORAGEGROUP TO EXCLUDE: SGUSR /* 5) D30003100 ==> ADRESS RANGE TO EXCLUDE: 3000->31 /* START OF EXCLUSION LIST /* --------------------------------------------------------------------/23456789012345678901234567890123456789012345678901234567890123456789012 /||||||||||||||||||||||||||||||------------------COMMENTS--------------D40005FFF -STOR01 *SH SSGPRL *--

Figuur 3-3 Structuur EXCLDATA

38

In B8D30020 worden vervolgens ook de DCOLLECT gegevens van B8D300A ingelezen. Op basis daarvan genereert het programma VINF0PRD.BLVB04.B8D300.BACKLIST. Deze dataset bevat dan een lijst van de volumes die gebruikt mogen worden in het back-up proces. 3.4.4

B8D300C

Het programma VINF3WVB.BATCH.REXX(B8D30030) dat door deze job wordt opgeroepen leest geen datasets in, maar accepteert wel verschillende parameters. De parameters STDDEVS en STDDEVE worden gebruikt om het beginadres en het eindadres van de originele volumes van de PROD-LPAR op te slagen. Hetzelfde geldt voor BCVDEVS en BCVDEVE voor de back-up volumes. De CUPSAVST parameter is een speciaal geval. Ondanks de enorme I/O capaciteit van de z/890 machine kan het gebeuren dat één volume enorm veel wordt benaderd door verschillende gebruikers. In z/OS zal een Workload Manager dit opmerken en automatisch zoveel virtuele volumes toekennen op andere adressen als er nodig zijn voor de I/O opdrachten. Dit principe noemt PAV of Parallel Access Volumes. Met behulp van CUPSAVST bepaalt u de grens tussen de echte volumes en deze alias of virtuele volumes. Die grens ligt op het hexadecimale getal “90”. Dat houdt in dat alle echte volumes bijvoorbeeld van 3000 tot 308F gaan. Volumes vanaf 3090 in het 30xx-bereik worden gebruikt als tijdelijke alias adressen. Dit voorbeeld wordt in “Figuur 3-4 Illustratie werking CUPSAVST parameter” nog eens extra geïllustreerd. 3000 – 308F

I/O opdrachten

3090 – 30FF

extra I/O opdrachten

3000

3001

3002

3090

3091

3092

3003

…

308F

3093

…

30FF

CUPSAVST = '90'

Figuur 3-4 Illustratie werking CUPSAVST parameter Op basis van die bereiken van volumes kan het programma verschillende datasets creëren die de Timefinder commando’s bevatten om de volumes onderling te verbinden (ESTABLISH), de verbinding te verbreken (SPLIT) en de verbinding te herstellen (RE-ESTABLISH). Eveneens wordt er een mapping aangemaakt. Dit is een overzicht van de corresponderende adressen. 3000 is bijvoorbeeld met 5000 verbonden.

39

3.4.5

B8D300D

B8D300D en het REXX-programma VINF3WVB.BATCH.REXX(B8D30040) hebben als doel de data uit B8D300B en B8D300C te combineren en te verwerken. B8D30040 leest de mapping van de volumes in (VINF0PRD.BLVB04.B8D300.MAPPING) en ook de lijst van de volumes waar een back-up moet van gemaakt worden (VINF0PRD.BLVB04.BACKLIST). Het programma genereert vervolgens de dataset VINF0PRD.BLVB04.MERGLIST, die bevat net zoals de MAPPING dataset een overzicht van de verbonden volumes. De overeenkomstige volumenamen hier eveneens geplaatst. Bijvoorbeeld 3000 SONL02 met 5000 BC5000. In de PDS VINF0PRD.BLVB04.COMMANDS worden members geplaatst die de SPLIT, ESTABLISH, en RE-ESTABLISCH commando’s bevatten. In VINF0PRD.BLVB04.BACKJOBS worden de jobs gecreëerd die alle data op tape zal plaatsen vanaf de back-up volumes. De dataset VINF0PRD.BLVB04.B8D300.BACKVOLS, die ook door het programma wordt weggeschreven, is een dataset die later in de ontwikkeling is toegevoegd. Deze dataset bevat de lijst (naam en adres) van volumes waarvan een back-up wordt genomen samen met hun nummering. Bijvoorbeeld: 3008 SONL01 is het 9e volume dat op de eerste tape geplaatst wordt. De inhoud van vele voorgenoemde datasets wordt bepaald door verschillende parameters die meegegeven kunnen worden in B8D300D. CMDSMEM bepaalt per member in de COMMANDS dataset hoeveel commando’s er in de member mogen. Als er meerdere commando’s zijn, dan wordt een volgende member aangemaakt. Standaard staat de CMDSLMEM waarde op 50. LABLCAR bepaalt hoeveel volumes er op één tape mogen geplaatst worden. Deze waarde is standaard 35. RETPERD regelt de retentietermijn van de datasets. Dit wil zeggen het aantal minuten dat een ze opgeslagen mogen worden. Met behulp van BACKDSN wordt de prefix van de naam van elke tape bepaald. De parameter BACKDSN is meestal ingesteld op ‘BACKUP’. Dit resulteert bijvoorbeeld in een tape die BACKUP.SONL02 heeft. Voor het tweede deel van de naam wordt altijd de naam van het eerste volume op die tape genomen. Met de parameter BACKUNI wordt de back-up unit doorgegeven die verwerkt moet worden in de back-up commando’s. De back-up units die gebruikt worden zijn van het type 3590-1. BCVPREF bepaalt de prefix van de back-up volumenamen. De back-up volumenamen worden opgebouwd uit deze prefix en hun adres. Hier wordt de prefix ‘BC’ gebruikt. In combinatie met het adres 5000 zal de volumenaam van het back-up volume BC5000 worden. Indien we voor het eerst een verbinding leggen tussen de originele en de back-up volumes moet voor TFETYPE de waarde ‘ES’ gebruikt worden van ESTABLISH. In normale

40

dagelijkse omstandigheden wordt het TFETYPE op ‘RE’ geplaatst van RE-ESTABLISH. TFETYPE bepaalt welke commando’s moeten uitgevoerd worden. 3.4.6

B8D300E

Deze job zal een deel van de PDS met commando’s uit de vorige job doorsturen naar JES, zodat de commando’s uitgevoerd worden op het systeem. Dit deel van de commando’s heeft als doel om alle back-up volumes als het ware virtueel uit te schakelen in het systeem zodat geen enkel proces de volumes nog kan bereiken en er dus geen data meer kan worden aangepast. Dit uitschakelen gebeurt met het commando “VARY OFFLINE”. 3.4.7

B8D300F

B8D300F doet hetzelfde als B8D300E en zal een volgend deel van de commando’s doorsturen naar JES. Door deze nieuwe serie commando’s zullen de verbindingen hersteld worden (“RE-ESTABLISH”). 3.4.8

B8D300G

Deze job zorgt ervoor dat alle commando’s voor het kopiëren naar tape in een productieformaat worden opgemaakt zodat men ze onder controle van de Tivoli Workload Scheduler (TWS) kan uitvoeren. 3.4.9

B8D300H

Naast back-ups van verschillende volumes heeft men op het uitwijkcentrum ook nog tijdelijke volumes nodig voor de werking van het systeem en dergelijke. Hiervoor levert men een HCDdataset telkens er wijzigingen in het uitwijkcentrum gebeuren. B8D300H heeft als doel om deze HCD-dataset in te lezen en bijvoorbeeld te bepalen of er voldoende volumes beschikbaar zijn in het uitwijkcentrum. Als dat niet het geval is, dan moet dit gemeld worden. B8D300H gebruikt hiervoor het REXX-programma B8D30080 dat ik heb ontwikkeld. De vorige programma’s (B8D30020,B8D30030 en B8D30040) waren deels gemaakt door mijn stagebegeleider dhr. Filip Van Gorp. Ik heb daaraan slechts enkele aanpassingen gedaan. Nadat de nodige controles zijn uitgevoerd over de beschikbaarheid zal deze job nog JCL-code aanmaken met initialisatie instellingen. Met die JCL-code kan men dan makkelijk het herstellen van een back-up voorbereiden. De naamgeving van bepaalde volumes is op voorhand ingesteld in het uitwijkcentrum. 3.4.10

B8D310x-Reeks

Dit is de verzameling van jobs die de back-ups op tape zal schrijven.

41

3.4.11

B8D320A

Na de vorige job zijn alle back-upvolumes op tape geplaatst. Nu begint de moeilijke taak om te bepalen welke tapes juist gebruikt zijn. Daarna kunnen de tapes verwijderd worden uit de IBM-tapelibrary en veilig gestockeerd worden in een kluis op een andere locatie. Voor dit alles wordt het REXX-programma B8D30010 gebruikt. Deze job gebruikt verschillende parameters zoals BACKUP_PFX waarin de back-up prefix wordt bepaald voor de tapes (standaard “BACKUP.”). Een andere parameter is HOUR_NOW. Hier kan je doorgeven vanaf welk uur in de tijd je terug wilt gaan om de tape te zoeken. Standaard is deze waarde ingesteld op “NOW”, maar dit kan ook een uur zijn zoals “12”. De waarde gaat van 0 tot 23. BACK

24u

eergisteren

24u

gisteren

REQ DATE

24u

vandaag

24u

HOUR_NOW

Figuur 3-5 Parameters B8D320A Met de parameter REQ_DATE wordt bepaald vanaf welke datum er terug moet gezocht worden in de tijd naar de tapes. Normaal staat deze waarde ook op “NOW”. Als u wilt zoeken naar de tapes die vorige week werden gemaakt hoeft u slechts de datum van vorige week in te geven in REQ_DATE in de vorm “dd/mm/yy”. Met BACK worden het aantal uren bepaald dat het systeem moet teruglopen om te zoeken naar back-up tapes. Zoals “Figuur 3-5 Parameters B8D320A” duidelijk illustreert is dit de teruglooptijd. Deze tijd kan vanzelfsprekend over meerdere dagen lopen. In het vorige voorbeeld, waar u zocht naar de tapes van vorige week, kunt u in BACK “168” ingeven. Zo zal het programma 7-dagen teruglopen vanaf de REQ_DATE en HOUR_NOW van de REQ_DATE. Als laatste parameter wordt REQ_LOC meegegeven. In normale omstandigheden is dit “CZ” of de computerzaal, maar als u zoekt naar de tapes van vorige week zal dit waarschijnlijk “F1” zijn. F1 duidt aan dat de tapes verwijderd zijn uit de zaal. De uitvoer van het REXX-programma B8D32010 zal uiteindelijk in VINF0PRD.BLBV04.B8D320.VOLSER1 geplaatst worden. In deze uitvoer is een overzicht van de tapes die gevraagd werden met de parameters. Meestal is dit een dagelijks overzicht van de voorbije nacht.

42 000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011

01 02 03 04 05 06 07 08 09 10 11

800087 800200 800469 800482 800648 800713 800752 800760 800871 800950 801237

BACKUP.PRB005 BACKUP.PRV013 BACKUP.PRV063 BACKUP.SPLP01 BACKUP.PRV043 BACKUP.DB2S03 BACKUP.PRV005 BACKUP.SRI0A3 BACKUP.SLIBS7 BACKUP.DB2S05 BACKUP.SONL09

Figuur 3-6 Voorbeeld inhoud VINF0PRD.BLVB04.B8D320.VOLSER1 De dataset die wordt gebruikt als database door het tapemanagement systeem is SYS4.CAI.TLMS.VMF. Deze wordt geladen door het REXX-programma B8D32010 om de resultaten te berekenen zoals in “Figuur 3-6 Voorbeeld inhoud VINF0PRD.BLVB04.B8D320.VOLSER1”. In de oorspronkelijke SAS-code van de back-up ketting bood SAS verschillende soorten variabelentypes aan zoals Integer, String, Date, Decimal… Hierbij kwam ik op het probleem dat REXX deze verschillende variabelentypes niet kent en slechts overweg kan met de eigen interpretatie van tekenreeksen, getallen en datums. Op de één of andere manier moest ik dus de VMF dataset openen en er de gegevens uithalen. Hier zal ik iets dieper ingaan op de problemen die ik tegenkwam zoals het extraheren van gegevens uit de VMF dataset. 3.4.11.1

Packed Decimal

Één van de formaten die de VMF dataset gebruikt en die door de oude SAS-code perfect kon gelezen worden is Packed Decimal. Op het Internet is er veel informatie te vinden over formaten die gebruikt worden in PC’s of in talen programmeertalen zoals C++. Informatie vinden over een formaat dat op een IBMmainframe gebruikt wordt, bleek niet zo simpel te zijn. Na een lange zoektocht kwam ik te weten dat het Packed Decimal formaat hetzelfde formaat is als Binary Coded Decimal (BCD). Gelukkig was de opbouw van een Binary Coded Decimal iets sneller te vinden.

43

1 byte nibble 0000

nibble 0001

1

0

Figuur 3-7 Opbouw Packed Decimal De werking van een Packed Decimal of BCD is in essentie zeer simpel en valt terug op de stockage van twee cijfers in één byte. Er wordt steeds één nibble (vier bits) per cijfer gebruikt. Zie “Figuur 3-7 Opbouw Packed Decimal” voor een illustratie. Bij nadere controle van het formaat bleek dat er twee formaten van zijn: ♦ 8421-weighting ♦ 2421-weighting Iedereen die het binaire stelsel kent zal vertrouwd zijn met het 8421-weighting formaat. Als u een binaire reeks “1111” neemt, dan is de uiterst linkse één gelijk aan acht, de tweede aan vier, de derde aan twee en de rechtse één staat voor één in het decimale stelsel. Dit is simpelweg het vertrouwde binaire formaat dat gebruikt wordt om getallen op te slagen. 2421-weighting is een ander formaat. De naam verraadt zelf al de opbouw ervan. Als u terug de binaire reeks “1111” neemt, dan is de uiterst linkse één gelijk aan twee, de tweede aan vier, de derde aan twee en de rechtse weer aan één in het decimale stelsel. Indien u met 8421-weighting een getal stockeert, dan is het mogelijk om met een cijfer groter dan negen te werken. Packed Decimals zijn bedoeld om met cijfers te werken in plaats van hexadecimale cijfers en het is duidelijk niet de bedoeling om waarden groter dan negen hexadecimaal te gebruiken. De 2421-weighting is geïntroduceerd om fouten te vermijden. Dit formaat kan niet met cijfers boven de negen werken. Een bijkomend probleem is dat Packed Decimals niet fatsoenlijk kunnen omgaan met kommagetallen. Indien kommagetallen nodig zijn, dan moet de positie van de komma vast staan. Er kan een komma gebruikt worden als bijvoorbeeld altijd met een packed decimal van vijf cijfers wordt gewerkt en de komma steeds tussen het derde en het vierde cijfer voorkomt. Ook voor negatieve getallen of absolute waardes is er een oplossing. Hiervoor wordt altijd een extra nibble achteraan toegevoegd bij de Packed Decimals. Deze nibble wordt ook de sign-nibble genoemd.

44

Eens ik de werking van Packed Decimals begreep kon ik de correcte data eruit halen met de volgende code: 000085 000086 000087 000088 000089

OR_DATE = SUBSTR(VMFLIST.T_VMF,345,4) OR_TIME = SUBSTR(VMFLIST.T_VMF,341,4) DAT_HEX = SUBSTR(C2X(OR_DATE), 1, LENGTH(C2X(OR_DATE)) - 1) DAT_JUL=1000 * (TRUNC(DAT_HEX/100000) * 100 + 1900), + DAT_HEX//100000

Figuur 3-8 Code uitlezen Packed Decimal In regel 85 wordt de datum uit de VMF-dataset gehaald en in een string geplaatst. Deze string wordt omgezet in hexadecimale tekens met de functie C2X die de 8421-weighting volgt. Vervolgens wordt de lengte bepaald, en knip ik de laatste nibble (één hexadecimaal teken) eraf. Met behulp van deze hexadecimale datum (die gelukkig is opgebouwd met 8421weighting) kon ik dan verder werken omdat het hexadecimale resultaat eigenlijk hetzelfde inhoudt als de decimale waarden. Verdere omzettingen zijn overbodig en zelfs foutief. Met behulp van de ingewikkelde formule op regel 88 en 89 heb ik de Juliaanse datum uiteindelijk kunnen bepalen. Gelukkig bood REXX een functie om de Juliaanse datum om te zetten naar de dd/mm/yyyy-standaard. (PAMULA, 2003; HEWLETT PACKARD, 1989:30-32) 3.4.11.2

Packed Decimal Time

Een ander formaat waarmee de SAS-code perfect overweg kon is Packed Decimal Time (PDTIME). Uit voorgaande ervaringen dacht ik te kunnen afleiden dat Packed Decimal Time simpelweg het tijdstip in Packed Decimal formaat was. Na enkele testen kwam ik erachter dat dat niet helemaal het geval is. Packed Decimal Time heeft een klein verwantschap met Packed Decimals maar het is een nieuw formaat. De opbouw van Packed Decimal Time had ik iets sneller gevonden omdat deze vermeld wordt in de documentatie van de SAS-taal. 4 bytes

0000

opvulling

0000

0000

uren

0000

0000

minuten

0000

0000

seconden

1111

opvulling

Figuur 3-9 Opbouw Packed Decimal Time Zoals u ziet in “Figuur 3-9 Opbouw Packed Decimal Time”, wordt deels het principe van Packed Decimal met 8421-weighting gebruikt. Op zich is deze standaard redelijk duidelijk en valt alle informatie eruit te halen met enkele substring commando’s.

45 000156 GET_TIME: PROCEDURE 000157 ARG OR_TIJD 000158 TIJD_BIN_FULL = X2B(C2X(OR_TIJD)) 000159 TIJD_BIN = SUBSTR(TIJD_BIN_FULL, 5, 24) 000160 UUR = B2X(SUBSTR(TIJD_BIN,1,4)) !! HEXBUG(B2X(SUBSTR(TIJD_BIN,5,4))) 000161 MIN = HEXBUG(B2X(SUBSTR(TIJD_BIN,9,4))), 000162 !! HEXBUG(B2X(SUBSTR(TIJD_BIN,13,4))) 000163 SEC = B2X(SUBSTR(TIJD_BIN,17,8)) 000164 TIJD = UUR !! ":" !! MIN !! ":" !! SEC 000165 RETURN TIJD

Figuur 3-10 Code functie GET_TIME(OR_TIJD): TIJD Ik heb voor het bepalen van de tijd een functie gemaakt die afhankelijk van de parameter de tijd teruggeeft in een duidelijk leesbare tijd. In regel 158 wordt alles omgezet in het binair stelsel, omdat hiermee duidelijk te werken valt aan de hand van het schema van “Figuur 3-9 Opbouw Packed Decimal Time”. In de volgende regel verwijder ik de opvulling achteraan en vooraan. Bij nader onderzoek ontdekte ik een afwijking van de standaard. De VMF-dataset gebruikt achteraan als opvulling “1100” in plaats van de “1111” die de standaard voorschrijft. Tot dusver verliep de omzetting perfect tot er hier en daar enkele tijden zoals “08:4D:31” verschenen. Blijkbaar correspondeert elke waarde van de Packed Decimal Time uit de VMFdataset die groter is dan negen (zoals A,B,C,…) met een negen. Om deze fout in de VMFdataset op te vangen heb ik een extra functie HEXBUG geschreven. Zoals u ziet wordt HEXBUG op regel 160 tot en met 162 toegepast. 000180 HEXBUG: PROCEDURE 000181 ARG HEX_DIG 000182 FIX_DIG = HEX_DIG 000183 IF (HEX_DIG == 'A') ! (HEX_DIG == 'B') ! (HEX_DIG == 'C'), 000184 ! (HEX_DIG == 'D') ! (HEX_DIG == 'E') ! (HEX_DIG == 'F') THEN 000185 DO 000186 FIX_DIG=9 000187 END 000188 RETURN FIX_DIG

Figuur 3-11 Code functie HEXBUG(HEX_DIG): FIX_DIG (SAS INSTITUTE INC., 1998) 3.4.11.3

Array’s of STEMS gebruiken

Ik wou in de code van mijn programma’s zoveel mogelijk werken met procedures en functies omdat dit de enige manier is om overzichtelijk procedureel te programmeren. Ik ben echter tot de conclusie gekomen dat het doorgeven van een STEM (array) niet gaat in REXX. Blijkbaar heeft REXX voor dit soort dingen een zeer gebrekkige ondersteuning en kon ik niet op die manier werken. Zoals u in mijn broncode op de bijgevoegde CD-ROM kunt zien heb ik toch zoveel mogelijk geprobeerd om procedureel te werken, maar dan met globale STEMvariabelen die spijtig genoeg veel resources consumeren.

46

3.4.12

B8D320B

B8D320B en het bijhorende REXX-programma VINF3WVB.BATCH.REXX(B8D32020) zorgen voor de generatie van de JCL-code voor herstelling van het systeem. De code die hier wordt aangemaakt zal op de herstellingstape geplaatst worden. Met behulp van de herstellingstape hoeft men in een noodgeval alleen de jobs op de tape naar JES te sturen. Het systeem zal automatisch de back-ups terugplaatsen. Het enige wat de operator dan nog hoeft te doen is de tapes wisselen omdat een herstelling manueel moet gebeuren. Als parameter van deze job dient u het aantal volumes, dat maximaal op een tape geplaatst wordt mee te geven met NUMBER_VOLS_TAPE. Dit is net zoals de parameter LABLCAR uit job B8D300D. Deze waarde staat standaard op 35. Met de volgende parameter JOBCONTROLPARAMS kunt u de parameters meegeven die ingevoegd worden in de resulterende JCL-code. Standaard staat deze waarde op “JOB T,JC,CLASS=N,MSGCLASS=T,TYPRUN=HOLD”, maar afhankelijk van de prioriteit die gevraagd wordt voor de herstellingsjobs kunt u deze aanpassen. De datasets VINF0PRD.BLVB04.B8D320.VOLSER1 en VINF0PRD.BLVB04.B8D300.BACKVOLS worden gebruikt voor invoer van de gegevens over de tapes en de volumes. De JCL-code wordt weggeschreven in de dataset VINF0PRD.BLVB04.B8D320.RSTORJCL. 3.4.13

B8D320C

Deze job heeft als doel de aangemaakte JCL-code uit job B8D320B weg te schrijven op een tape met als naam VINF3CUC.JCLDUMP. 3.4.14

B8D320D

B8D320D gebruikt net als B8D320A het REXX-programma B8D32010 om tapes te selecteren uit de VMF-dataset. Met de parameters worden bij deze job andere instellingen meegegeven dan bij B8D320A. Dan kan B8D320D de VMF-dataset doorzoeken naar de tape waarop de herstellingsjobs staan. Hiervoor wordt BACKUP_PFX met de waarde “VINF3CUC.JCLDUMP”op de naam van de herstellingstape gezet. Het resultaat van het REXX-programma wordt weggeschreven naar VINF0PRD.BLVB04.VOLSER2. Daarna zal dezelfde job de datasets VINF0PRD.BLVB04.VOLSER1 en VINF0PRD.BLVB04.VOLSER2 samenvoegen tot VINF0PRD.BLVB04.VOLSER.

47

3.4.15

B8D320E

De laatste job in de back-up ketting die dagelijks wordt doorlopen is de rapportagejob. B8D320E leest de inhoud van VINF0PRD.BLVB04.VOLSER en stuurt deze door naar Sendmail met de juiste parameters die in de JCL-code van de job zijn bepaald. Op deze manier krijgt [email protected] dagelijks een rapport met de lijst van de tapes waarop de back-ups staan. De operators kunnen ook zien welke tapes zij uit de IBM-tapelibrary moeten verwijderen en doorgeven naar een andere locatie om in de kluis bewaard te worden.

48

4

TAAKOMSCHRIJVING OPDRACHT VOLSMIGR

4.1

Achtergrondinformatie

Bij technology changes moeten volumes van een DASD systeem (Direct Access Storage Device) naar een andere DASD gezet worden. Manueel kruipt hier heel wat werk in, vooral als het gaat over hele ranges van volumes die verplaatst moeten worden.

4.2

Concrete opdrachtomschrijving

Het maken van een REXX-script dat JCL-code genereert om de verplaatsing van de DASD (Direct Access Storage Devices) makkelijker te laten verlopen. Zodoende moet niet manueel per volume een nieuw bestand met JCL-code gemaakt worden, maar genereert het script zelf deze JCL-code bestanden, afhankelijk van een aantal parameters. Deze parameters bestaan uit de bereiken van de invoer-en uitvoervolumes en een excludelijst van volumes die niet mogen gekopieerd worden. Een bereik kan één volumeadres zijn of een hele reeks. De uitvoer gebeurt dan in verschillende PDS’en (Partitioned Datasets) met daarin per invoervolume een job in JCL-code. De volgende PDS’en en de daarin nodige jobs worden aangemaakt: copy, init, reformat en een rollback van de reformat. In de copy PDS wordt voor elk invoervolume de JCL-code geplaatst om de gegevens van het invoervolume naar het overeenkomstige uitvoervolume te kopiëren. In de reformat PDS wordt voor elk invoervolume de JCL-code geplaatst om het invoervolume een andere (tijdelijke) naam te geven. Als de verplaatsing succesvol is, dan wordt de JCLcode van de init PDS uitgevoerd. In de init PDS wordt de tijdelijke naam van het invoervolume veranderd naar een nieuwe naam die een vrij volume aanduidt. Het is na deze init dat een volume als echt leeg kan worden aanzien, aangezien een init de VTOC (Volume Table of Contents) opnieuw aanmaakt. Als laatste wordt een PDS gemaakt die een rollback toelaat. Aangezien het invoervolume is gekopieerd naar het uitvoervolume en beide volumes van naam zijn veranderd, is een rollback mogelijk door de naam van het invoervolume weer correct te plaatsen.

49

4.3

Uitwerking van de opdracht

In tegenstelling tot de vorige stageopdracht is hierbij de broncode beperkt gebleven tot één dataset. De JCL-code bevindt zich in de dataset VOLSMIGR.CNTL en de broncode in VOLSMIGR.REX. Om het proces te kunnen besturen is er natuurlijk ook een controledataset STG0917.VOLSMIGR.CNTLSET nodig. In die controledataset wordt bepaald welke volumes de zogenaamde in- en uitvoervolumes zijn. Eveneens worden de excluded volumes hierin opgegeven. De lay-out van het bestand is als volgt: 000100 000200 000300 000400 000500 000600 000610 000700 000800 000900 000910 001000 001100 001200 001300 001400 000610 000700 000800 000900 000910 001000 001100 001200 001300 001400 001500 001600 001700 001800 001900 002000 002100 002200 002300 002400 002500 002600 002700 002800 003000 003100 003200 003300 003400 003500 003600 003700

//---------------------------------------------------------------------// COMMENT: // THIS FILE IS THE CONTROL FILE FOR THE VOLSMIGR REXX PROGRAM. // // HOW TO USE? // DEFINE IN-VOLUMES: // S0000-0000 FOR A RANGE AND S0000 FOR A SINGLE VOLUME // WHERE 0000 IS THE DEVICE NUMBER IN HEX. // DEFINE OUT-VOLUMES: // D0000-0000 FOR A RANGE AND D0000 FOR A SINGLE VOLUME // WHERE 0000 IS THE DEVICE NUMBER IN HEX. // DEFINE EXCLUDES: // E0000-0000 TO EXCLUDE A RANGE AND E0000 TO EXCLUDE A SINGLE VOLUME // WHERE 0000 IS THE DEVICE NUMBER IN HEX. // EXXXXXX CAN BE USED TO EXCLUDE A VOLUME USING IT'S VOLUME NAME. // // S0000-0000 FOR A RANGE AND S0000 FOR A SINGLE VOLUME // WHERE 0000 IS THE DEVICE NUMBER IN HEX. // DEFINE OUT-VOLUMES: // D0000-0000 FOR A RANGE AND D0000 FOR A SINGLE VOLUME // WHERE 0000 IS THE DEVICE NUMBER IN HEX. // DEFINE EXCLUDES: // E0000-0000 TO EXCLUDE A RANGE AND E0000 TO EXCLUDE A SINGLE VOLUME // WHERE 0000 IS THE DEVICE NUMBER IN HEX. // EXXXXXX CAN BE USED TO EXCLUDE A VOLUME USING IT'S VOLUME NAME. // // THE FOLLOWING RULES MUST BE FOLLOWED -STRICTLY- OR THE RISK // OF SEVERE DATALOSS EXISTS! // - THE FIRST GROUP ARE THE EXCLUDES // - SECONDLY ARE THE IN-VOLUMES // - THIRDLY ARE THE OUT-VOLUMES // // EXAMPLE: // //EXCLUDES: // E3040-3045 // ESTOR01 // //IN-VOLUMES: // S3000-304F // //OUT-VOLUMES: // D3100-305F // D3100-305F //--+----1----+----2----+----3----+----4----+----5----+----6----+----7-//EXCLUDES: //IN-VOLUMES: S3600-362A S3700-3722 //OUT-VOLUMES: D3410-345F

Figuur 4-1 VOLSMIGR.CNTLSET

50

In deze dataset is de nodige informatie opgenomen over de werking van het bestand in het Engels zodat de dataset door iedereen kan worden begrepen. Een volume in een IBM-mainframe wordt gekenmerkt door een label (volume serial) en een apparaatnummer (device number). Dit label moet zes tekens lang zijn en kan verschillende tekens bevatten. Een apparaatnummer is per definitie het hexadecimaal adres van dit volume. Enkele voorbeelden van volumes zijn: 3544 (SONL02), 500F(BCV002), … De verplaatsing van volumes wordt gebaseerd op deze apparaatnummers. Volumes kunnen in een bereik worden ingegeven of per volume. Afhankelijk van de letter die ervoor geplaatst wordt, is dit bereik of volume een in-, uit- of excludevolume. Om verwarring te voorkomen tussen de 0 (nul) en de O (de letter ‘o’) heb ik gekozen om de benamingen in de controledataset aan te passen. In deze dataset wordt voor een in-volume de letter ‘S’ van ‘Source’ geplaatst, voor een uit-volume wordt de letter ‘D’ geplaatst van ‘Destination’ en de excludevolumes worden gekenmerkt door een letter ‘E’. Een regel die begint met ‘//’ kenmerkt een commentaarregel.

VOLSMIGR.REX

// VOLSMIGR.CNTLSET // EXCLUDES: E3012 // IN-VOLS: S3010-3015 S3020 // OUT-VOLS: D32A1-32A7

INIT

3010

32A1

3011

32A2

3012

32A3

3013

32A4

3014

32A5

3015

32A6

3020

32A7

COPYJCL

Figuur 4-2 Werking VOLSMIGR.REX script

REFORMAT

REFORMUN

51

Zoals in “Figuur 4-2 Werking VOLSMIGR.REX script” aangeduid, leest het REXX-script de controledataset in en kijkt het script na welke in-volumes moeten gekoppeld worden aan welke uit-volumes. Dit gebeurt in de procedure READ_CNTLLIST (zie broncode op CDROM). Tevens moet er rekening worden gehouden met het feit dat elk script of programma zo efficiënt mogelijk moet lopen. Daarom heb ik ervoor gekozen om de volumes die niet mogen gekopieerd (excludelijst) worden vooraan te plaatsen. Zo kan de procedure READ_CNTLLIST optimaal werken door eerst te lezen welke volumes hij zeker niet mag benaderen. Zodoende kan er bij het overlopen van de in- en out-volumes ineens gekeken worden of deze voorkomen in de excludelijst. Na het inlezen van deze lijsten zijn er twee lijsten, namelijk die van de in-volumes die verplaatst moeten worden en die van de out-volumes die beschikbaar zijn. Het aantal benodigde volumes wordt vergeleken met de beschikbare volumes. Indien er een tekort blijkt aan beschikbare volumes verschijnt volgend bericht: TOTAL IN-VOLUMES:78 TOTAL OUT-VOLUMES:0 TOTAL EXCLUDED VOLUMES:0 ABORTED: NOT ENOUGH OUT-VOLUMES AVAILABLE

Figuur 4-3 Tekort aan out-volumes Als er toch voldoende volumes beschikbaar zijn, gaat het programma verder met het aanmaken van de verschillende datasets in de PDS’n voor het kopiëren, initialiseren, herformatteren en de rollback. Per dataset wordt vervolgens de procedure GENERATE_JCL opgeroepen. Deze procedure heeft als doel een lijst op te vullen met de code die in de dataset moet weggeschreven worden. /* CREATE DATASETS AND JCL CODE FOR COPYING */ PARAM = "JOBNAME=" !! VOLSER_S !! ";SOURCE_VS=" !! VOLSER_S, !! ";TARGET_VS=" !! VOLSER_D !! ";" STAT = GENERATE_JCL(' %)(,.;','TMPLCOPY', ,PARAM) CODE = LISTDSI("OUTDD1" "FILE") /* SAY "OUTPUT PDS:" SYSDSNAME */ PDS = SYSDSNAME ADDRESS TSO "FREE FILE(OUTDD1)" "ALLOC F(OUTDD1) DA('"PDS"("VOLSER_S")') OUTPUT SHR" "EXECIO * DISKW OUTDD1(FINIS STEM WRITELIST." ADDRESS ISPEXEC

Figuur 4-4 Aanroepen GENERATE_JCL De procedure GENERATE_JCL is speciaal ontwikkeld om ook in andere REXX-scripts gebruikt te kunnen worden. Ze vraagt als parameter een sjabloondataset. In “Figuur 4-4 Aanroepen GENERATE_JCL” ziet u dat TEMPLCOPY wordt meegegeven. TEMPLCOPY is een dataset die gedefinieerd is in de JCL-code om dit REXX-script aan te roepen.

52

Naast TEMPLCOPY worden ook nog de variabelen ‘.%)(,.;’ en PARAM doorgegeven. De tekenreeks definieert de verschillende tekens waarmee een variabele in de sjabloon (template) kan beëindigd worden. Een variabele wordt in het sjabloon namelijk gekenmerkt door het feit dat hij begint met een ‘$’ en het einde van een variabele kan dus bepaald worden door een van de tekens in de reeks. PARAM is de variabele waarlangs alle data wordt doorgegeven aan GENERATE_JCL. PARAM wordt gevuld met de labels van de variabelen die voorkomen in de sjabloondataset en met de waardes voor deze variabelen (zoals in “Figuur 4-4 Aanroepen GENERATE_JCL” kan gezien worden). Zo krijg je bijvoorbeeld als waarde voor PARAM JOBNAME=SONL02;SOURCE_VS=SONL02;TARGET_VS=EM332F. In “Figuur 4-5 Sjabloon VOLSMIGR.TMPLCOPY” ziet u dat in de sjabloondataset de variabelen $JOBNAME, $SOURCE_VS en $TARGET_VS voorkomen. 000100 000200 000300 000400 000500 000600 000700 000800 000900 001000 001100 001200 001300 001400 001500

//$JOBNAME JOB ,'PHYSICAL FULL COPY',CLASS=L,MSGCLASS=T,TYPRUN=HOLD //*--------------------------------------------------------------------//STEP0010 EXEC PGM=ADRDSSU,REGION=6M PARM='TYPRUN=NORUN' //* //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=$SOURCE_VS,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=$TARGET_VS,UNIT=3390,DISP=SHR //SYSIN DD * COPY FULL INDD(INVOL1) OUTDD(OUTVOL1) COPYVOLID ALLEXCP ALLDATA(*) CHECKVTOC CANCELERROR ADMINISTRATOR

Figuur 4-5 Sjabloon VOLSMIGR.TMPLCOPY In GENERATE_JCL wordt bepaald waar exact een variabele zich bevindt in de meegegeven dataset. Daarna wordt de meegegeven waarde van die variabele toegekend in de plaats van de naam van de variabele. Een voorbeeld daarvan vindt u in “Figuur 4-6 Sjabloon TMPLCOPY ingevuld”.

53

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015

//SLU0A1 JOB ,'PHYSICAL FULL COPY',CLASS=L,MSGCLASS=T,TYPRUN=HOLD //*--------------------------------------------------------------------//STEP0010 EXEC PGM=ADRDSSU,REGION=6M PARM='TYPRUN=NORUN' //* //SYSPRINT DD SYSOUT=* //INVOL1 DD VOL=SER=SLU0A1,UNIT=3390,DISP=SHR //OUTVOL1 DD VOL=SER=EM3410,UNIT=3390,DISP=SHR //SYSIN DD * COPY FULL INDD(INVOL1) OUTDD(OUTVOL1) COPYVOLID ALLEXCP ALLDATA(*) CHECKVTOC CANCELERROR ADMINISTRATOR

Figuur 4-6 Sjabloon TMPLCOPY ingevuld Indien er een “$” moet voorkomen in het sjabloon zelf dan wordt er gewerkt met een vervangende variabele. Uit praktijktesten blijkt dat dit sneller is dan een dubbele test uit te voeren op een ontsnappingsteken (zoals de ‘\’ die gekend is uit Unix/Linux-omgevingen). Reeds bij het initialiseren kwam ik dit probleem tegen. Voordat een volume kan geïnitialiseerd worden, dient men het volume uit te schakelen voor gebruik met het commando /*$VS,'V 32F2,OFFLINE. In mijn sjabloon is $VS vervangen door $VS_CMD en is $VS=$VS; een extra parameter in het aanroepen van GENERATE_JCL. Bij de implementatie van $VS=$VS kwam ik echter een volgend probleem tegen. VS is een deel van een andere parameter, namelijk SOURCE_VS. Een variabele naam moet niet alleen uniek zijn, maar mag ook geen deel van een andere variabele zijn. De oplossing hiervoor was $VS_CMD=$VS omdat een volledige controle op lengte en overeenkomstigheid tot een vertraging leidde. In VOLSMIGR.REX worden 4 sjablonen op deze manier gebruikt bij de creatie van de JCLcode voor het kopiëren, initialiseren, herformatteren en de rollback. Zo kunt u trouwens ook gemakkelijk de uitvoer van het script aanpassen, u hoeft slechts de sjablonen aan te passen.

54

5

TAAKOMSCHRIJVING OPDRACHT VPS

5.1

Achtergrondinformatie

Door de jaren heen is de ING Groep steeds groter en groter geworden. Zoals vermeld in paragraaf 1.3 is ING Insurance zelf ontstaan uit de fusie van enkele grote verzekeraars in België. Deze fusie bracht naast de gewoonlijke personeels- en budgetteringsproblemen ook informaticaproblemen met zich mee. Zo golden er verschillende standaarden bij elke verzekeraar voor servers, workstations, printers en het netwerk. In een eerste stap om deze verschillende standaarden tot één standaard te brengen werd CIDS ingericht. CIDS staat voor Common Insurance Desktop Services. Dit is de standaard die nu bij ING Insurance in België gebruikt wordt. Maar met de constante groei van de markt en de ING Groep zelf en de toenemende informatica eisen moet er een opvolger komen. Deze opvolger noemt Common European Desktop Services (CEDS) en combineert de bankwereld met de verzekeringswereld in één uniforme standaard binnen Europa. Het standaardiseren van de huidige apparatuur brengt problemen met zich mee. Zo worden nu al in pilootprojecten de PC’s vervangen door CEDS PC’s met MS Windows XP erop. Elke PC, server of printer krijgt een Europese naam toegewezen met het type, land en volgnummer erin verwerkt. Het nadeel hiervan is dat er bepaalde applicaties draaien op de IBM-mainframe waarin de printernamen vast gecodeerd zijn en die nu aangepast moeten worden. Ook zijn er door de jaren verschillende printers bijgekomen, verwijderd, aliassen aangemaakt enzovoorts.

55

5.2

Concrete opdrachtomschrijving

Mijn opdracht bestond erin om een systeem uit te werken dat de omschakeling naar CEDS emuleert tegenover het mainframe. Er wordt op het mainframe gebruik gemaakt van een VTAM Printer Support System (VPS) van LRS (Levi, Ray & Shoup). VTAM staat voor Virtual Telecommunications Access Method. Dit is een interface die het propriëtaire SNA (Systems Network Architecture) protocol van IBM controleert. SNA werd en wordt nog steeds vaak gebruikt als protocol tussen een mainframe en printers. Dit VPS systeem voegt compatibiliteit toe met bestaande netwerken, de uitvoer van een mainframe wordt doorgestuurd naar een andere printer server in plaats van dit zelf volledig af te handelen. (LEVI, e.a., 2002:7) In de productie LPAR van ING Insurance draaien momenteel 2 VPS omgevingen, VPSTEST en VPSPROD. VPSPROD is het systeem dat dagelijks gebruikt wordt terwijl de andere een testomgeving is. Aangezien er duizenden gebruikers zijn die het systeem gebruiken, mag er niet zomaar met de productieversie gespeeld worden. Alles moet eerst uitvoerig in VPSTEST getest worden. Het VPS systeem beheert de printernamen in het mainframe en de uitvoer voor printers van JES2. Op deze manier kunt u de uitvoerbestemmingen voor de printers aanpassen en de mainframe printernamen ongewijzigd laten. Die uitvoer stuurt het systeem dan door naar bijvoorbeeld een MS Windows 2003 printer server, afhankelijk van de instellingen van de bepaalde printer in het VPS systeem. Zo kan een printer in de mainframe omgeving “H011L” blijven noemen terwijl de uitvoer doorgestuurd wordt naar PPBE2524 (de nieuwe CEDS printernaam). Dankzij dit systeem moeten niet alle applicaties aangepast worden voor de nieuwe printernamen. Informatie over de printers in het huidige systeem en het CEDS systeem wordt beheerd in een MS Excel bestand genaamd, CEDS-IIB_printing.xls. Uit dit bestand moet in de eerste plaats alle informatie worden opgehaald voor het mainframe platform. Daarna moet de opgehaalde informatie op de PROD LPAR geraken via bijvoorbeeld een FTP (File Transfer Protocol) transfer. Op basis van de gegevens moet een REXX-script automatisch printerinstellingen aanmaken binnen de VPS omgeving zodat de omschakeling probleemloos kan verlopen.

56

5.3

Uitwerking van de opdracht

In dit deel wordt de praktische uitwerking van de opdracht rond VPS omschreven en de verschillende stappen die hiervoor nodig waren.

1

CEDS-IIB_printing.xls

2

3

FTP (VINF3SOF.VPSCEDS.EXPORT.CSV) Programma VPSGENER

4 CEDS

NONCEDS

Figuur 5-1 Overzicht uitwerking VPS opdracht

5.3.1

CEDS-IIB_printing.xls

In een eerste stap van dit proces moet alle informatie over de printers correct worden bijgehouden door de verantwoordelijke hiervan. Dit dient volgens strikte afspraken te gebeuren zodat er geen andere stappen verkeerd kunnen lopen. 5.3.2

Converteren naar CSV

Het CEDS-IIB_printing.xls bestand wordt ingelezen door een MS Excel macro programma dat Convert_CEDS-IIB.xls noemt. Hiervoor hoeft u slechts Convert_CEDS-IIB.xls te openen, de locatie van CEDS-IIB_printing.xls op te geven en op de knop “Converteer” te klikken. Het programma zal automatisch de benodigde data kopiëren en in het bestand export.csv in dezelfde directory exporteren.

57

Figuur 5-2 Screenshot "Convert_CEDS-IIB.xls" Ik heb gekozen om het bestand te exporteren als een Comma-Separated Value bestand waarin de kolommen gescheiden worden door komma’s en rijen door een nieuwe lijn te beginnen. 5.3.3

Uploaden via FTP

De afdeling Operations heeft het uploaden van het export.csv bestand naar de mainframe via FTP geautomatiseerd. Op het mainframe wordt het bestand in de dataset VINF3SOF.VPSCEDS.EXPORT.CSV geplaatst. 5.3.4

VPSGENER

VPSGENER bevat JCL-code om eerst het REXX-programma VINF3SOF.VPSCEDS.VPS.REX aan te roepen en vervolgens de LISTVPS op te stellen, waarover later meer. Dankzij de eenvoudigheid van de CSV opbouw kan de dataset VINF3SOF.VPSCEDS.EXPORT.CSV makkelijk ingelezen worden. Na het inlezen door het REXX-programma zal het de dataset regel voor regel overlopen om te bepalen voor welke printer CEDS-instellingen moeten gemaakt worden, en voor welke printer niet. Een printer die voorkomt in de mainframe omgeving en niet in het toekomstige CEDS model zal als eerste waarde in de CSV dataset “(Record)” krijgen, gevolgd door de huidige naam. Dit is een printer die in een NONCEDS PDS moet geplaatst worden. Een printer waarvoor er wel een CEDS naam geplaatst is in de EXPORT.CSV dataset zal in de CEDS PDS worden opgenomen. Bijvoorbeeld “PPBE2548, E119” is een dergelijke printer.

58

Printers die beginnen met een “-” (afwezig) of waarvan de mainframe versie afwezig (ook “-”) is, mogen genegeerd worden en moeten niet in een PDS geplaatst worden. CEDS naamgeving 000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016

Oude naamgeving

PPBE2727,B033 PPBE2727,B034 PPBE2728,B081 -,E001 (RECORD),E011 PPBE2731,E012 PPBE2732,E013 PPBE2733,E015 PPBE2734,E016 PPBE2735,E017 PPBE2736,E031 PPBE2737,E032 PPBE2738,E033 PPBE2739,PPBE2740,PPBE2741,-

Figuur 5-3 Voorbeeld VINF3SOF.VPSCEDS.EXPORT.CSV Elke printer die wordt weggeschreven zal gebaseerd zijn op één van de sjabloon datasets VINF3SOF.VPSCEDS.GEN.MBTMPLCL, VINF3SOF.VPSCEDS.GEN.MBTMPLCP, VINF3SOF.VPSCEDS.GEN.MBTMPLNL of VINF3SOF.VPSCEDS.GEN.MBTMPLNP. Voor elke printer worden er ook twee instellingen weggeschreven in de CEDS of NONCEDS PDS. De instellingen voor “landscape” of “portrait” zijn verschillend voor de printer. Hierdoor zijn er vier sjabloonbestanden, twee voor CEDS en twee voor NONCEDS, elk met staande en liggende instelling.

59

VINF3SOF.VPSCEDS.EXPORT. CSV VINF3SOF.VPSCEDS.GEN. MBTEMPLCL

JCL-code VINF3SOF.VPSCEDS.GEN. CNTL REXX-programma VINF3SOF.VPSCEDS. GEN.REX

VINF3SOF.VPSCEDS.GEN. MBTEMPLCP VINF3SOF.VPSCEDS.GEN. MBTEMPLNL

Systeem programma SORT

VINF3SOF.VPSCEDS.GEN. MBTEMPLNP

VINF3SOF.VPSCEDS. CEDS

VINF3SOF.VPSCEDS. NONCEDS

VINF3SOF.VPSCEDS.NONCEDS (DYNLVPS) VINF3SOF.VPSCEDS.NONCEDS (STATLVPS)

VINF3SOF.VPSCEDS..NONCEDS (LISTVPS)

Figuur 5-4 Overzicht werking VPSGENER Nadat alle printers zijn geplaatst in één van de twee PDS’en moet er voor de VPS omgeving ook een LISTVPS dataset aangemaakt worden. Het VPS systeem laadt alleen de printers die daarin vermeld worden. Een probleem dat hierin ontstaat is dat er ook enkele statische printers zijn die rechtstreeks verbonden zijn met het mainframe. Die printers moeten ook in de LISTVPS dataset vermeld worden. Ze zijn manueel in de NONCEDS PDS toegevoegd. De oplossing, die ik hiervoor gemaakt heb, is zeer simpel. Het REXX-programma schrijft namelijk voor elke printer ook informatie weg in de nieuwe DYNLVPS dataset. Vervolgens zal de JCL-code met een systeem programma SORT ervoor zorgen dat die dataset aaneengekoppeld wordt met een STATLVPS dataset. De uitvoer ervan wordt dan in de LISTVPS dataset geplaatst.

60

BESLUIT Mainframes zijn een complexe materie en zullen dat waarschijnlijk altijd blijven. Toch heb ik in deze drie korte maanden zeer veel bijgeleerd over IBM-mainframes, hun netwerk en het programmeren ermee. De opgedragen opdrachten werden telkens correct en in korte tijd afgewerkt. Twee van de drie opdrachten draaien momenteel zelfs in productie. De laatste opdracht kan voorlopig nog niet in productie draaien aangezien de migratie naar CEDS nog niet voltooid is. Ze werkt echter wel volledig in een speciaal opgezette testomgeving. Er is ook voldoende documentatie voorzien bij de opdrachten zodat ze perfect onderhoudbaar zijn. Vooral door mijn eerste opdracht heb ik ingezien hoe belangrijk het is voor een bedrijf (zowel klein als groot) om aan datamanagement te doen. Een goed uitgebouwd Storage Area Network is hiervoor de beste oplossing. Waar mainframes vroeger altijd werden afgeschilderd als oubollige ten dode opgeschreven machines, realiseer ik nu de enorme stabiliteit en kracht van het platform. Vele technologieën en concepten die al jaren bestaan op een mainframe verschijnen nu pas op de PC. Hoewel een mainframe vaak nog oude principes hanteert (zoals JCL) en compatibel is met programma’s van 30 jaar geleden is dit platform verre van dood. Ik durf zelfs besluiten dat IBM in technologie ver voorloopt tegenover andere servers.

61

LITERATUURLIJST Boeken EBBERS, Mike, O’BRIEN, Wayne en OGDEN, Bill, 2005. Introduction to the New Mainframe: z/OS Basics. U.S., International Business Machines Corporation, 312 p. EMC CORPORATION, 2004. TimeFinder/Mirror Product Set for OS/390 and z/OS. U.S., EMC Corporation, 236 p. HEWLETT PACKARD, 1989. 900 Series HP 3000 Computer Systems DATA TYPES CONVERSION Programmer’s Guide. Second Edition, U.S., Hewlett Packard, 68 p. INTERNATIONAL BUSINESS MACHINES CORPORATION, 2004. MVS JCL User’s Guide. Fourth Edition, U.S., International Business Machines Corporation, 324 p. LEVI, RAY & SHOUP, 2002. VPS The Core of Enterprise Output Management. U.S., Levi, Ray & Shoup, Inc., 1302 p. WHITE, Bill, ALMEIDA, Mario, FADEL, Jose, HAMID, Parwez, HATFIELD, Brian, JORNA, Dick, en OGDEN, Bill, 2004. IBM eServer zSeries 890 Technical Introduction. U.S., International Business Machines Corporation, 166 p.

Losbladige werken VAN GORP, Filip, 2003. Data-management. ING Insurance. VAN DEN BULCK, Luc, 2005. Budget z/OS. ING Insurance.

Elektronische bronnen BRIAN MADDEN, 2004. The 4GB Windows Memory Limit: What does it really mean? http://www.brianmadden.com/content/content.asp?ID=69 (4 mei 2005) ING INTRANET, 28 mei 2004. ING Groep. http://www.be.inginsurance.intranet/nl/company/profile_group.asp (8 april 2005). ING INTRANET, 28 mei 2004. ING Insurance. http://www.be.inginsurance.intranet/nl/company/profile_company.asp (11 april 2005). ING INTRANET, 2005. Organigram. http://sent44.bbl.intranet/hrswpe/_organigram/NL_org_view_chart.asp?Department_id=1108 745 (11 april 2005). PAMULA, Ray S, 20 oktober 2003. Data Representations. http://www.calstatela.edu/faculty/rpamula/cs101/datarepresentation.htm (23 april 2005) SAS Institute Inc., 1998. SAS OnlineDoc™. http://www.msb.edu/training/statistics/sas/books/langref/z0204435.htm (25 april 2005)

62

Mondelinge bronnen VAN GORP, Filip, 2005. System Administrator IBM MF ING Insurance (Antwerpen), mondelinge mededelingen, 14/03/2005 – 03/06/2005. VAN DEN BULCK, Luc, 2005. IBM MF Engineering ING Insurance (Antwerpen), mondelinge mededeling, 18/04/2005.