01
URGENTE
Le but de cette communication technique est d'apporter quelques informations sur le processus
d'installation des licences et de répondre aux questions que se pose le technicien face à des problèmes
qu'il rencontre lors d'opérations d'installation ou d'adjonction.
1
OmniPCX Enterprise
NOUVELLE GESTION DES LICENCES SUR
OmniPCX Enterprise
SOMMAIRE
1. PRÉAMBULE .................................................................................3
9. CONTRÔLES ................................................................................7
9.1. Contrôle de la cohérence entre un fichier <offre>.swk et l'identifiant
matériel des Call Server............................................................................ 7
9.2. Contrôle de l'édition de la clé hard dans le cas d'une migration ............... 8
1. PRÉAMBULE
A partir de la Release 5.0 Lx, le processus de gestion des licences de l'OmniPCX Entreprise a
changé. En même temps, est apparu un nouveau circuit de commercialisation. Ces nouveautés
peuvent perturber les techniciens intervenant sur le système.
Le but de cette communication technique est d'apporter quelques informations sur le processus
d'installation des licences et de répondre aux questions que se pose le technicien face à des
problèmes qu'il rencontre lors d'opérations d'installation ou d'adjonction.
2. DOCUMENT À CONSULTER
Documentation Système: Services système/Gestion des licences.
4. SYSTÈME NEUF
Etapes suivies depuis la construction de l'offre jusqu'à l'installation du système sur le site client.
− Le Business Partner construit son offre avec Actis.
− Actis exporte l'offre vers le service "eLP" du serveur de commandes "eBuy" via le fichier
<offre>.sap qui contient l'ensemble des fichiers décrivant l'offre.
− "eLP" contrôle l'offre transmise par le Business Partner et passe commande à l'industriel par
l'intermédiaire du fichier <offre>.sap.
− L'industriel construit le système et transmet à "eLP", les identifiants hardware des CPU qu'il affecte
à la commande (CPU-4400, CPU-Alizé, ou Appliance Server) afin que ce dernier puisse calculer
la "signature" contenue dans le fichier <offre>.swk.
− L'industriel peut alors récupérer dans "eLP" le fichier <offre>.swk contenant la "signature" et le
fichier <offre>.sw4760 (si l'application OmniVista A4760 fait partie de la commande).
Note
Si les Appliance Server sont commandés directement chez un revendeur IBM, le Business Partner
doit saisir les CPU-Id dans "eLP".
− L'industriel génère alors les fichiers <offre>.zip, <offre>.hw et hardware.mao à partir
du fichier <offre>.sap et récupère les fichiers <offre>.swk et <offre>.sw4760 dans
"eLP".
− Il peut alors tester le système avec l'ensemble des fichiers OPS qu'il transfère dans le répertoire
/DHS3dyn/BACKUP/OPS.
− Le Business Partner peut, à tout moment, récupérer les fichiers <offre>.swk et
<offre>.sw4760 sur "eLP".
− Lorsque le technicien reçoit le système, les 4 ou 5 fichiers OPS sont dans le répertoire
/DHS3dyn/BACKUP/OPS, et optionnellement sur une disquette si la demande a été faite lors
de la commande.
Note
Il est aussi possible de construire directement une offre avec l'outil "ExpressQuote".
− Actis a besoin de connaître la configuration du client pour effectuer une adjonction de matériel.
Le technicien fait une sauvegarde des fichiers OPS avec l'outil swinst, ou bien l'opérateur Actis
fait une "photoconfig" à distance.
− Les fichiers OPS sont chargés sur Actis avant de faire l'adjonction.
− Actis vérifie que l'édition de l'offre à charger est supérieure ou égale à celle qu'il connaît déjà. Si
elle est inférieure, il refuse le chargement.
− Lorsque l'adjonction est réalisée, l'opérateur Actis exporte la commande vers "eLP" via le fichier
<offre>.sap.
− Si l'adjonction nécessite des licences complémentaires, "eLP" fournit un nouveau fichier
<offre>.swk et/ou <offre>.sw4760, car les licences doivent être affectées à la
commande et les "signatures" recalculées.
− L'opérateur Actis dispose des fichiers <offre>.swk et/ou <offre>.sw4760 livrés par "eLP"
et des fichiers hardware.mao, <offre>.hw, <offre>.zip, résidant dans Actis. Il fournit
les 4 ou 5 fichiers OPS au technicien sur disquette.
− Le technicien installe les fichiers OPS avec l'outil swinst. Après les contrôles de cohérence, le
fichier <offre>.swk est renommé software.mao dans la base de données, comme dans les
versions antérieures.
Seule cette procédure est autorisée. La copie manuelle du fichier <offre>.swk dans
le répertoire /DHS3data/mao est INTERDITE, car elle passe outre les contrôles et
génère un "panic flag".
− Lorsqu'un Omni-PCX 4400 migre en R5.1, le Business Partner a le choix de conserver la ou les
clé(s) hard comme identifiant de CPU, même si celles-ci sont équipées de "CPU-Id". Dans ce cas,
l'opérateur Actis aura renseigné ces clés dans "eLP".
Cependant, si lors de la migration en R5.1, le Business Partner fait l'adjonction de la duplication,
la deuxième CPU ne sera pas équipée de clé hard. Il sera alors possible de fonctionner avec
une clé hard sur l'une et avec le "CPU_ID" sur l'autre.
− Lorsque le technicien installe les fichiers OPS sur le système après migration, il doit vérifier la
cohérence entre le fichier <offre>.swk fourni par "eLP" et les identifiants CPU-Id ou clé hard
des CPU.
En cas d'incohérence, le Business Partner dispose de 30 jours pour régulariser. Pendant ces 30
jours, il peut gérer la base de données sans restriction ; se reporter au paragraphe 9.1 pour
contrôler la cohérence entre un fichier <offre>.swk et l'identifiant matériel des Call Server.
De même, si le Business Partner choisit de préparer une migration sur maquette et qu'il ne
dispose pas encore des CPU du client, le système sera dans la période des 30 jours, et la base
de données pourra être gérée sans restriction.
L' incident 5906 journalier est édité lorsque le système est dans la période des 30 jours.
9. CONTRÔLES
− Après avoir installé le fichier <offre>.swk à l'aide de l'outil swinst, taper la commande
spadmin et choisir le menu 2 Display active file.
Timestamp = Tue Nov 11 17:57:25 2003 Timestamp = Wed Oct 8 11:43:02 2003
OPS version = 00000 OPS version = 00000
Notes
1 La Soft Key appelée aussi "signature" est calculée et fournie par "eLP" (uniquement par "eLP").
Elle est le résultat du checksum sur les données du fichier <offre>swk.
Ces données incluent les licences achetées et les clés hard ou "CPU-Id des Call Server.
2 Cpu Id for eLP 0 et Cpu Id for eLP 1. C'est le CPU-Id virtuel pour les CPU 4400
équipées de clés hard. Il est conçu à partir de la clé hard suivie du numéro d'un identifiant sur
onze caractères. Les dix premiers caractères de l'identifiant contiennent le numéro de
commande. Le onzième caractère prend la valeur "1" pour la CPU-a et "2" pour la CPU-b.
Cet identifiant est exploité par "eLP".
Cpu Id 0 et Cpu Id 1. C'est le CPU-Id enregistré dans une mémoire flash des CPU ou
Appliance Server. Il est inscrit sur une étiquette collée sur le circuit imprimé des CPU Alizé et
CPU-4400, et en face arrière des Appliance Servers.
3 Hard-key A et Hard-key B. Ce sont les valeurs des clés hard lues dans le verrou 301 pour
CPU-a et 302 pour CPU-b.
Note
Cette information apparaît dans le cas d'utilisation de clé hard mais n'apparaît pas dans le cas
d'utilisation de CPU-Id.
4 Valeur réelle de la clé hard ou du "CPU-Id" lu sur le Call Server sur laquelle est exécutée la
commande spadmin.
Lorsque la clé hard ou le "CPU-Id" lu sur le Call Server est identique à "Hard-Key A" ou "Hard-
Key B", ou bien "Cpu Id 0" ou "Cpu Id 1", le système répond System Hard-Key found ou
Cpu-Id found. Dans la négative, il répond System Hard-Key not found ou System
CPU-Id not found, suivi d'une information du nombre de jours restant pour régulariser.
Exemple
26 remaining days(s) to fix issue
5 Handle 4760.
C'est le "Cpu Id for eLP 0" ou le "Cpu Id 0" à l'intention d'OmniVista 4760 qui sera autorisée à se
connecter sur le système.