Remarques concernant la conception d'une application

L'application doit définir les paramètres régionaux avant d'appeler l'API. Pour définir la valeur par défaut des paramètres régionaux, ajoutez le code suivant à l'application:

setlocale(LC_ALL,"");

Pour définir l'emplacement sur une autre valeur, utilisez le même appel avec l'emplacement approprié dans le deuxième paramètre. Vérifiez les détails dans la documentation de chaque système d'exploitation que vous utilisez.

Appliquez les instructions suivantes au contrôle de session :

• Affectez un nom de poste unique à chaque client de sauvegarde-archivage IBM Storage Protect et à chaque produit client d'API IBM Storage Protect . Voici quelques exemples de ces clients :
  • IBM Storage Protéger pour le courrier
  • ou IBM Storage Protect HSM for Windows
• Utilisez le même nom de propriétaire entre une sauvegarde et une restauration.
• Utilisez l'option passwordaccess pour gérer l'accès au fichier protégé par mot de passe.
• Vérifiez que les sessions de transfert de données s'arrêtent dès que la tâche se termine pour libérer les unités du serveur afin qu'elles puissent être utilisées par d'autres sessions.
• Pour autoriser un transfert de données hors réseau local, utilisez l'appel de fonction dsmSetup en définissant l'indicateur multithread sur on.
• Sous AIX®, lorsque vous utilisez des applications à unités d'exécution multiples ou hors réseau local, en particulier sur des machines à processeurs multiples, définissez la variable d'environnement AIXTHREAD_SCOPE sur S dans l'environnement avant de démarrer l'application, pour de meilleures performances et une planification plus rigoureuse. Par exemple :

    EXPORT AIXTHREAD_SCOPE=S

  En définissant AIXTHREAD_SCOPE sur S, user les unités d'exécution utilisateur créées avec les attributs par défaut sont placées dans l'espace de contention au niveau du système. L'unité d'exécution utilisateur est liée à une unité d'exécution du noyau et est planifiée par le noyau. L'unité d'exécution du noyau sous-jacente n'est pas partagée avec aucune autre unité d'exécution utilisateur. Pour plus d'informations, voir Utilisation du traitement multitâche.
• Vérifiez que seule une unité d'exécution d'une session appelle des fonctions de l'API à tout moment. Les applications utilisant plusieurs unités d'exécution avec le même descripteur de session doivent synchroniser leurs appels à l'API. Par exemple, utilisez une exclusion mutuelle mutex pour synchroniser les appels à l'API :
  • getTSMMutex()
  • issue TSM API call
  • releaseTSMMutex()
  Utilisez cette approche uniquement lorsque les unités d'exécution partagent le même descripteur. Dans le cas contraire, vous pouvez faire des appels de fonction en parallèle.

• Implémentez un modèle fournisseur/consommateur pour les transferts de données. Les appels d'API sont synchrones et les appels de dsmGetData function et dsmSendData function sont bloqués jusqu'à ce qu'ils soient terminés. Avec ce modèle, l'application peut lire le tampon suivant en attendant le réseau. La dissociation entre la lecture/écriture de données et le réseau permet aussi d'améliorer les performances en cas de goulot d'étranglement du réseau ou de lenteurs. En général :

  Data thread <---> shared queue of buffers <---> communication
  thread (issue calls to the IBM Storage Protect API)

• Utilisez la même session pour plusieurs opérations afin d'éviter une surcharge. Pour les applications traitant de nombreux petits objets, implémentez le regroupement de sessions de manière à ce que la même session puisse être utilisée lors de plusieurs petites opérations. Une surcharge est associée à l'ouverture et à la fermeture d'une session sur le serveur IBM Storage Protect . L'appel à dsmInit/dsmInitEX est effectué en série. Ainsi, même dans une application multitâche, une seule unité d'exécution peut se connecter à tout moment. De plus, lors de la connexion, l'API envoie un nombre de requêtes uniques au serveur de manière ce dernier puisse effectuer toutes les opérations. Ces requêtes incluent une règle, une option, des espaces fichier et une configuration locale.

Le serveur IBM Storage Protect verrouille les entrées de base de données d'espace fichier lors de certaines opérations. Les règles suivantes s'appliquent lorsque vous concevez des applications d'API IBM Storage Protect :

• Les requêtes verrouillent l'espace fichier pendant l'intégralité de la transaction.
• Le verrou peut être partagé entre différentes opérations de requête, par conséquent, plusieurs opérations sur le même espace fichier peuvent s'exécuter en même temps.
• Les opérations suivantes sont utilisées pour modifier la base de données du serveur IBM Storage Protect (DB Chg): envoi, obtention, changement de nom, mise à jour et suppression.
• L'exécution d'une opération DB Chg requiert un verrouillage de l'espace fichier pendant la modification de la base de données.
• Plusieurs opérations DB Chg sur le même espace fichier peuvent s'exécuter en même temps. Il se peut qu'il y ait un temps d'attente lorsque la séquence attend le verrou à la fin de la transaction.
• Le verrou de requête ne peut être partagé avec les opérations DB Chg. Une opération DB Chg retarde le début d'une requête sur le même espace fichier. Par conséquent, concevez vos applications pour séparer et sérialiser les requêtes des opérations DB Chg sur le même espace fichier.

• Les noms spécifiques des objets sont les noms d'objet de haut et de bas niveau. Si un identificateur unique, tel qu'un horodatage, fait partie du nom, alors des objets de sauvegarde sont toujours actifs. Les objets n'expirent que s'ils sont signalés comme inactifs, à l'aide d'un appel de fonction dsmDeleteObj.
• La méthode de restauration pour les objets détermine le format du nom pour faciliter les requêtes. La compression n'est pas possible si vous décidez d'utiliser une restauration partielle d'objet (POR). Pour supprimer la compression, utilisez la fonction dsmSendObj objAttr objCompressed=bTrue .

Faites particulièrement attention à l'ordre de restauration pendant une opération de ce type. A l'issue de la requête, faites un tri par rapport à cette valeur avant de procéder à la restauration. Si vous utilisez plusieurs types de media à accès séquentiel, alors vous devez y accéder dans des sessions différentes. Pour plus d'informations, consultez la rubrique suivante :

Sélection et tri d'objets par ordre de restauration