IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Cobol Discussion :

[Divers] Découpe des programmes


Sujet :

Cobol

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Décembre 2004
    Messages : 49
    Points : 36
    Points
    36
    Par défaut [Divers] Découpe des programmes
    Salut à tous,


    je travaille dans une société qui fait des développements web et des développements batch en cobol. Aujourd'hui, je m'occupe des développements web et pour la programmation, nous avons décidé de couper cela en 3 couches soit :
    la couche présentation
    la couche business
    la couche accès IO

    Dans les développements batch COBOL, les programmeurs sont habités de tout mettre dans un programme ( naturellement pas de présentation ici).
    Je voudrais bien appliquer plus ou moins la même découpe pour les batch que pour les développements web mais je ne sais pas si mon idée est bonne.

    Je retourne donc vers vous et fait appel à votre expérience dans ce domaine.

    merci pour votre aide

  2. #2
    Membre du Club
    Inscrit en
    Juin 2007
    Messages
    60
    Détails du profil
    Informations personnelles :
    Âge : 60

    Informations forums :
    Inscription : Juin 2007
    Messages : 60
    Points : 62
    Points
    62
    Par défaut
    Salut,

    J'ai moi-même travaillé dans une banque qui appliquait des règles similaires (collecte, traitement, restitution) sur le batch.

    C'est une façon comme une autre de travailler.
    Cela évite en tout cas d'avoir des programmes fourre-tout qui deviennent parfois difficiles à maintenir à cause de leur complexité.

    J'ai tendance, depuis, à découper mes applis en plusieurs programmes dédiés chacun à une fonction déterminée plutôt que de faire des gros pavets bien repoussants.

    Autre côté intéressant : on localise plus rapidement en cas de problème.

  3. #3
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    Bonjour à tous.

    Heureux de constater qu'on est peut être en train de revenir aux vieux principes de la conception et de l'analyse fonctionnelle.

    En effet, autant que faire se peut, on essayait de découper une applic en Unités de Traitement (UT). Chaque unité assure en fait une fonction homogène complète qui peut comprendre des sous-unités partagées entre plusieurs de ces fonctions. Ces sous-unités étant les sous-programmes, les fonctions externes, les transactions, les fonctions de service, etc....

    Par exemple : dans le traitement de la paie du personnel (une des trois glorieuses), l'édition des bulletins est une Unité de Traitement, mais l'édition d'un bulletin peut être considérée comme une sous-unité (S/pgm) parce qu'on peut aussi l'utiliser dans un autre process (duplicata par exemple). Un processus étant un enchainement de plusieurs UTs.

    Autre exemple qui peut être légèrement plus complexe malgré sa simplicité : La gestion du Plan Comptable peut constituer une UT à part entière avec toutes ses options : Affichage de la liste (S/Fichier) selon plusieurs clés d'accès (par code ou par libellé par exemple), Création, Modification, Copie, Supprression, Affichage, Impression, Définition des rubriques de regroupement, etc... Mais on peut aussi dire que l'affichage du plan comptable ou l'impression ou encore la gestion des regroupement peuvent utiliser ailleurs, par exemple lors de la saisie des écritures. Alors on va décomposer ça en sous-unités de traitement à part.....

    Alors bien sûr on va faire des supers programmes ou des supers fonctions (ou des menus) qui regrouperont toutes ces Unités en applic. Il va y avoir des call partout, des enchaînements par le jcl, etc...

    AMHA, l'essentiel est de bien considérer les règles (critères), la finesse et les objectifs de découpe, de bien refléchir aux fonctions primaires non décomposables, de voir ce que l'on peut considérder comme une fonction, une sous-fonction, une fonction (pgm) de service, une fonction répétitive, etc...

    Il faudrait aussi penser à la méthodologie, en particulier à la modélisation. Est ce qu'elle permettrait ça ou non ?? aux langages de programmation : adaptés ou non. L'environnement ILE est assez intéressant à voir.

    Excuser de ce baratin assez long et fait à la volée, mais il y a matière à réflexion et la question est loin d'être banale

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Décembre 2004
    Messages : 49
    Points : 36
    Points
    36
    Par défaut
    merci pour vos réponses.

    En effet, la découpe des programmes mais surtout l'analys fonctionnelle et technique me semblent un élément essentiel.

    Je travaille avec des collègues qui ont des années d'expérience mais qui ont l'habitude de tout mettre dans un seul programme.

    Le point négative que l'on avance à chaque fois que je parle de découpe est le temps d'exécution plus long !

    Une autre question qui me vient à la tête est la façon de gérer les sources. Avez-vous une expérience dans l'utilisation d'un gestionnaire de sources?

  5. #5
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par lecitoyen Voir le message
    ...
    Dans les développements batch COBOL, les programmeurs sont habités de tout mettre dans un programme ( naturellement pas de présentation ici).
    Je voudrais bien appliquer plus ou moins la même découpe pour les batch que pour les développements web mais je ne sais pas si mon idée est bonne...
    Les données sont stockées comment ?
    Fichiers ? si oui quel type ?
    Bases de données ?

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2007
    Messages : 362
    Points : 419
    Points
    419
    Par défaut
    Citation Envoyé par lecitoyen Voir le message
    Je travaille avec des collègues qui ont des années d'expérience mais qui ont l'habitude de tout mettre dans un seul programme.

    Le point négative que l'on avance à chaque fois que je parle de découpe est le temps d'exécution plus long !
    C'est très discutable comme argument.

    Tout d'abord, dans de gros traitements batchs, on accède souvent à plusieurs référenciels (par exemple Client, Contrat, etc.), et souvent sur des clefs différentes. Le fait que les données ne puissent être triées sur la clef d'accès à chaque référentiel ralenti considérablement le traitement (puisque le SGBD ou le SGF vont passer leur temps à charger des pages en mémoire). La solution consiste à trier le fichier entre chaque programme applicatif.

    Ensuite, en cas de problème, il est bien plus simple de le localiser si chaque tâche est séparée. Et le traitement pourra être relancé au step qui posait problème.

    Enfin, la réutilisation des programmes est plus facile s'ils sont simples et font un travail clairement délimité.

    En bref, une tâche, un programme !

  7. #7
    Membre expérimenté

    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    1 298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 298
    Points : 1 578
    Points
    1 578
    Par défaut
    Sur quelle plateforme matérielle ces programmes sont-ils susceptibles de tourner ?

  8. #8
    Membre confirmé Avatar de Homer-ac
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    449
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2007
    Messages : 449
    Points : 586
    Points
    586
    Par défaut
    Juste quelques remarques pour ceux qui adossent la modularité aux performances.
    1) Le coût le plus important dans une société n'est pas le développement mais la maintenance.
    2) Si on est confronté à un pb de performances, il est plus facile de zoomer sur une fonction isolée.
    3) Sans entrer dans une analyse fine des fonctions, le simple fait de séparer acquisition, règles de gestion et restitution, en modules distincts simplifient autant l'écriture, les tests que la maintenance évolutive.
    Prenons l'exemple d'un module d'accès à des données fichier. Si on prend simplement la précaution de demander (et de vérifier dès le départ) un numéro de version à l'appelant, le module pourra lui restituer le 'vue' qu'il attend sans qu'il s'agisse nécessairement de bases type DB2, en cas d'évolution du fichier, voire d'organisation.
    Quant aux performances, cela éviterait la généralisation de paquets de FILLER et donc de la mémoire inutile, souvent vus dans des descriptions de fichiers, 'au cazou'
    Id pour la restitution à commencer par celle des cas d'erreurs. Si on passe par un module centralisé sur numéro de message d'erreur et éventuellement code gravité, la validation de la gestion d'un seul cas donne en plus d'un répertoire utile au dossier de mise en prod., une assez bonne garantie d'une gestion correcte des cas les plus improbables.
    Des sociétés ont parfois développés ou préconisés de tels modules qui permettent accessoirement la tracabilité. Pas nécessairement des erreurs mais pour savoir si par exemple des données fichiers sont encore utiles ou pour éviter des redondances. Celles-ci ont très certainement eu une meilleure visibilité, pour le passage à l'Euro par exemple.
    Bon, ces remarques simplement pour montrer, en accord avec d'autres remarques précédentes, le propos est loin d'être banal et que ces découpages peuvent être plus importants qu'il n'y parait comparés à des arguments de performances basiques.

  9. #9
    Membre confirmé Avatar de Homer-ac
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    449
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2007
    Messages : 449
    Points : 586
    Points
    586
    Par défaut
    Un oubli quant à l'expérience d'un gestionnaire de source. Sur Mainframe, je connnais assez bien ENDEVOR. C'est un produit assez lourd mais c'est la contrepartie d'une gestion très rigoureuse des versions et des flux des tests unitaires jusqu'à la mise en prod.

  10. #10
    Membre éclairé Avatar de Peut-êtreUneRéponse
    Homme Profil pro
    IT Specialist - IBM Z
    Inscrit en
    Décembre 2006
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : IT Specialist - IBM Z
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2006
    Messages : 548
    Points : 801
    Points
    801
    Par défaut
    Une autre question qui me vient à la tête est la façon de gérer les sources. Avez-vous une expérience dans l'utilisation d'un gestionnaire de sources?
    ENDEVOR, CCC (ASG-LCM), CHANGEMAN. Ma préférence va à LCM (sûrement parce que j'y suis le plus habitué), je trouve la gestion des sources de CHANGEMAN ("en étoile") trop risquée et peu souple.

  11. #11
    Membre averti
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2007
    Messages : 362
    Points : 419
    Points
    419
    Par défaut
    Citation Envoyé par Peut-êtreUneRéponse Voir le message
    Ma préférence va à LCM
    +1

  12. #12
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    Bonjour.

    Le problème des performances est toujours discutable et "relativisable" quand il s'agit de la décomposition en "taches" d'un processus quelconque.

    - Primo, comme cela a été évoqué, plus on "perd" du temps dans les différentes phases d'analyse, plus on en gagne dans les tests, la mise en production et surtout dans la maintenance.
    - Secundo, si une bonne fonctionnelle a bien préparé le terrain à une aussi bonne analyse organique, si la modélisation et la structuration des données a été correctement faite, alors quels gains de temps, maintenant, dans les traitements. Peut être plus longs en terme de kilométrage (volume) mais pas en terme de temps. Je fais attention, je vais dire une bêtise : la linéarité des traitements n'est pas forcement un inconvénient.
    - Tercio, la puissance des machines d'aujourd'hui n'est pas celle d'hier (pléonasme). Ceci pour dire que les nanno-secondes et les quelques bits qu'on cherchait à gagner ne sont plus de mise.
    - quarto, ne pas tellement tenir compte des plateformes et des systèmes d'exploitation dans ce genre de phases, mais plutôt des moyens qui seront utilisés et des couches des logiciels : SGBDR, outils de requêtes, langages de programmation, environnements de développement, environnement de production, etc....

    A creuser.

  13. #13
    Membre régulier
    Homme Profil pro
    Dévelopeur Cobol + Java J2SE
    Inscrit en
    Novembre 2007
    Messages
    72
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Dévelopeur Cobol + Java J2SE
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 72
    Points : 77
    Points
    77
    Par défaut
    Effectivement en règle générale, 1 programme par tache. Se rappeler que la maintenance représente 80% des couts d'une application. Par contre faut essayer de pas avoir 50 programmes non plus. Quand je pense que dans ma banque ils veulent passer à java ça me fait pleurer; la maintenance va prendre 5 fois plus de temps, les temps d'execution vont augmenter, bref tout ce que j'aime dans le main frame, tchao.

  14. #14
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    Bonjour.

    Bien sûr il ne faut pas tomber dans l'excès inverse où l'on pisse des kilomètres de code Cobol ou JCL pour faire des opérations à la noix.
    Je suis tombé une fois chez un client à l'occasion du réengeneering Y2K d'une application sur une procédure JCL de 1500 lignes, exécutant dans la foulée une cinquantaine (ou plus) de programmes, une trentaine de phases de tri. Des programmes à part entière rien que pour calculer une rubrique à partir d'une expression arithmétique simple. A la limite d'accord si les calculs sont complexes et éventuellement utilisés en plusieurs endroits.
    Après refonte de cette procédure et des programmes utilisés, le process ne dure plus que 10 mn au lieu des 2 heures.
    Un prgramme de gestion d'un fichier clients, par exemple, doit comprendre toutes les actions qu'on peut faire sur ce fichier : création, modification, affichage, impression, affichage des mouvements du client, etc... que sais-je ?? Par contre dès qu'une fonction complexe qui serait utilisée dans plusieurs programmes s'impose, il faudrait la programmer à part et l'appeler là où il faut.

    Généralement on distinguera les fonctions de saisie et de mise à jour contrôlées, etc..., les fonctions de calcul, des traitements complexes et puis les restitutions, les analyses, les requêtes, les impressions, les consultations, etc...

    A suivre....

  15. #15
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Décembre 2004
    Messages : 49
    Points : 36
    Points
    36
    Par défaut
    A la lecture de vos commentaires, je remarque que la tendance va à une découpe correcte des programmes en module fonctionnel.
    Notre métier tourne autour de la paie et il est donc important d'avoir un temps d'éxecution rapide mais aussi une maintenance facile.

    Toutes nos données se trouvent dans une base de données DB2 et une des options choisies pour la réécriture est de copier la BD dans un fichier séquentiel et puis de traiter ce fichier pour terminer par un réinjection dans la DB.

    Cela ne me semble pas très efficace comme méthode de travail, je crois que l'on peut directement travailler avec la base de données.
    Mon expérience dans ce domaine est réduite et j'aimerais avoir votre opinion sur ce sujet.

    En ce qui concerne le gestionnaire des sources, nous travaillons sur un mainframe ibm.

  16. #16
    Membre éclairé Avatar de Peut-êtreUneRéponse
    Homme Profil pro
    IT Specialist - IBM Z
    Inscrit en
    Décembre 2006
    Messages
    548
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : IT Specialist - IBM Z
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2006
    Messages : 548
    Points : 801
    Points
    801
    Par défaut
    Citation Envoyé par lecitoyen Voir le message
    Toutes nos données se trouvent dans une base de données DB2 et une des options choisies pour la réécriture est de copier la BD dans un fichier séquentiel et puis de traiter ce fichier pour terminer par un réinjection dans la DB.

    Cela ne me semble pas très efficace comme méthode de travail, je crois que l'on peut directement travailler avec la base de données.
    Mon expérience dans ce domaine est réduite et j'aimerais avoir votre opinion sur ce sujet.
    C'est une solution courante sous mainframe IBM.

    Il faut savoir que les utilitaires de load/unload pour DB2 sont très performants et très rapides. Si les données à chargées ne nécessitent pas une disponibilité immédiate, un batch quotidien avec déchargement, traitement, rechargemnt peut-être envisagé avec d'excellentes performances.

    .

  17. #17
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    Bonjour.

    Je suis un peu surpris par ce choix. Si travail "coopératif" il y a, il ne faut pas non plus que l’on revienne à la carte perforée.

    Ce n’est pas seulement qu’on peut travailler directement sur les bases de données, mais il faut le faire. Je pense aussi que le maximum des outils de traitement qui seront crées, doivent être sur le même serveur (peut être le même serveur que les données) : pour des raisons de maintenance, de dispersion et d’éparpillement des objets et de leurs niveaux de versions, d’accès par plusieurs développeurs, des normes de développement, etc. Certains traitements s’exécuteront sur les postes clients. On peut faire des copies partielles des BD ou descendre sur les postes clients des enregistrements à traiter, mais pas les BD et certainement pas en fichiers séquentiels.
    Sur les mainframes, que j’ai connu quand j’avais plus de cheveux sur le crâne et que j’ignore totalement aujourd’hui, il doit y avoir énormément de logiciels qui permettent l’accès depuis les postes clients au serveur DB2 soit directement soit via les ODBC.

    A+

  18. #18
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    Salut peut-êtreUneRéponse,

    Désolé pour le téléscopage, j'ai préparé mon post avant de voir le tien. Tu ne trouves pas curieux cette méthode de va-et-vien pour du temps réel ?

  19. #19
    Membre averti
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    362
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2007
    Messages : 362
    Points : 419
    Points
    419
    Par défaut
    Citation Envoyé par Hédhili Jaïdane Voir le message
    Salut peut-êtreUneRéponse,

    Désolé pour le téléscopage, j'ai préparé mon post avant de voir le tien. Tu ne trouves pas curieux cette méthode de va-et-vien pour du temps réel ?
    Je ne pense pas que ce schéma soit (puisse être) appliqué pour du temps réel. Lecitoyen a parlé au départ de traitement temps réel et batch.

  20. #20
    Membre expert
    Homme Profil pro
    Retraité
    Inscrit en
    Octobre 2005
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Finance

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 473
    Points : 3 283
    Points
    3 283
    Par défaut
    Citation Envoyé par lecitoyen Voir le message
    ...
    Toutes nos données se trouvent dans une base de données DB2 et une des options choisies pour la réécriture est de copier la BD dans un fichier séquentiel et puis de traiter ce fichier pour terminer par un réinjection dans la DB.

    Cela ne me semble pas très efficace comme méthode de travail, je crois que l'on peut directement travailler avec la base de données.
    Mon expérience dans ce domaine est réduite et j'aimerais avoir votre opinion sur ce sujet ...
    Effectivement, on peut se demander quel est l'intérêt d'avoir une Base de données si c'est pour travailler sur des fichiers séquentiels ...

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. pb d'affichage des programmes
    Par loveflower dans le forum Autres Logiciels
    Réponses: 9
    Dernier message: 09/01/2006, 13h23
  2. Réponses: 1
    Dernier message: 01/12/2005, 00h14
  3. Réponses: 7
    Dernier message: 16/04/2005, 09h55
  4. Association des programmes aux fichiers: icônes
    Par jamesb dans le forum C++Builder
    Réponses: 6
    Dernier message: 15/01/2005, 20h17
  5. existe t 'il des programme pour transformer les bases
    Par creazone dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 05/10/2004, 15h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo