Des options pour se débarrasser de WARNING de SAS 9.2

Avec SAS 9.1.3 et SAS9.2 de nouveaux warning apparaissent. En voici deux que vous pouvez faire disparaître dans le cas où ils ne reflètent pas un problème dans votre programme.

1. Avec PROC SQL, je crée une nouvelle table du même nom que la table source.
2. Dans un data set je réduis la longueur d’une variable

1. Utiliser le même nom de data set en entré et en sortie avec PROC SQL

Pour illustrer le sujet, je vais d’abord créer un data set appelé ONE avec deux variables X et Y.

data one;
x=‘A’;
y=‘B’;
run;

Ensuite je vais créer avec PROC SQL un nouveau data set du même nom ONE qui ne contiendra que la variable X.

proc sql;
create table one as
select x
from one;
quit;

Le message dans la log ressemble à ceci:
WARNING: This CREATE TABLE statement recursively reference the target table. A consequence of this is a possible data integrity problem.

Pour ne plus avoir ce message dans la log, ajouter l’option UNDO_POLICY=NONE

proc sql undo_policy=none;
create table one as
select x
from one;
quit;

Ce cas existe depuis SAS 9.1.3.

2. Réduire la longueur d’une variable dans une étape data

Une solution pour changer la longueur d’une variable est de définir sa longueur dans une instruction LENGTH avant de lire les données avec un SET par exemple.

Depuis SAS 9.2, si la nouvelle longueur est plus petite que l’ancienne un WARNING apparaît dans la log. Ceci est une bonne chose car cela vous permet de repérer d’éventuelles coupures (truncations) de vos données.

Dans certains cas cependant, vous savez pertinemment que le nombre de caractères dans données est au plus X et que dès lors elles ne seront pas coupées en réduisant la longueur.

Vous pouvez vous épargner le warning en encadrant votre étape data des options globales VARLENCHK=nowarn et VALENCHK=warm.

Je vous conseille d’appliquer cette option localement afin de pouvoir continuer à repérer d’autres coupures potentielles non prévues.

data two;
length x $32;
x=‘A’;
run;

data two_a;
length x $1;
set two;
run;

WARNING : Multiple lengths were specified for the variable x by input data set(s). This may cause truncation of data.

options varlenchk=nowarn;
data two_b
length x $1;
set two;
run;
options varlenchk=warn;

Notez cependant, qu’avec SAS 9.1.3 ou SAS 9.2, un warning apparaît dès lors que la variable est donnée dans une instruction BY. L’option VARLENCHK de SAS 9.2 ne vous enlèvera pas le warning. Je vous conseille donc de changer votre longueur au préalable si vous ne voulez pas ce WARNING.

data two_b;
length x $1;
set two;
by x;
run;

WARNING: Multiple lengths were specified for the BY variable x by input data sets and LENGTH, FORMAT, INFORMAT statements. This may cause unexpected results.

Lectures complémentaires :

• Deux manières de créer un data set vide
• Qui a la priorité : RETAIN ou SET ? (article protégé : devenez correspondant ou écrivez un article pour obtenir le mot de passe)
• Changer la longueur d’une variable avec PROC SQL (instruction ALTER)

20 pistes pour vérifier le contenu d’un data set

AA : Faites des vérifications sur ces données.

BB: Vous avez un descriptif des choses que vous voulez voir vérifier ? AA : Non.

BB: J’imagine donc que vous ne savez pas quelles sont les vérifications les plus importantes ? AA : Oui c’est bien cela.

BB: Vous savez sous quelle forme vous voulez avoir l’information ? BB: Lisible.

Voici quelques pistes pour aborder ce genre de travail.

1. Travailler au niveau de la cellule

Pour chaque variable, listez les valeurs possibles.

1. la variable A peut ne prendre que les valeurs N ou Y, ne peut prendre que des valeurs manquantes ? (valeurs discrètes).
2. Dans quel intervalle les valeur sont-elles autorisées ? (valeurs continues).
3. Les valeurs manquantes sont-elles autorisées ? Si oui, lesquelles pour les variables numériques : le point, .A, ._, etc. ?
4. Les valeurs numériques doivent-elles être arrondies ?
5. La case des variables caractères est importante ? Tout doit-il être en majuscule ?
6. Les blancs de début, de fin ou les blancs multiples sont-ils autorisés ?
7. Est-ce que plus d’un seul mot est autorisé ?
8. Est-ce que les caractères spéciaux sont autorisés et si oui lesquels ? Seulement les caractères imprimables ?

2. Le cas particulier des dates

1. Pour les variables jour, mois et années, clarifiez si la date doit être complète ou non ?
2. Si une date incomplète est autorisée, parle t-on d’une date où seul le jour peut-être manquant, où le jour et le mois peuvent être manquants, où le jour, le mois et l’année peuvent être manquants ?
3. Comment gère t-on les dates dans le futur ? Utilise-t-on le moment d’exécution du programme comme date séparant le passé du futur ?  Si le jour et le mois sont manquants, dit-on que l’année en cours est une valeur valide ? Ainsi, si l’année 2011 est entrée, quel est le résultat si le programme est exécuté le 31 décembre 2010 et le 1er janvier 2011 ?
4. Comment comparer deux dates autorisant des valeurs manquantes ?

