1. 1/
Présenta,on
de
votre
société
v Na#xis
Altaïr
IT
Shared
Services
est
la
filiale
portant
les
moyens
et
services
informa,ques
partagés
de
NATIXIS.
v Créée
en
1992,
NAITSS
propose
des
services
d’infogérance
d’infrastructure,
notamment
en
environnement
Z.

2. 2/
La
situa,on
avant/
L’origine
du
problème
v Le
coût
du
portefeuille
des
logiciels
IBM
«
MLC
»
représente
à
la
fin
des
années
1990
une
part
importante
du
budget
informa,que
des
u,lisateurs
MVS.
v L’usage
croissant
des
environnements
distribués
et
la
volonté
d’y
migrer
le
parc
applica,f
existant
et
à
venir
accroit
la
tension
sur
le
coût
des
logiciels
mainframe.
v L’infrastructure
SYSPLEX
permet
de
diminuer
le
coût
unitaire
de
la
MSU
en
faisant
cohabiter
des
environnements
MVS.
v La
première
mutualisa,on
démarre
en
1998.

3. 3/
Le
choix
de
la
solu,on
retenue
v Faire
cohabiter
des
systèmes
hétérogènes
dans
un
seul
Sysplex
en
partageant
le
minimum
nécessaire
(GRS=STAR
/
GRSRNL=EXCLUDE)
v Déployer
des
solu,ons
alterna,ves
quand
les
composants
IBM
standard
ne
peuvent
être
mis
en
communs
(ex
:
GRS
remplacé
par
un
ou,l
de
sérialisa,on
pour
les
fichiers
propres
à
chaque
environnement)
v Cloisonner
ce
qui
doit
l’être
afin
d’éviter
des
interac,ons
malencontreuses
(ex
:
exits
consoles)
v Par
la
suite
(infrastructure
Z)
veille
au
respect
des
règles
d’éligibilité
des
ordinateurs
hôtes
v Medre
en
place
des
normes
pour
éviter
les
conflits
(WLM
notamment)

4. 4/
Le
business
case
v NAITSS
a
géré
au
fil
de
l’eau
la
mise
en
commun
de
plus
de
10
sociétés
indépendantes
avec
plus
de
30
par,,ons
PRSM
dans
le
même
sysplex.

5. 5/
La
mise
en
oeuvre
de
la
solu,on
Pour
la
par,e
technique
:
v Définir
un
unique
administrateur
des
ressources
communes
au
sein
de
la
communauté
v Ne
partager
que
ce
qui
doit
l’être
et
isoler
ces
composants
dans
des
infrastructures
dédiées
(CF
et
disques
notamment)
v Définir
des
créneaux
d’interven,on
qui
conviennent
à
tout
le
monde
v Ecrire,
diffuser
et
medre
à
jour
toutes
les
règles
de
partage
et
d’exclusion.
Pour
la
par,e
économique
:
v Établir
le(s)
schéma(s)
économique(s)
permedant
de
valoriser
l’unité
d’œuvre
MSU,
d’abord
globalement
puis
logiciel
par
logiciel
en
environnement
Z.

6. 6/
Les
avantages
et
effets
de
bord
v Avantages
:
– Le
prix
unitaire
des
MSU
diminue
avec
l’effort
de
mutualisa,on
v Effets
de
bord
:
– En
cas
de
problème,
l’impact
est
plus
grand
et
le
temps
de
reprise
plus
élevé
– Les
évolu,ons
sont
plus
difficiles
à
programmer
– L’u,lisa,on
de
certaines
fonc,onnalités
«
non
partageables
»
doit
être
exclue
(RACF
sharing,
Catalog
Sharing)
– Les
montées
de
version
doivent
être
synchronisées
au
sein
des
par,cipants
au
sysplex

7. 7/
Les
pièges
à
éviter
Il
n’y
a
pas
à
proprement
parler
de
piège
si
ce
n’est
de
ne
pas
fléchir
l’aden,on
portée
au
:
v contrôle
de
l’éligibilité
des
machines,
v
et
de
l’archivage
des
records
SMF,
sans
trous,
nécessaires
au
contrôle
de
l’usage
des
CPU
par
IBM,
records
qui
doivent
être
communiqués
chaque
fin
de
mois.
v
à
la
surveillance
de
l’usage
des
composants
partagés.

8. 8/
Nos
recommanda,ons
v Les
bénéfices
acquis
permedent
d’accepter
les
contraintes
inhérentes,
que
ce
soit
les
règles
de
cohabita,on
ou
la
sensibilité
des
effets
de
bords.
v NAITSS
con,nue
à
étudier
et
medre
en
œuvre
de
nouvelles
coopéra,ons.