Système d'exploitation virtuel

Pourquoi un système d'exploitation virtuel ?
Concepts du système d'exploitation virtuel...

Celui qui a quelque peu travaillé sur des plates-formes différentes, même d'une famille identique, sait au combien il est pénible de devoir gérer les spécificités des systèmes d'exploitation. Bon nombre de logiciels ne sont pas disponibles sur des plates-formes non par manque d'intérêt mais plutôt du fait de la nécessité d'un portage sur une nouvelle plate-forme.

L'intérêt d'un système d'exploitation virtuel est de mettre à la disposition des informaticiens une interface système identique quelle que soit la plate-forme qui se fond sur un système d'exploitation réel. Les API étant identiques, le portage de l'applicatif est immédiat, même si des fonctions particulièrement avancées ont été employées.

Pour connaître les options d'exécution d'Up ! System, veuillez vous référer à la fiche Description des options d'exécution d'Up ! System.

Revenir en haut de la page...

Les files d'attente permettent de gérer deux sortes de travaux : ceux s'exécutant qu'une seule fois et ceux s'exécutant périodiquement. Pour ce second cas, le plus simple est de se définir un calendrier spécifiant les dates et les périodes de déclenchement des travaux. Un calendrier est défini à partir de plusieurs période de calendrier. Une période de calendrier est définie par :

Nous pouvons éventuellement adjoindre une sous-période de déclenchement dans la journée de planification définie par : Après chaque exécution d'un travail périodique, celui-ci est remis dans la file d'attente pour la date de la prochaine planification.

Le type Calendrier d'Up ! System modélise les calendriers. Le type PeriodeCalendrier d'Up ! System modélise les périodes de calendrier.

Les entrées-sorties sont modélisées par des variables du type Fichier d'Up ! System. Elles correspondent à des fichiers spéciaux. Il y a : Le journal est donné par le paramètre Journal. Par défaut, il s'agit du fichier ${UPS_HOME}/log/ups.log en mode mono-poste ou ${UPS_HOME}/log/${UPS_USER}/ups.log en mode multi-postes. Un fichier est un élément d'un répertoire. Il est constitué d'une liste d'octets ordonnée. La taille de cette liste est sans limite, hormis la place disponible de l'unité dont fait partie le fichier. Un fichier sert à conserver des informations persistantes à l'exécution des programmes.

Un fichier porte un nom composé de caractères éditables et sans limite de taille. Il peut comporter des caractères non alpha-numérique tel le caractère espace. Seuls les caractères division / et division inversé \ ne sont pas acceptés.

Un fichier appartient à un utilisateur (son propriétaire) et possède des droits d'accès vis-à-vis de son propriétaire et de groupes d'utilisateur.

Un fichier est caractérisé par un chemin d'accès correspondant à la succession des répertoires y menant. Ce chemin d'accès est exprimé sous forme d'une chaîne de caractères et cite dans l'ordre :

Le type Fichier d'Up ! System permet de lire et d'écrire dans des fichiers.

Pour connaître le contenu d'un répertoire, il faut utiliser la fonction ListerFichiers d'Up ! System. Celle-ci retourne la description de chaque fichier ou de chaque sous-répertoire d'un répertoire donné sous forme d'un objet du type FichierListe.

Avec une architecture logicielle classique, quand il y a une augmentation de l'usage du système d'informations, de nouveaux processus et de nouvelles tâches sont crées. La machine monte en charge linéairement avec le nombre de demandes, les temps de réponse s'accroissent en conséquence.

Dans le cas d'une politique autorisant une croissance souple (scalable growth), le mieux est d'employer des files d'attente gérant les demandes pour lisser la monter en charge de la machine. Les temps de réponse sont alors améliorés et la machine supportera une plus grande amplitude d'utilisateurs.

Une file d'attente permet à une tâche cliente d'y placer un travail de type Travail en spécifiant une contrainte temporelle d'exécution et une priorité. A chaque file sont associées des tâches la desservant. Les tâches sont créées dynamiquement en fonction de la demande, dans la limite d'un nombre maximal spécifique à chaque file.

Les tâches prélèvent les travaux un à un selon le planning établi et par ordre de priorité puis les exécutent. Les tâches clientes peuvent suivre l'état leur état d'avancement. Une fois terminés, le résultat des travaux est disponible.

