Commande errupdate

Objectif

Met à jour le référentiel des modèles d'enregistrement d'erreur.

Syntaxe

errupdate [ -c] [ -f] [ -h] [ -n] [ -p] [ -q] [ -y FileName] [ Fichier ]

Descriptif

La commande Errupdate ajoute ou supprime des entrées dans le référentiel des modèles d'enregistrement d'erreur ou modifie le journal, le rapport ou les caractéristiques d'alerte des entrées existantes. La commande Errupdate lit le paramètre Fichier indiqué. Si le paramètre Fichier n'est pas spécifié, la commande Errupdate lit à partir de l'entrée standard et écrit dans la sortie standard.

Chaque entrée à ajouter, à supprimer ou à modifier doit être précédée d'un opérateur. Les opérateurs valides sont:

Article	Descriptif
`+`	Ajoute une entrée (opérateur add).
`-`	Supprime une entrée (opérateur de suppression).
`=`	Modifie le journal, le rapport ou les caractéristiques d'alerte d'une entrée.

Les entrées du fichier d'entrée doivent être séparées par une ligne vide.

Les commentaires dans le fichier d'entrée peuvent être placés entre les modèles et sont indiqués par un *(astérisque) dans la première colonne.

Si des messages X/Open Portability Guide Numéro 4 sont utilisés dans des modèles d'erreur, un catalogue de messages doit être spécifié. Ceci peut se faire avec une ligne de la forme:

<*!catalog-name>

Par exemple

*!mycat.cat

Le catalogue spécifié s'applique aux messages XPG4 trouvés dans les modèles suivants, jusqu'à un autre "* !" Le spécificateur de catalogue est rencontré. Aussi, le "* !" Le spécificateur peut être remplacé par un modèle individuel avec le mot clé "catname".

Sauf si un chemin d'accès complet au catalogue est spécifié, les règles normales d'extraction d'un catalogue de messages sont respectées. Par exemple, dans l'exemple ci-dessus, mycat.cat est supposé se trouver dans /usr/lib/nls/msg/ %L.

Les entrées à ajouter doivent être définies dans un format spécifique. Le format général du modèle d'enregistrement d'erreur est:

Error Record Template
 
        + LABEL:
                         Comment=
                         Class=
                         Log=
                         Report=
                         Alert=
                         Err_Type=
                         Err_Desc=
                         Prob_Causes=
                         User_Causes=
                         User_Actions=
                         Inst_Causes=
                         Inst_Actions=
                         Fail_Causes=
                         Fail_Actions=
                         Detail_Data= <data_len>, <data_id>,
                         <data_encoding>

En outre, un nom de catalogue pour les messages XPG4 peut être spécifié avec:

catname = <catalog>

Tout modèle contenant des messages XPG4 , le mot clé catname, plus de huit éléments de données détaillés sera appelé un modèle XPG4 . Un modèle XPG4 n'est pas alertable et utilise un calcul légèrement différent pour l'ID d'erreur.

Les zones de modèle d'enregistrement d'erreur sont décrites comme suit:

