Conditions requises pour l'installation des packages de type de ressources

L'installation de nouveaux packages de type de ressources est soumise à deux conditions :

• Lorsqu'un nouveau type de ressources est enregistré, son fichier RTR doit être accessible sur le disque.

• Lorsqu'une ressource du nouveau type est créée, tous les noms de chemin d'accès aux méthodes déclarés, ainsi que le programme détecteur du nouveau type doivent figurer sur le disque et être exécutables. Les programmes détecteurs et de méthode antérieurs doivent être conservés au même emplacement tant que la ressource est utilisée.

  Pour choisir le package le plus approprié, la personne chargée de la mise en application du type de ressources doit tenir compte des points suivants :

  • Le fichier RTR change-t-il ?

  • La valeur par défaut ou la capacité de réglage d'une propriété change-t-elle ?

  • La valeur min ou max d'une propriété change-t-elle ?

  • La mise à niveau supprime-t-elle ou ajoute-t-elle des propriétés ?

  • Le code de méthode change-t-il ?

  • Le code de contrôle change-t-il ?

  • Les nouvelles méthodes ou le nouveau code de contrôle est-il compatibles avec la version antérieure ?

Informations utiles avant la modification d'un fichier RTR

Certaines mises à niveau du type de ressources n'impliquent ni une nouvelle méthode ni un nouveau code de contrôle. Par exemple, la mise à niveau d'un type de ressources peut n'induire que la modification de la valeur par défaut ou de la capacité de réglage d'une propriété de ressources. Comme le code de méthode ne change pas, il est uniquement nécessaire, pour installer la mise à niveau, de disposer d'un nom de chemin d'accès valide vers un fichier RTR lisible.

Il n'est pas nécessaire de réenregistrer le type de ressources précédent car le nouveau fichier RTR peut écraser la version antérieure. Dans le cas contraire, vous devez enregistrer le nouveau fichier RTR sous un nouveau nom de chemin d'accès.

Si la mise à niveau modifie la valeur par défaut ou la capacité de réglage d'une propriété, la méthode Validate de la nouvelle version peut vérifier, au moment de la migration, que les attributs de propriétés existants sont valides pour le nouveau type de ressources. Si la mise à niveau modifie les attributs min, max ou type d'une propriété, la commande scrgadm valide automatiquement ces contraintes au moment de la migration.

Les informations relatives à la mise à niveau doivent présenter tous les nouveaux attributs de propriétés par défaut. Elles doivent indiquer à l'administrateur système qu'il est possible de modifier les propriétés de ressources existantes sur les valeurs appropriées à l'aide de la commande servant à modifier la propriété Type_version pour mettre à niveau la ressource vers la nouvelle version du type de ressources.

Si la mise à niveau ajoute ou supprime des propriétés, il est probable qu'il faille également modifier le code de contrôle ou certaines méthodes de rappel.

Modification du code de contrôle

Si seul le code de contrôle a été modifié dans le type de ressources mis à jour, l'installation du package peut écraser les codes de contrôle binaires. La documentation doit spécifier à l'administrateur système de suspendre la surveillance avant d'installer le nouveau package.

Modification du code de méthode

Si seul le code de méthode a été modifié dans le type de ressources mis à jour, il est crucial de déterminer si le nouveau code de méthode est compatible avec la version antérieure. Ceci vous permet de savoir si vous devez enregistrer ce nouveau code sous un nouveau nom de chemin d'accès ou si vous pouvez écraser les méthodes antérieures.

Si vous pouvez appliquer les nouvelles méthodes Stop, Postnet_stop et Fini (à condition d'être déclarées) aux ressources initialisées ou exécutées par les versions antérieures des méthodes de Start, Prenet_start ou Init, vous pouvez écraser les anciennes méthodes par les nouvelles.

Si le nouveau code de méthode n'est pas compatible avec la version antérieure, vous devez arrêter une ressource ou la supprimer de la configuration à l'aide des versions antérieures avant de pouvoir la migrer vers le type de ressources mis à niveau. Si les nouvelles méthodes écrasent les anciennes, il peut s'avérer nécessaire d'arrêter (voire de basculer en mode non géré) toutes les ressources de ce type avant de mettre ce dernier à niveau. Si les nouvelles et les anciennes méthodes sont enregistrées séparément (tout en étant accessibles simultanément), vous pouvez, même en l'absence de rétrocompatibilité, installer la nouvelle version du type de ressources et mettre les ressources à niveau individuellement.

Même si les nouvelles méthodes sont rétrocompatibles, il peut s'avérer nécessaire de mettre à niveau une ressource pour utiliser les nouvelles méthodes tandis que les autres ressources continuent d'utiliser les méthodes antérieures. Vous devez encore enregistrer les nouvelles méthodes dans un répertoire distinct plutôt que d'écraser les méthodes antérieures.

L'enregistrement des méthodes de chaque version du type de ressources dans un répertoire distinct permet de rebasculer les ressources vers la version antérieure en cas de problème avec la nouvelle version.

Une autre approche consiste à inclure toutes les versions précédentes encore prises en charge dans le package. Le cas échéant, le nouveau package remplace la version antérieure sans écraser ni supprimer les chemins d'accès aux méthodes antérieures. C'est au développeur du type de ressources de décider du nombre de versions antérieures prises en charge.

nous vous recommandons d'écraser les méthodes ou les méthodes pkgrm/ pkgadd sur un nœud appartenant au cluster. Si le RGM doit exécuter une méthode qui n'est pas accessible sur le disque, ceci risque d'engendrer des résultats inattendus. La suppression ou le remplacement du code binaire d'une méthode en cours d'exécution peut également engendrer des résultats inattendus.