Le type FileDAttente d'Up ! System modélise les files d'attente. Le type Travail d'Up ! System modélise les travaux dans les files d'attente.

Optionnellement, un journal des travaux peut être maintenu pour chaque file d'attente. Ce journal porte alors le nom de la file. Il est stocké dans le répertoire ${UPS_HOME}/log en mode mono-utilisateur ou ${UPS_HOME}/log/${UPS_USER} en mode multi-utilisateurs. Voici le contenu du journal pour l'exemple traitant des files d'attente :

Le 7/8/2003 à 23:39:35 : planification du travail 'AFaire1' numéro 1 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:35 : planification du travail 'AFaire2' numéro 2 au plus tard le 7/8/2003 à 23:39:45.
Le 7/8/2003 à 23:39:35 : début du travail 'AFaire2' numéro 2.
Le 7/8/2003 à 23:39:36 : planification du travail 'AFaire3' numéro 3 au plus tôt le 7/8/2003 à 23:39:60.
Le 7/8/2003 à 23:39:37 : fin du travail 'AFaire2' numéro 2.
Le 7/8/2003 à 23:39:37 : planification du travail 'AFaire4' numéro 4 synchronisé avec d'autres travaux.
Le 7/8/2003 à 23:39:37 : planification du travail 'AFaire5' numéro 5 synchronisé avec d'autres travaux.
Le 7/8/2003 à 23:39:37 : planification du travail 'AFaire6' numéro 6 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:38 : planification du travail 'AFaire7' numéro 7 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:39 : planification du travail 'AFaire8' numéro 8 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:40 : début du travail 'AFaire5' numéro 5.
Le 7/8/2003 à 23:39:40 : planification du travail 'AFaire9' numéro 9 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:41 : fin du travail 'AFaire5' numéro 5.
Le 7/8/2003 à 23:39:43 : planification du travail 'AFaire10' numéro 10 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:57 : début du travail 'AFaire7' numéro 7.
Le 7/8/2003 à 23:39:59 : fin du travail 'AFaire7' numéro 7.
Le 7/8/2003 à 23:39:59 : début du travail 'AFaire1' numéro 1.
Le 7/8/2003 à 23:40:0 : fin du travail 'AFaire1' numéro 1.
Le 7/8/2003 à 23:40:0 : début du travail 'AFaire4' numéro 4.
Le 7/8/2003 à 23:40:3 : fin du travail 'AFaire4' numéro 4.
Le 7/8/2003 à 23:40:3 : début du travail 'AFaire8' numéro 8.
Le 7/8/2003 à 23:40:4 : fin du travail 'AFaire8' numéro 8.
Le 7/8/2003 à 23:40:4 : début du travail 'AFaire9' numéro 9.
Le 7/8/2003 à 23:40:5 : fin du travail 'AFaire9' numéro 9.
Le 7/8/2003 à 23:40:5 : début du travail 'AFaire10' numéro 10.
Le 7/8/2003 à 23:40:6 : fin du travail 'AFaire10' numéro 10.
Le 7/8/2003 à 23:40:6 : début du travail 'AFaire6' numéro 6.
Le 7/8/2003 à 23:40:10 : fin du travail 'AFaire6' numéro 6.
Le 7/8/2003 à 23:40:10 : début du travail 'AFaire3' numéro 3.
Le 7/8/2003 à 23:40:12 : fin du travail 'AFaire3' numéro 3.

Supposons qu'un applicatif soit conçu sur une architecture client-serveur. Par principe, un serveur traite plusieurs clients. Le temps qu'un client travaille, le serveur peut traiter le demande de plusieurs autres clients.

Dans le cadre d'un applicatif complexe, les demandes successives d'un même client ne sont pas indépendantes. En effet, il existe une relation de causalité ce qui demande de gérer un contexte par client regroupant des informations persistantes entre deux demandes. Ce contexte regroupe un ensemble de variables traduisant l'état du client. Nous pouvons y trouver :

Up ! System possède le mécanisme d'instances pour gérer automatiquement le contexte d'un client lors de l'écriture du programme du serveur. Une instance correspond au contexte d'exécution d'un client particulier du serveur. Up ! System possède des API pour créer une nouvelle instance lorsque le client se connecte au serveur (CreerInstance), pour changer d'instance lorsqu'il est nécessaire de traiter la demande d'un client (CommuterInstance) ou terminer une instance lorsque le client se déconnecte du serveur (ArreterInstance).