Article	Descriptif
`Alert`	Indique que l'entrée du journal des erreurs peut être traitée par des produits conformes à l'architecture d'alerte générique SNA. :NONE.`Alert`Peut être définie sur True ou False. Si cette zone est omise du modèle, sa valeur par défaut est False. Si la commande`Alert`Est définie sur True, la commande Errupdate n'ajoute pas le modèle sauf si le contenu de la `Err_Desc`, `Inst_Actions`, `Fail_Cause, Fail_Actions`et `Detail_Data data_id`Sont des valeurs reconnues par l'architecture d'alerte générique SNA (dans la publication GA27-3136). Si l'une des valeurs utilisées n'est pas reconnue par l'architecture d'alerte générique SNA ou si le modèle est un modèle XPG4 , et `Alert`Est définie sur True, l'indicateur -p doit être spécifié pour ajouter ou mettre à jour le modèle.
`Class`	Indique si l'erreur s'est produite dans le matériel ou le logiciel, est un message de l'opérateur ou n'est pas déterminé. L'un des descripteurs de classe suivants doit être spécifié: h Indique que l'erreur est un incident matériel. O Indique que l'erreur est un message opérateur. S Indique que l'erreur est un incident logiciel. U Indique que l'erreur n'est pas déterminée.
`Comment`	Indique un commentaire à inclure dans l'instruction #define créée pour l'ensemble de messages d'ID d'erreur. Le commentaire ne doit pas dépasser 40 caractères et doit être placé entre guillemets. Les commentaires de plus de 40 caractères sont automatiquement tronqués. La commande Errupdate contient le commentaire dans les délimiteurs de commentaire de langage C, / * (barre oblique, astérisque) et */ (astérisque, barre oblique).
`Detail_Data`	Décrit les données détaillées, telles que la détection des noms de module, des données de détection ou des codes retour, qui sont consignées avec l'erreur lorsque l'erreur se produit. Si aucune donnée détaillée n'est consignée avec l'erreur, cette zone peut être laissée en blanc ou elle peut afficher un message à partir du jeu de messages d'ID de données détaillé en indiquant une valeur _données_données de zéro. Les trois valeurs suivantes sont requises pour chaque zone Données Detail_Data et doivent être séparées par des virgules: _données_données Nombre d'octets de données à associer à la valeur Id_données . La valeur _données_données est interprétée comme une valeur décimale. Pour spécifier la taille dépendante de l'environnement, utilisez "W". "W" sera traité comme 8 octets si l'erreur est consignée à partir d'un environnement 64 bits, sinon 4 octets. Remarque: Lors du calcul détaillé de la longueur des données, chaque "W" est traité comme étant de 8 octets, et il n'est pas sensible à la casse. Id_données Identifie un message texte de l'ensemble de messages d'ID de données détaillé "D" à imprimer dans le rapport d'erreur en regard des données détaillées. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre 4 chiffres. Codage de données Décrit comment les données détaillées doivent être imprimées dans un rapport d'erreur. Les valeurs valides sont : alpha Les données détaillées sont une chaîne de caractères ASCII imprimable. DÉC Les données détaillées sont la représentation binaire d'un entier, et l'équivalent décimal doit être imprimé. LDEC Les données détaillées sont la représentation binaire d'une valeur 64 bits et l'équivalent décimal doit être imprimé. HEX Les données détaillées doivent être imprimées au format hexadécimal. Jusqu'à 16 `Detail_Data`Des entrées peuvent être spécifiées par modèle. La quantité de données consignées avec une erreur ne doit pas dépasser la valeur de ERR_REC_MAX définie dans le fichier /usr/include/sys/err_rec.h . Les données d'erreur qui ne peuvent pas être contenues dans une entrée de journal des erreurs doivent être sauvegardées ailleurs. Les données détaillées de l'entrée du journal des erreurs doivent contenir des informations pouvant être utilisées pour corréler les données d'erreur et l'entrée du journal des erreurs.
`Err_Desc`	Décrit l'erreur qui s'est produite. Un identificateur de message de description d'erreur doit être indiqué dans cette zone. Cette valeur identifie un message texte de l'ensemble de messages de description d'erreur "E" à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre 4 chiffres. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`Err_Type`	Décrit la gravité de l'erreur qui s'est produite. L'une des valeurs suivantes doit être spécifiée: PERF Condition dans laquelle les performances de l'unité ou du composant se sont dégradées en dessous d'un niveau acceptable (performances). PERM Condition qui ne peut pas être récupére( permanente). PEND Condition indiquant que la perte de disponibilité d'un périphérique ou d'un composant est imminente (imminente). TEMP Condition qui a été rétablie après un certain nombre de tentatives infructueuses (temporaires). NON KN Condition dans laquelle il n'est pas possible de déterminer la gravité de l'erreur (inconnue). INFORMATION Condition d'entrée du journal des erreurs d'information.
`Fail_Actions`	Décrit les actions recommandées pour corriger une erreur résultant d'une cause d'échec. Une liste de 4 identificateurs de message d'action recommandés séparés par des virgules peut être spécifié. Cette valeur identifie un message texte de l'ensemble de messages Action recommandée " R à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre quatre chiffres. Cette zone doit être vide si `Fail_Causes`Est vide. L'ordre dans lequel les actions recommandées sont répertoriées doit être déterminé par le coût de l'action et la probabilité que l'action corrige l'erreur. Toujours répertorier les actions qui n'ont que peu ou pas de coût (ou peu ou pas d'impact) sur le système en premier. Répertoriez les actions pour lesquelles la probabilité de corriger l'erreur est égale ou presque égale à la suivante, avec les actions les moins coûteuses en premier. Répertoriez les actions restantes par ordre décroissant de probabilité. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`Fail_Causes`	Décrit les causes de l'erreur qui s'est produite. Une cause d'échec est définie comme une condition résultant de l'échec d'une ressource. Cette zone peut répertorier jusqu'à quatre identificateurs de message de cause d'échec séparés par des virgules. Cette valeur identifie un message texte provenant de l'ensemble de messages "F" à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre 4 chiffres. Répertoriez les causes d'échec par ordre décroissant de probabilité. Cette zone peut être laissée en blanc si elle ne s'applique pas à l'erreur qui s'est produite. Si cette zone est vide,`User_Causes`Ou le `Inst_Causes`Ne doit pas être vide. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`Inst_Actions`	Décrit les actions recommandées pour corriger une erreur d'installation. Cette zone peut répertorier jusqu'à 4 identificateurs de message d'action recommandés, séparés par des virgules. Cette valeur identifie un message texte de l'ensemble de messages Action recommandée " R à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre quatre chiffres. Cette zone doit être vide si`Inst_Causes`Zone a été laissée vide. L'ordre dans lequel les actions recommandées sont répertoriées est déterminé par le coût de l'action et la probabilité que l'action corrige l'erreur. Les actions qui ont peu ou pas de coût ou peu ou pas d'impact sur le système doivent toujours être répertoriées en premier. Les actions pour lesquelles la probabilité de corriger l'erreur sont égales ou presque égales doivent être répertoriées ensuite, avec les actions les moins coûteuses en premier. Les actions restantes doivent être répertoriées par ordre décroissant de probabilité. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`Inst_Causes`	Décrit les causes d'installation de l'erreur qui s'est produite. Une cause d'installation est définie comme étant une condition résultant de l'installation ou de la configuration initiale d'une ressource. Une liste de 4 identificateurs de message d'origine d'installation séparés par des virgules peut être spécifié. Cette valeur identifie un message texte à partir de l'ensemble de messages de la cause d'installation " I à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre quatre chiffres. Les causes d'installation doivent être répertoriées par ordre décroissant de probabilité. Cette zone peut être laissée en blanc si elle n'est pas applicable à l'erreur qui s'est produite. Si cette zone est laissée à blanc, `User_Causes`Ou le`Fail_Causes`Doit être non vide. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`LABEL`	Indique un libellé unique pouvant contenir jusqu'à 19 caractères pour chaque modèle de consignation des erreurs. Une chaîne contenant "`#define #ERRID_label Error_ID`, où la valeur ID_erreur est l'ID unique affecté au modèle d'enregistrement d'erreur est écrit dans la sortie standard si l'indicateur -h a été spécifié sur la ligne de commande. Remarque: si la zone `LABEL` comporte plus de 19 caractères, les 19 premiers caractères sont acceptés.
`Log`	Indique si une entrée de journal des erreurs doit être créée pour cette erreur lorsqu'elle se produit. La zone de journal peut être définie sur True ou False. Si cette zone est omise du modèle, sa valeur par défaut est True. Lorsque cette zone est définie sur False, le `Report`et `Alert`Les zones sont ignorées.
`Prob_Causes`	Décrit une ou plusieurs causes probables de l'erreur qui s'est produite. Une liste de 4 identificateurs de message Cause probable, séparés par des virgules, peut être spécifié. Cette valeur identifie un message texte de l'ensemble de messages Cause probable "P" à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre 4 chiffres. Les causes probables doivent être classées par ordre décroissant de probabilité. Au moins une cause probable est requise. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`Report`	Indique si les occurrences consignées de cette erreur doivent être signalées lorsqu'un rapport d'erreur est imprimé. :NONE. `Report`Peut être définie sur True ou False. Si cette zone est omise du modèle, sa valeur par défaut est True.
`User_Actions`	Décrit les actions recommandées pour corriger une erreur causée par l'utilisateur. Une liste de 4 identificateurs de message d'action recommandés séparés par des virgules peut être spécifié. Cette valeur identifie un message texte de l'ensemble de messages Action recommandée " R à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre 4 chiffres. Cette zone doit être laissée à blanc si`User_Causes`Zone a été laissée vide. L'ordre dans lequel les actions recommandées sont répertoriées est déterminé par le coût de l'erreur et la probabilité que l'action corrige l'erreur. Les actions qui ont peu ou pas de coûts, ou peu ou pas d'impact sur le système, doivent toujours être répertoriées en premier. Les actions pour lesquelles la probabilité de corriger l'erreur sont égales ou presque égales doivent être répertoriées ensuite, avec les actions les moins coûteuses en premier. Les actions restantes doivent être répertoriées par ordre décroissant de probabilité. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.
`User_Causes`	Décrit les causes de l'erreur qui s'est produite. Une cause d'utilisateur est définie comme une condition qui peut être corrigée sans contacter une organisation de service. Une liste de quatre identificateurs de message d'origine utilisateur séparés par des virgules peut être spécifié. Cette valeur identifie un message texte du jeu de messages Cause de l'utilisateur "U" à afficher pour une occurrence de l'erreur. La valeur est interprétée comme une valeur hexadécimale non signée pouvant atteindre quatre chiffres. Les causes de l'utilisateur doivent être répertoriées par ordre décroissant de probabilité. Cette zone peut être laissée en blanc si elle n'est pas applicable à l'erreur qui s'est produite. Si cette zone est laissée à blanc, `Inst_Causes`Ou le `Fail_Causes`Doit être non vide. La zone peut également spécifier un message de style XPG4 . Cette question est abordée plus loin.