3. Travailler avec plusieurs lignes et/ou colonnes

Après avoir vérifier les valeur valables au niveau de la cellule, il s’agit de faire des comparaisons horizontales et verticales, sur toute une ligne, toute une colonne ou seulement certaines variables d’une ligne ou certaines variables d’une colonne. Voir plusieurs lignes et plusieurs colonnes.

1. Il vous faudra clarifier si les doublons dans une variable sont autorisés.
2. Pensez à inverser la requête. Par exemple, si les valeurs de ma variable CRITERIA finissent pas OLD alors je parle d’anciens critères. Ma requête vérifiera que lorsque CRITERIA=xxOLD alors FLAG=OLD d’une part et que lorsque FLAG=OLD, CRITERIA=xxOLD : if not (substr(criteria,length(criteria)-2)=’OLD’ and flag=’OLD’);
3. La plus grande difficulté consistera à éviter d’avoir plusieurs requêtes pour une seule valeur erronée. Par exemple, vous avez trois variables oui/non: AA, BB et CC. La première requête vérifera que AA=Y ou AA=N, que BB=Y ou BB=N et que CC=Y ou CC=N. Ensuite, si AA=Y alors REFEREFENCE ne doit pas être manquant. Il est important ici de ne pas avoir une requête supplémentaire si déjà AA  a des valeurs non autorisés identifiées précédemment.

4. Documenter les requêtes dans un tableau

1. Vous aurez souvent intérêt à lister toutes vos requêtes dans une table. Que vous lirez par la suite.
2. Il peut être intéressant d’identifier chaque requête par un nom plutôt qu’un numéro cas très probable où de nouvelles requêtes doivent s’insérer entre des requêtes déjà existantes. Vous pouvez ensuite insérer un numéro pour le tri uniquement.
3. Une autre table peut servir à lister les exceptions à la règle.

5. Présenter les résultats dans un tableau

Enfin, la présentation sous forme de tableau s’avèrera plus lisible qu’un fichier .rtf, .pdf.

1. D’une part le volume est moindre avec un tableau qu’avec un fichier textuel. Cela décourage moins les personnes qui doivent le lire.
2. D’autre part, sous Excel, les utilisateurs apprécieront les filtres et la possibilité de trier les données.

Vous pouvez étendre cette réflexion au cas où vous devez vérifier plusieurs tableaux. Quelles sont les variables communes aux différentes sources. Dans quelle mesure doivent-elles être compatibles ? Est-il préférable de tout programmer dans un seul programme ou d’appeler un programme par requête ? Il faudra

3 angles de vue sur les commentaires

Il existe trois notations différentes pour écrire des commentaires dans un programme SAS. Chacune à ses avantages et ses limites. En en prenant connaissance ici, vous pourrez faire des choix stratégiques.

1. Désactiver une instruction : un commentaire entre une étoile et un point virgule est la plus rapide des notations. Celle-ci fait usage de la particularité de la syntaxe SAS. En effet, chaque instruction se termine par un point-virgule. En ajoutant une étoile (asterisk) en tête, l’instruction est désactivée.

Lors du développement d’un programme, on est amené à suspendre certaines instructions ou à en activer ponctuellement. C’est le cas la procédure PROC PRINT, qui permet d’avoir un aperçu du contenu d’un jeu de donné. 

*proc print data=cnt_pct;
*run;

Note : On n’utilisera pas cette syntaxe étoile/point-virgule :

• pour suspendre un large bloc de texte
• si les guillemets ne sont pas fermés dans le commentaire
• entre deux instructions PUT ou deux instructions CALL EXECUTE.

2. Désactiver un bloc de texte plus globales : L’étoile/point-virgule  peut-être incluse dans d’autres  commentaires plus larges définis pas /* */. Ainsi on peut choisir d’annoter des titres de rubriques d’un programme avec *; . Ainsi on pourra englober ces titres dans une zone de désactivation plus grande.

/*
*Calcul des fréquences;
proc freq…;
run;

*Générer une table;
proc report…;
run;
*/

Note : On pourra choisir de fermer le bloc par /***/ au lieu de */. Ainsi, en enlevant seulement le /* en début de commentaire, l’intégralité du code est réactivée et fonctionne sans que la notation de fin soit impérativement supprimée.

3. Les commentaires et le langage macro :

Les différences entre les instructions à l’intérieur et la l’extérieur d’une définition de macro : les instructions macro doivent avoir l’étoile après le symbole pourcentage à l’intérieur d’une définition de macro. On continuera à mettre l’étoile avant si l’instruction est à l’extérieur de la définition de macro. La notation /**/ ne rencontre pas de difficulté particulière.

%macro commentaires;
%*IF….;
%mend;
*%commentaires;

Le cas particulier des conditions : seul le /**/  peut-être utilisé entre un %if et un %else.

%macro commentaire;
   %IF … %THEN %DO; … %END;
 /* l’autre notation n’est pas possible ici*/ 
  %ELSE …
%mend commentaire;