Le principe des instances est bien différent de celui d'une tâche : une instance permet de faire de la sérialisation alors qu'une tâche permet de faire du parallélisme.

Quand l'applicatif est multi-instance, il reste à signifier à Up ! Application System quelles sont les informations propres à une instance et quelles sont celles qui sont partagées. Cela se résout aisément au moyen du mode de partage des segments de données.

Un module comporte des mémoires dans lequel sont regroupées les variables et les références vers les objets particuliers de chacun de ces composants : exceptions, files d'attente, entrepôts, types, etc. Ces mémoires sont de trois sortes : Chaque segment de mémoire peut être qualifié selon le mode de partage voulu en fonction de ce qui doit être ou non mis en commun par deux instances gérées par un même processus ou par deux instances gérées par deux processus d'un même programme : Par défaut, le mode de partage d'un segment de mémoire est MemoireProtegee. Au cours de l'exécution du programme, Up ! Virtual Technical Machine peut alimenter des journaux reportant l'activité du processus.

Il ne faut pas confondre ces journaux avec les journaux mémorisant les modifications apportées aux objets des entrepôts persistants. Ceux-ci servent pour le mécanisme de reprise en cas d'arrêt brutal d'un programme persistant.

Optionnellement, un journal de l'activité du processus est maintenu. Ce journal est alimenté si le paramètre Journal d'Up ! Virtual Technical Machine est spécifié, si le processus est lancé en batch au moyen du paramètre batch d'Up ! Virtual Technical Machine ou si le programme est un serveur.

Ce journal porte alors le nom du processus. Il est conservé dans le répertoire ${UPS_HOME}/log en mode mono-utilisateur ou ${UPS_HOME}/log/${UPS_USER} en mode multi-utilisateurs.

Le contenu de ce journal correspond à ce que vous écrivez dans la variable Journal de type Fichier. Si l'option d'exécution d'Up ! Kernel TracerException est activée, alors toutes les exceptions envoyées par une des tâches du processus sont reportées dans le journal.

Optionnellement, un journal des travaux peut être maintenu pour chaque file d'attente. Ce journal est alimenté si la méthode ActiverJournal du type FileDAttente est appelée.

Ce journal porte alors le nom de la file. Il est conservé dans le répertoire ${UPS_HOME}/log en mode mono-utilisateur ou ${UPS_HOME}/log/${UPS_USER} en mode multi-utilisateurs.

Voici le contenu du journal pour l'exemple traitant des files d'attente :

Le 7/8/2003 à 23:39:35 : planification du travail 'AFaire1' numéro 1 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:35 : planification du travail 'AFaire2' numéro 2 au plus tard le 7/8/2003 à 23:39:45.
Le 7/8/2003 à 23:39:35 : début du travail 'AFaire2' numéro 2.
Le 7/8/2003 à 23:39:36 : planification du travail 'AFaire3' numéro 3 au plus tôt le 7/8/2003 à 23:39:60.
Le 7/8/2003 à 23:39:37 : fin du travail 'AFaire2' numéro 2.
Le 7/8/2003 à 23:39:37 : planification du travail 'AFaire4' numéro 4 synchronisé avec d'autres travaux.
Le 7/8/2003 à 23:39:37 : planification du travail 'AFaire5' numéro 5 synchronisé avec d'autres travaux.
Le 7/8/2003 à 23:39:37 : planification du travail 'AFaire6' numéro 6 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:38 : planification du travail 'AFaire7' numéro 7 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:39 : planification du travail 'AFaire8' numéro 8 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:40 : début du travail 'AFaire5' numéro 5.
Le 7/8/2003 à 23:39:40 : planification du travail 'AFaire9' numéro 9 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:41 : fin du travail 'AFaire5' numéro 5.
Le 7/8/2003 à 23:39:43 : planification du travail 'AFaire10' numéro 10 au plus tôt le 7/8/2003 à 23:39:50.
Le 7/8/2003 à 23:39:57 : début du travail 'AFaire7' numéro 7.
Le 7/8/2003 à 23:39:59 : fin du travail 'AFaire7' numéro 7.
Le 7/8/2003 à 23:39:59 : début du travail 'AFaire1' numéro 1.
Le 7/8/2003 à 23:40:0 : fin du travail 'AFaire1' numéro 1.
Le 7/8/2003 à 23:40:0 : début du travail 'AFaire4' numéro 4.
Le 7/8/2003 à 23:40:3 : fin du travail 'AFaire4' numéro 4.
Le 7/8/2003 à 23:40:3 : début du travail 'AFaire8' numéro 8.
Le 7/8/2003 à 23:40:4 : fin du travail 'AFaire8' numéro 8.
Le 7/8/2003 à 23:40:4 : début du travail 'AFaire9' numéro 9.
Le 7/8/2003 à 23:40:5 : fin du travail 'AFaire9' numéro 9.
Le 7/8/2003 à 23:40:5 : début du travail 'AFaire10' numéro 10.
Le 7/8/2003 à 23:40:6 : fin du travail 'AFaire10' numéro 10.
Le 7/8/2003 à 23:40:6 : début du travail 'AFaire6' numéro 6.
Le 7/8/2003 à 23:40:10 : fin du travail 'AFaire6' numéro 6.
Le 7/8/2003 à 23:40:10 : début du travail 'AFaire3' numéro 3.
Le 7/8/2003 à 23:40:12 : fin du travail 'AFaire3' numéro 3.