Le nom de catname est utilisé pour spécifier un catalogue de messages à utiliser pour l'extraction des messages XPG4 pour le modèle en cours. Cette option remplace un catalogue spécifié par un précédent "* !" Spécificateur de catalogue. Tout modèle contenant des messages XPG4 doit avoir un catalogue spécifié avec catname ou "* !". Le nom du catalogue doit être placé entre guillemets. Sauf si un chemin d'accès complet au catalogue est spécifié, les règles normales d'extraction d'un catalogue de messages sont respectées.

Par exemple, si

catname = "mycat.cat"

Est spécifié,mycat.catest supposé se trouver dans /usr/lib/nls/msg/ %L.

La description d'erreur, la cause probable, la cause d'utilisateur, la cause d'installation, la cause d'échec, les actions recommandées et les messages d'ID de données détaillés doivent être un identificateur de message d'erreur conservé dans le catalogue des messages du journal des erreurs ou un message XPG4 .

Un identificateur de message d'erreur est constitué d'un maximum de 4 chiffres hexadécimaux, sans aucun "0x". Par exemple, 1234 ou ABCD. La commande errmsg -w permet d'imprimer ces messages avec leurs identifiants. La commande Msg peut être utilisée pour ajouter de nouveaux messages.

Un message XPG4 est spécifié à l'aide du formulaire