Une macro sans nom : la troisième méthode pour écrire un commentaire est de créer une macro sans nom.

%macro;
Mon texte est inactif ici.
%mend;

8 clés pour vos en-têtes

Que vous programmiez en SAS, en C++, en Java ou en Visual Basic, la qualité d’un programme commence par l’utilisation de commentaires. Ceux-ci doivent être compréhensibles par les non-spécialistes. L’entête est le premier élément à apparaître dans votre programme. Les étapes de votre programme se doivent d’être lisibles sans avoir à se plonger dans chaque ligne individuelle de code.

1. Préférez un nom de programme parlant : dans le milieu pharmaceutique, les tableaux et listings suivent des règles précises. Celles-ci assurent une cohérence entre les projets ou pour répondre à des contraintes techniques. Par exemple, ‘pp’ pourra être inclus dans le nom pour préciser la population à laquelle réfère le tableau est Per Protocol, ou encore, les noms de programmes pourront apparaître en minuscule.

2. Positionnez votre programme dans son projet : il est rare d’écrire un seul programme pour un projet. Le nom du projet auquel appartient le programme pourra ainsi figurer en premier.

3. Clarifiez l’objectif de votre programme : qu’il s’agisse le titre d’un tableau statistique “Nombre de patients par centre, âge et sexe” ou le rôle d’une macro “Créer des fichiers XML à partir de jeux de données SAS”, l’objectif du programme doit être explicitement défini.

4. Listez les grandes étapes du programme : vous pourrez compléter cette rubrique en fin de programmation en exploitant les grands titres numérotés.

5. Renvoyez votre lecteur vers les références documentaires : le protocole d’une étude statistique (protocol), le cahier d’observation électronique annoté (eCRF), le descriptif détaillé du programme (specification) sont des sources de documentation possibles.

6. Enumérez vos entrées/sorties : listez les données que vous exploitez dans votre programme et les fichiers permanents que vous crées.

7. Prévenez des limites du programme : les contraintes techniques comme la version SAS requise au minimum ou le système d’exploitation ont leur place dans l’entête.

8. Datez et signez vos programmes : En plus du nom des auteurs et les dates de création et de modifications, on trouvera l’inventaire des changements intervenus.

Vous venez de voir 8 informations clés pour votre entête. Cette liste n’est pas exhaustive. Elle doit s’adapter au cas par cas. Par exemple, votre client ou votre entreprise aura probablement une liste prédéfinie des critères à faire figurer. Afin d’éviter les oublis, vous pourrez faire l’usage d’un modèle d’entête.

Structure un programme, un exemple en 5 étapes

Tel un menu, les commentaires donnent une vue d’ensemble de votre programme SAS. Par la suite, vous devez expliquer les étapes de votre développement. Mais comment agencer votre code ? Voici un exemple extrait de la pharmaceutique. Il s’agit de créer un tableau statistique extrait de données sur les essais cliniques.

1. Des valeurs rapidement accessibles pour la maintenance du programme : dans cette première section figurent les informations utilisables à tout moment dans le programme. Voici quelques exemples de mises à jour :

• changement de répertoire de vos données ou programmes ;
• changement des labels apposés sur vos données codifiées ;
• pour connaître les valeurs prises par vos variables macros.

Suivre cette convention aidera les autres programmeurs à se familiariser avec votre travail.

2. Regrouper les informations : l’information à publier est, le plus souvent, à recueillir parmi plusieurs jeux de données. Il vous faudra donc les combiner. Par exemple, les données démographiques sur les patients seront à ajouter aux résultats de laboratoire. Si seule une sous population vous intéresse, il faudra supprimer les champs inutiles.

3. Extraire les statistiques : cette section peut inclure le calcul de simples fréquences et pourcentages. Elle peut aussi faire l’objet du calcul de tests statistiques.

4. Mettre en forme les résultats : chaque tableau devra suivre une mise en page précise. Les titres devront être adaptés à chaque tableau et ces dérivés. Les données codées se verront remplacées par du texte via des formats. L’ensemble pourra être lu par des éditeurs de texte ou sur des fichiers Internet.

5. Nettoyage : enfin vous pouvez faire du nettoyage en supprimant toutes les données temporaires, qu’il s’agisse de jeux de données, de catalogues, de fichiers .log ou de noms reconnus comme chemin d’accès à une bibliothèque de données. Ce travail vous sera d’autant plus bénéfique que vous exécuterez plusieurs programmes à la suite des uns des autres. Cela vous évitera de mauvaises surprises dues à l’utilisation involontaire de données en mémoire.

Tout au long de ces cinq étapes, vous ponctuerez votre code de commentaires. Un programme s’allonge très rapidement même s’il est bien écrit. Pour un simple tableau statistique en essai clinique il n’est pas rare de voir l’équivalent d’une dizaine d’écrans. Pour naviguer rapidement d’une section à l’autre, rien de tel que de numéroter vos commentaires. Un programme SAS est composé principalement de deux groupes de texte (data step et procedure). Commentez chacun bloque de texte. Par exemple, “extraire pour chaque effet secondaire, le nombre de patient l’ayant vécu”. Si une étape est inhabituelle, fournissez les raisons.