Lorsque Up ! Common Object Request Broker Architecture est mis en mode trace au moyen de l'option d'exécution TracerCorba=O, un journal est alimenté pour chaque entrée-sortie dans un module Up ! Application System se comportant dans comme un serveur Corba.

Ce journal est conservé dans le fichier ${UPS_HOME}/log/${UPS_APPLICATION}-upscrb-${NumeroSession}.log en mode mono-utilisateur ou dans le fichier ${UPS_HOME}/log/${UPS_USER}/${UPS_APPLICATION}-upscrb-${NumeroSession}.log en mode multi-utilisateur.

Ce journal permet notamment de mettre au point l'usage d'un serveur Corba correspondant à un module Up ! Application System afin de se rendre compte si le client transmet les bonnes valeurs de paramètres. Voici le contenu du journal :

-> Annuaire.LireArborescenceAnnuaire(0x01cc6d68)
<- OK
-> EstNul(0x00000000)
<- OK
-> Liste.DernierElement()

<- OK
-> Identique(0x01cc6368,0x01cc6ea8)
<- OK
-> Liste.Suivant(0) <- OK
-> CorbaString2Caractere() <- OK
-> Caractere.!=(0x01cc7128) <- OK
-> Booleen2CorbaBoolean(0x01cc7268)
<- OK
-> CorbaString2Caractere(.) -> Caractere.+(0x01cc73a8) <- OK
-> Caractere.+(0x01cc6fe8) <- OK
-> Caractere2CorbaString(0x01cc7628)
<- OK
-> CorbaString2Caractere(.) <- OK

Ce journal permet notamment de mettre au point l'usage d'un serveur Corba correspondant à un module Up ! Application System afin de se rendre compte si le client transmet les bonnes valeurs de paramètres.

Lorsque Up ! Component Object Module est mis en mode trace au moyen de l'option d'exécution TracerCom=O, un journal est alimenté pour chaque entrée-sortie dans un module Up ! Application System se comportant dans comme un serveur Com Inproc Server ou Com Outproc Server.

Ce journal est conservé dans le fichier ${UPS_HOME}/log/${UPS_APPLICATION}-upscom-${NumeroSession}.log en mode mono-utilisateur ou dans le fichier ${UPS_HOME}/log/${UPS_USER}/${UPS_APPLICATION}-upscom-${NumeroSession}.log en mode multi-utilisateur.

Voici le contenu du journal :

-> IDispatch.GetIDsOfNames(0x00ce27c0,DComBStr2Caractere)
<- S_OK
-> IDispatch.Invoke(0x00ce27c0,1610743948,3)

<- S_OK
-> IDispatch.GetIDsOfNames(0x00ce27c0,Binaire2)
<- S_OK
-> IDispatch.Invoke(0x00ce27c0,1610743904,3) <- S_OK
-> IDispatch.GetIDsOfNames(0x00ceacd0,AdditionnerAffecter) <- S_OK
-> IDispatch.Invoke(0x00ceacd0,1610743825,1) <- S_OK
IUnknown.Release(0x00ceb060)
IUnknown.Release(0x00ceaf30)