{<set>, <number>, <"default text">}

Le jeu, le nombre et le texte par défaut sont tous requis. Les références de message symbolique ne sont pas prises en charge. En outre, les modèles contenant des messages XPG4 ne sont pas alertables.

Un catalogue de messages doit être spécifié pour les messages XPG4 . Ceci est fait avec le "* !" Ou le mot clé catname.

La consignation des erreurs ne prend pas en charge toutes les fonctions de la messagerie d'erreur normale. Les chaînes utilisées dans les modèles de journal des erreurs doivent être conformes à certaines restrictions.

La substitution de variable n'est pas prise en charge. Par exemple, les chaînes ne peuvent pas être utilisées comme des spécificateurs de format pour imprimer des valeurs. Les chaînes ne peuvent contenir que les caractères de formatage "\t" et "\n".
Les chaînes de texte par défaut ne peuvent pas dépasser 1 Ko, 1024 octets.
Il est à noter que la description de l'erreur est imprimée dans une zone de 40 caractères sur les rapports non détaillés. Aucun formatage de chaîne n'est effectué pour ces rapports et seuls les 40 premiers caractères seront imprimés.
Les chaînes ne doivent pas contenir de nouvelle ligne de fin. Ceci est fourni par erreur.

Pour chaque entrée ajoutée, la commande errupdate attribue un ID d'erreur unique écrit dans le fichier d'en-tête spécifié par Fichier.h (où le paramètre Fichier est le nom du fichier d'entrée de commande d'interruption). Si la commande errupdate est en lecture à partir de l'entrée standard, #defineEst écrite dans la sortie standard. Les valeurs fournies pour le Class, Err_Desc, Err_Type, Fail_Actions, Fail_Causes, Inst_Actions, Inst_Causes, Prob_Causes, User_Actions, User_CausesLes zones et Detail_Data.data_id, sont utilisées pour calculer l'ID d'erreur unique pour cette erreur. Pour les modèles XPG4 , le libellé est également inclus dans le calcul.

