mainframe academy Hoe legacy en mainframe naar eigen ritme en mogelijkheden ontsluiten, rentabiliseren en klaar maken voor de toekomst? Comment gérer et planifier l’avenir de vos systèmes legacy et mainframe, tout en rentabilisant vos investissements passés? Karl Reremoser, NRB Maryse Sawicki, BULL
25/03/10
1
mainframe academy
uitgangspunt
Wat zijn de vaststellingen die het uitgangspunt vormen de mainframe academy?
doelstelling
Wat wil de mainframe academy bereiken?
mainframe academy
Hoe kan één en ander concreet vorm krijgen?
case
projet OPEN IC «Etude de faisabilité de migration d’une base IDS2 (sur GCOS8) vers DB2 (sur SOLARIS)»
projet OPEN NP « Accessibilité d’une base DB2 (sur SOLARIS) depuis le GCOS8 »
2
uitgangspunt
vandaag draaien nog een aanzienlijk aantal toepassingen in een legacy-omgeving
deze toepassingen zijn uiterst stabiel, maar vergen bepaalde specifieke competenties
MVS, GCOS, BS2000,…
IMS, IDS2,…
COBOL, PL1,…
deze specifieke competenties worden vandaag schaarser
zowel inzake exploitatie als toepassingen
zowel bij de klant als de leverancier
de verdwenen competentie raakt moeilijk ingevuld
de nieuwe generatie is niet gevormd op dat vlak
vandaar de vraag naar ‘evolutie’, niet noodzakelijk ‘revolutie’
consultants / auditeurs sturen aan op het verlaten van de mainframe 3
doelstelling
het bieden van continuïteit voor de bestaande toepassingen in een legacy-omgeving binnen het mogelijks vooropgestelde schema van migratie
continuïteit op het vlak van:
exploitatie van de bestaande omgeving
onderhoud van de bestaande toepassingen en data
beschikbare en noodzakelijke competentie
het ontsluiten en valoriseren van de bestaande toepassingen in een legacy-omgeving als voorafname aan het mogelijks vooropgestelde schema van migratie
ontsluiten naar
andere technologieën: RDBMS, WEB, JAVA, …
andere platformen: client/server, webservice, …
met een bijzondere aandacht voor de historische gegevens 4
mainframe academy
poolen van de noodzakelijke competenties, in zeer ruime zin:
systeemarchitecten
systeemingenieurs
ontwikkelaars
operators
…
poolen van de noodzakelijk technologie
exploitatie van de bestaande omgeving
hosting en onderhoud van de bestaande toepassingen en data
met een bijzondere focus op
de interoperabiliteit naar andere platformen
de historische data: hiërarchisch -> relationeel
5
aanbod
begeleiding in het valoriseren van wat is
technologische begeleiding: valoriseren van de bestaande toepassingen in een SOA-architectuur
organisatorische begeleiding: valoriseren van het professionalisme van de mainframe omgeving:
service level change management job scheduling …
opleiding, in beide richtingen
COBOL, PL1
J2EE, .Net
risicobeheersing
datamigratie: hiërarchisch -> relationeel
re-hosting en onderhoud van bestaande toepassingen en data
6
Cases : OPEN XX project – projet OPEN XX
projet OPEN IC «Etude de faisabilité de migration d’une base IDS2 (sur GCOS8) vers DB2 (sur SOLARIS)»
objectifs
description générale
projet OPEN NP « Accessibilité d’une base DB2 (sur SOLARIS) depuis le GCOS8 »
objectifs
description générale
comparaison projets OPEN IC / OPEN NP
7
case: projet OPEN IC - objectifs
objectif fonctionnel
avoir un accès et une intégration plus aisés des données comptables (ICPC) pour les applications développées dans le monde ouvert,
éviter les multiples copies partielles de ICPC non sécurisées ni synchronisées -> source authentique.
démontrer la faisabilité de migrer les données dans l’environnement cible tout en maintenant le fonctionnement des programmes dans l’environnement GCOS8.
vérifier que les performances sont acceptables.
8
case: projet OPEN IC - description générale application B
application C
application D
GCOS
application A
IDS/II data
IDS/II data
application B
GCOS
application A
environnement SPF actuel
environnement SPF cible
SOLARIS
IDS/II data
IDS/II data
DB2 data nouvelle application E 9
case: projet OPEN NP - objectifs
objectif fonctionnel
dans le cadre de la nouvelle architecture des applications du SPF Finances, recherche des informations dans la nouvelle base de données SITRAN (*) (DB2 sur SOLARIS) en lieu et place de la base actuelle NP (**) (IDS2 sur GCOS8) -> source authentique.
démontrer la possibilité d’utiliser les données dans l’environnement cible tout en maintenant le fonctionnement des programmes dans l’environnement GCOS8.
vérifier que les performances sont acceptables.
(*) Signalétique TRANsversale (**) Naturlijke Persoon
10
case: projet OPEN NP - description générale environnement SPF actuel application C
IDS/II data
application C
SOLARIS
application B
GCOS
application A
DB2 data
SOLARIS
application B
GCOS
application A
DB2 data
environnement SPF cible 11
case: comparaison projets OPEN IC / OPEN NP OPEN IC analyse DB
OPEN NP
approche REVER création de la DB
mapping avec la DB existante
journalisation
mise à jour
via FTP
via DBSP (*)
constitution DB solution technique sommunication GCOS8 – Solaris transformation des programmes : DML -> SQL
approche REVER
avantages
OPEN IC:
mise à disposition des données pour les applications du monde ouvert;
continuité et sécurité des traitements mainframe
OPEN NP : unicité des données;
performances d’accès acceptables
(*) (Data Base Service Processor : solution avec mainframe GCOS8)
12
Questions?
13
case: projet OPEN 8 - les différentes étapes
reprise de la connaissance de la DB existante:
extraction des structures de données;
extraction des dépendances cachées (via l’analyse des programmes);
conceptualisation d’un schéma relationnel.
mise en place de la DB cible:
design du schéma relationnel; production d’un schéma physique; validation des données en production; validation de la structure de la base de données cible; production d’un jeu de données de test; préparation de la migration des données; migration des données (après transformation des programmes); validation de la migration des données.
14
case: projet OPEN 8 - les différentes étapes
communication GCOS8 - Solaris:
développement des fonctions d’accès à une base de données SQL/DB2 sous Solaris à partir des programmes COBOL tournant sur Bull/GCOS 8;
transformation des programmes : DML -> SQL:
détermination d’un jeu de programmes critiques;
adaptation des programmes critiques;
évaluation;
adaptation de tous les programmes:
partie automatique (90%);
partie manuelle (10%);
test des programmes;
mise en production.
15
case: projet OPEN 8 - détails (1/3)
étape 1: isolement des traitements et des accès aux données
programmes
programmes
accesseurs
ICPC IDS2
ICPC IDS2
Bull GCOS 8
Bull GCOS 8 16
case: projet OPEN 8 - détails (2/3)
étape 2: journalisation
programmes
programmes
accesseurs
accesseurs
ICPC IDS2
ICPC IDS2
Bull GCOS 8
journal IDS2
Bull GCOS 8 17
case: projet OPEN 8 - détails (3/3)
étape 3: synchronisation
ftp journal IDS2
fichier enregistrements mis à jour
Traitement journal
mise à jour
fichier enregistrements mis à jour
ICPC DB2
Bull GCOS 8
SOLARIS 18
case: ressources projets OPEN 8 / OPEN NP (1/2) OPEN 8 / OPEN NP
début de projet:
fourniture de tous les éléments (personne responsable):
1 jour / 1 jour
validation des dépendances :
analyse des résultats produits par REVER: (personnes ayant une bonne connaissance du S.I.)
6 jours / 9 jours
conceptualisation:
interprétation des résultats et validation : 20 jours / 24 jours (personne ayant une bonne connaissance du métier/business)
production schémas SQL:
validation (DBA)
1 jour
validation des données :
exécution de programmes sur les données réelles (DBA) :
validation des résultats - correction des données: (personne habilitée à manipuler ces données / business)
6 jours / 10 jours 3 jours / 6 jours
validation de la structure des données:
sélection d’un jeu de tests et exécution des programmes d’extraction (DBA):
2 jours / 1 jour 19
case: ressources projets OPEN 8 / OPEN NP (2/2) OPEN 8 / OPEN NP
migration des données:
exécution des programmes de migration (DBA) :
2 jours
validation de la migration des données:
exécution de scripts d’extraction (DBA):
2 jours / 3 jours
détermination d’un jeu de programmes critiques:
réunions et travail de recherche (responsable application):
3 jours / 1 jour
évaluation de la transformation des programmes critiques:
évaluation (responsable application):
1 jour / 1 jour
tests des programmes:
tests sur les machines du SPF avant mise en production: (programmeurs, utilisateurs, DBA, …)
100 jours / 100 jours
mise en production:
phase final de mise en production du travail terminé: (toutes personnes concernées)
2 jours / 8 jours
20