Ce journal permet notamment de mettre au point l'usage d'un serveur Com correspondant à un module Up ! Application System afin de se rendre compte si le client transmet les bonnes valeurs de paramètres.

Lorsque Up ! Java est mis en mode trace au moyen de l'option d'exécution TracerJava=O, un journal est alimenté pour chaque entrée-sortie dans un module Up ! Application System se comportant dans comme un serveur Java.

Ce journal est conservé dans le fichier ${UPS_HOME}/log/${UPS_APPLICATION}-upsjav-${NumeroSession}.log en mode mono-utilisateur ou dans le fichier ${UPS_HOME}/log/${UPS_USER}/${UPS_APPLICATION}-upsjav-${NumeroSession}.log en mode multi-utilisateur.

Voici le contenu du journal :

-> UpsKrnSJ.JavaString2Caractere(0x0007fab8)

<- '0x00a05860'
-> UpsKrnSJ.JavaString2Caractere(0x0007fab4) <- '0x00a05860'
-> UpsKrnSJ.JavaString2Caractere(0x0007fab0) <- '0x00a05860'
-> UpsKrnSJ.JavaString2Caractere(0x0007fab4) <- '0x00a05864'
-> UpsKrnSJ.JavaString2Caractere(0x0007fab0) <- '0x00a05860'

Ce journal permet notamment de mettre au point l'usage d'un serveur Java correspondant à un module Up ! Application System afin de se rendre compte si le client transmet les bonnes valeurs de paramètres.

Lorsqu'il est demandé à Up ! Kernel de mesurer les performances au moyen de l'option d'exécution PeriodePerformance=O, un journal est alimenté périodiquement par la tâche Up ! Moniteur. Elle doit alors être activée au moyen de du paramètre periodemoniteur.

Ce journal est conservé dans le fichier ${UPS_HOME}/log/${UPS_APPLICATION}-upskrn-${NumeroSession}.log en mode mono-utilisateur ou dans le fichier ${UPS_HOME}/log/${UPS_USER}/${UPS_APPLICATION}-upskrn-${NumeroSession}.log en mode multi-utilisateur.

Voici le contenu du journal :

No=1 : NbTaches 3 TempsUtilisateur 0.740% TempsSysteme 0.100%

No=2 : NbTaches 3 TempsUtilisateur 0.000% TempsSysteme 0.000%
No=3 : NbTaches 3 TempsUtilisateur 0.000% TempsSysteme 0.000%
No=4 : NbTaches 3 TempsUtilisateur 0.000% TempsSysteme 0.000%
No=5 : NbTaches 3 TempsUtilisateur 0.000% TempsSysteme 0.000%

Ce journal permet notamment de mettre au point la configuration mémoire optimale pour le programme en fonction de son activité.

Lorsque Up ! Network est mis en mode trace au moyen de l'option d'exécution TracerCommunication=O, un journal est alimenté pour chaque entrée-sortie dans un module Up ! Application System se comportant dans comme un client ou serveur de communication inter-application.

Ce journal est conservé dans le fichier ${UPS_HOME}/log/${UPS_APPLICATION}-upsnet-${NumeroSession}.log en mode mono-utilisateur ou dans le fichier ${UPS_HOME}/log/${UPS_USER}/${UPS_APPLICATION}-upsnet-${NumeroSession}.log en mode multi-utilisateur.

Voici le contenu du journal :

No=817 : Recu de l'en-tete du message 'OuvrirSession' de 'UpsTcp:127.0.0.1/1635' suivi de 0 octets.
No=818 : Envoi de l'en-tete du message 'Reponse' vers 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=819 : Fin de l'envoi vers 'UpsTcp:127.0.0.1/1634'.
No=820 : Recu de l'en-tete du message 'MethodeSansParametre' de 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=821 : Envoi de l'en-tete du message 'Reponse' vers 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=822 : Fin de l'envoi vers 'UpsTcp:127.0.0.1/1634'.
No=823 : Recu de l'en-tete du message 'NePlusUtiliserObjet' de 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=824 : Envoi de l'en-tete du message 'Reponse' vers 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=825 : Fin de l'envoi vers 'UpsTcp:127.0.0.1/1634'.
No=826 : Recu de l'en-tete du message 'MethodeSansParametre' de 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=827 : Envoi de l'en-tete du message 'Reponse' vers 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=828 : Fin de l'envoi vers 'UpsTcp:127.0.0.1/1634'.
No=829 : Recu de l'en-tete du message 'NePlusUtiliserObjet' de 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=830 : Envoi de l'en-tete du message 'Reponse' vers 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=831 : Fin de l'envoi vers 'UpsTcp:127.0.0.1/1634'.
No=832 : Recu de l'en-tete du message 'MethodeSansParametre' de 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.
No=833 : Envoi de l'en-tete du message 'Reponse' vers 'UpsTcp:127.0.0.1/1634' suivi de 0 octets.