Le contenu de la Log, Reportet AlertLes zones ne sont pas incluses dans le calcul de l'ID d'erreur unique ; par conséquent, les caractéristiques de journal, de rapport et d'alerte d'une erreur particulière peuvent être modifiées à tout moment dans la définition d'entrée d'erreur stockée dans le référentiel des modèles d'enregistrement d'erreur à l'aide de la commande Errupdate . Notez également que les parties data_len et data_encode de la zone de données détaillées ne sont pas utilisées.

La commande Errupdate crée également un fichier d'annulation dans le répertoire en cours appelé Fichier.Annuler. Si la commande errupdate est lue à partir d'une entrée standard, le fichier undo est écrit dans le fichier errids.undo . Le fichier Annuler contient des entrées de la commande Errupdate pour annuler les modifications effectuées par la commande Errupdate .

La commande errpt -t permet de visualiser le contenu du référentiel de modèles d'enregistrements d'erreurs. Les modèles sont traités et imprimés comme ils apparairaient dans un rapport d'erreur réel.

Attention: Si vous modifiez les modèles d'erreur, vous devez savoir que ces modèles peuvent être modifiés par une mise à jour ultérieure. Vous devez conserver un enregistrement de toutes les modifications apportées et appliquer à nouveau les modifications lorsque votre système est mis à jour. Cette opération n'est généralement nécessaire qu'après une mise à jour majeure du système, telle que le passage à un nouveau niveau du système d'exploitation. De plus, un tel enregistrement vous permet de modifier vos modèles si vous réinstallez. La façon la plus simple de conserver un tel enregistrement est de toujours faire des modifications de modèle à partir d'un fichier source d'interruption.

Indicateurs