Le contenu de ces fichiers de tracer ne peuvent qu'être analysé par les techniciens du support technique. Lorsqu'il arrive un problème d'exécution grave, un journal d'alerte est alimenté. Généralement, un tel problème a pour effet d'arrêter la tâche étant donné qu'il est rarement prévu dans le programme d'attraper les exceptions d'Up ! Kernel ou d'Up ! Object Management System. Il peut s'agir par exemple d'un interblocage entre plusieurs tâches, une liaison réseau qui ne répond plus, etc.

Ce journal porte alors le nom ${UPS_HOME}/log/${UPS_APPLICATION}-upsoms-${NumeroSession}.log en mode mono-utilisateur ou dans le fichier ${UPS_HOME}/log/${UPS_USER}/${UPS_APPLICATION}-upsoms-${NumeroSession}.log en mode multi-utilisateur. La session est l'identification d'un tâche issue d'un processus ou d'un groupe de processus partageant des ressources au sein d'Up ! System.

Ce journal d'alerte est alimenté en continu quand l'option TracerNoyau d'Up ! Object Management System est activée.

Voici le contenu du journal :

Interblocage pour 7 :
Actif 65596 Cache 12 Bloc 98 Index 2 TypeVerrou LecturePartagee Proprietaire 8 Date 0
Actif 65592 Cache 12 Bloc 98 Index 0 TypeVerrou LecturePartagee Proprietaire 8 Date 0
Bloque 65595 Cache 12 Bloc 98 Index 5 TypeVerrou LecturePartagee Proprietaire 7 Date 0
Actif 65599 Cache 12 Bloc 98 Index 5 TypeVerrou LecturePartagee Proprietaire 8 Date 0
Actif 65587 Cache 12 Bloc 98 Index 9 TypeVerrou LecturePartagee Proprietaire 8 Date 0
Actif 65600 Cache 12 Bloc 98 Index 5 TypeVerrou LecturePartagee Proprietaire 8 Date 0
Actif 65598 Cache 16 Bloc 130 Index 0 TypeVerrou EcritureExclusive Proprietaire 7 Date 0
Bloque 65597 Cache 16 Bloc 130 Index 0 TypeVerrou EcritureExclusive Proprietaire 8 Date 0

Le contenu de ces fichiers d'alerte ne peuvent qu'être analysé par les techniciens du support technique. Pour Up ! System, un programme a deux états : Un même programme peut être exécuté simultanément par plusieurs utilisateurs sur un même ordinateur ou sur différents ordinateurs. Chaque exécution forme alors un processus caractérisé par : Un processus est identifié de manière unique par le couple (numéro de la machine, numéro du processus).

La variable NumeroProcessus contient le numéro du processus du programme courant.

Pour connaître les programmes en cours d'exécution, il faut utiliser la fonction ListerProcessus d'Up ! System. Celle-ci retourne la description de chaque processus de la machine courante sous forme d'un objet du type ProcessusListe.

Pour Up ! System, les unités de stockages sont organisées en hiérarchies. Chaque niveau d'une hiérarchie est un répertoire. Il n'y a pas de limite quant à la profondeur de la hiérarchie. La base de cette hiérarchie pour une unité donnée est le répertoire racine symbolisé par le caractère division / ou le caractère division inversé \.

Un répertoire porte un nom composé de caractères éditables et sans limite de taille. Il peut comporter des caractères non alpha-numérique tel le caractère espace. Seuls les caractères division / et division inversé \ ne sont pas acceptés.

Un répertoire appartient à un utilisateur (son propriétaire) et possède des droits d'accès vis-à-vis de son propriétaire et de groupes d'utilisateur.

La variable RepertoireTmp contient le répertoire où doivent être créés les fichiers temporaires. Sa valeur provient du paramètre tmp.

Si plusieurs tâches cohabitent, d'un même ou de plusieurs processus, alors celles-ci partagent des données et des ressources communes. Les synchronisations d'Up ! System sont nécessaires pour garantir un bon fonctionnement de l'applicatif. Il y en a de deux types : Le type Synchronisation d'Up ! System permet gérer les synchronisations fonctionnelles des tâches. Il permet en particulier d'en créer de spécifiques. Pour prendre une synchronisation, il suffit d'appeler la méthode Prendre. Si la synchronisation a déjà été prise par une autre tâche, alors la tâche est suspendue temps que la synchronisation n'est pas lâchée et que ce n'est pas son tour de la prendre : la file des tâches en attente sur une synchronisation est gérée Premier Arrivé Premier Servi i.e. First In First Out (FIFO).

Pour lever une synchronisation préalablement posée, il suffit d'appeler la méthode Lacher.

En règle générale, les synchronisations sont levées lors de l'appel à la méthode Lacher. Cependant, il se peut qu'il existe un imprévu aie lieu dans le programme suite à une exception ou suite à un dysfonctionnement. En ce cas, des synchronisations prises par la tâche essuyant cet imprévu sont automatiquement levées. Voici de tels cas de figure : Un processus est constitué de plusieurs tâches s'exécutant en parallèle. Une tâche est un traitement unitaire autonome. Il existe deux sortes de tâches : Chaque tâche est caractérisée par : La variable TachePrincipale d'Up ! System identifie la tâche principale du processus.

Le type Tache d'Up ! System permet gérer les tâches des processus. Il permet en particulier d'en créer de spécifiques.

Up ! Object Management System comporte des tâches spécifiques. Ces dernières sont listées dans le document Architecture d'un processus d'un programme en technologie Up ! Virtual Technical Machine.

Up ! System comporte des tâches servant à gérer :

Up ! System reconnaît les unités de stockage formatées qui sont en ligne au moment de l'exécution d'un programme Up ! Application System. Ces unités de stockage peuvent être : Pour connaître les unités de stockage disponibles, il faut utiliser la fonction ListerUnites d'Up ! System. Celle-ci retourne la description de chaque unité sous forme d'un objet du type UniteListee.

Ces informations vous seront particulièrement utiles pour écrire un module d'installation ou de configuration de votre applicatif.

Une variable environnement est une entité définie pour la session courante. Cette entité possède un nom et une valeur. Généralement, leur nom est en majuscule. Pour obtenir, la valeur d'une variable environnement, il suffit de précéder son nom du caractère dollar $.

On peut définir autant de variables environnement que nécessaire.

UPS_HOME, UPS_PATH et UPS_USER sont des variables environnement. Elles alimentent respectivement les variables UpsHome, UpsPath et UpsUser.

Up ! System met à la disposition des programmes les pseudo variables environnement suivantes :

VariableSignification
SYSTEM_HOMERépertoire d'installation du système d'exploitation.
UPS_APPLICATIONIdentifiant de l'application au sein de Up ! Virtual Technical Machine.
UPS_HOMERépertoire d'installation d'Up ! Application System.
UPS_LANGUAGEIdentifiant de la langue au sein de Up ! Virtual Technical Machine.
UPS_NLSListe des chemins d'accès aux ressources linguistiques d'Up ! Application System.
UPS_PATHListe des chemins d'accès aux exécutables d'Up ! Application System.
UPS_PROJECTIdentifiant du projet au sein de Up ! Virtual Technical Machine.
UPS_USERIdentifiant de l'utilisateur au sein de Up ! Virtual Technical Machine.

Ces variables sont uniquement utilisables en lecture.

Elles peuvent être également employées dans la valeur de tous les paramètres de tous les modules de Virtual Technical Machine dont la sémantique correspond à un nom de répertoire ou de fichier.

En ce cas, le nom de la variable doit être écrit entre caractères accolade ouvrante { et accolade fermante } et précédée du caractère dollar $. Voici un exemple :

tmp=${UPS_HOME}/demo/tmp/${UPS_USER}



Revenir en haut de la page...