Article	Descriptif
-c	Vérifie le fichier en entrée pour les erreurs de syntaxe.
-f	Forces tous les modèles à mettre à jour, y compris tous les modèles avec des ID d'erreur identiques à ceux des modèles d'entrée
-h	Crée un `#define`Pour chaque ID d'erreur affecté à un modèle d'erreur. Si un nom de fichier a été fourni sur la ligne de commande, le nom du fichier d'en-tête est celui fourni avec .h. Sinon, le `#define`Sont écrites dans la sortie standard.
-n	Supprime l'ajout du modèle d'enregistrement d'erreur au référentiel des modèles d'enregistrement d'erreur.
-P	Ajoute ou met à jour un modèle avec `Alert`Zone définie sur True qui contient une description d'erreur, une cause probable, une cause d'utilisateur, une action utilisateur, une cause d'installation, une action d'installation, une cause d'échec, une action d'échec ou des valeurs d'ID de données de données détaillées qui ne sont pas reconnues par l'architecture d'alerte générique SNA (dans la publication GA27-3136). La commande Errupdate ne vous permet pas d'ajouter un modèle avec ces caractéristiques, sauf si vous spécifiez cet indicateur.
-q	Supprime la création d'un fichier d'annulation.
-y FileName	Utilise le fichier modèle d'enregistrement d'erreur spécifié par le paramètre FileName .

Security

Contrôle d'accès: Aucun, mais vous devez disposer des droits d'accès en écriture sur un fichier modèle que vous modifiez, /var/adm/ras/errtmplt par défaut.

Attention aux utilisateurs RBAC: Cette commande peut effectuer des opérations privilégiées. Seuls les utilisateurs privilégiés peuvent exécuter des opérations privilégiées. Pour plus d'informations sur les autorisations et les privilèges, voir Base de données des commandes privilégiées dans Sécurité. Pour obtenir la liste des privilèges et des autorisations associés à cette commande, voir la commande 'lssecattr ou la sous-commande 'getcmdattr

Exemples

Pour ajouter une entrée, définissez l'entrée dans le fichier d'entrée de la manière suivante:

+ CDROM_ERR22:
        Comment=        “Temporary CDROM read error”
        Class=  H
        Log=            True
        Report= True
        Alert=          False
        Err_Type=       TEMP
        Err_Desc=       E801
        Prob_Causes=    5004
        Fail_Causes=    E800, 6312
        Fail_Actions=   1601, 0000
        Detail_Data=    120, 11, HEX
        Detail_Data=    4, 8058, DEC
        Detail_Data=    4, 8059, DEC

Pour entrer les données,

errupdate <input file>

Pour modifier le journal, le rapport et les caractéristiques d'alerte de l'entrée 99999999, indiquez l'opérateur de modification = (signe égal) suivi de l'ID d'erreur unique et les nouvelles caractéristiques de l'entrée à modifier:
```
errupdate
 =99999999:
 Report = False
 Log = True
```
Pour supprimer une entrée 99999999à partir du référentiel de modèles d'enregistrement d'erreur, indiquez l'opérateur de suppression-(signe moins) suivi de l'ID d'erreur unique de l'entrée à supprimer:
```
errupdate
 -99999999:
```

Pour remplacer le catalogue de messages XPG4 spécifié pour ce flux d'entrée avec "* !", Utilisez le mot clé "catname".

*!mycat.cat

* mycat.catEst utilisé pour tous les messages XPG4 à partir de maintenant.

* sauf pour celui-ci:

+ CDROM_ERR23:
         Comment=        "Temporary CDROM read error"
         catname= "othercat.cat"
         Class=  H
         Log=            True
         Report= True
         Alert=          False
         Err_Type=       TEMP
         Err_Desc=       {1, 1, "CD ROM is broken"}
         Prob_Causes=    {2, 1, "cause 1"},\
                        {2, 2, "Cause 2"}
         Fail_Causes=    E800, 6312
         Fail_Actions=   1601, 0000
         Detail_Data=    120, 11, HEX
         Detail_Data=    4, 8058, DEC
         Detail_Data=    4, 8059, DEC

Le catalogue othercat.cat sera utilisé uniquement pour le modèle CDROM_ERR23 .

Remarque: Un modèle peut contenir à la fois des messages XPG4 et des ID ou des points de code d'erreur traditionnels.

Fichiers

Article	Descriptif
/usr/include/sys/errids.h	Contient le fichier d'en-tête qui contient les ID d'erreur.
/usr/include/sys/err_rec.h	Contient le fichier d'en-tête qui contient des structures pour les erreurs de consignation.