Passage de données d'un JOB a un autre [Résolu]

[hermellin]

Bonjour,

J'ai une problematique de passage de données entre 2 jobs. Ces jobs travailleront toute la journée et seront chacun en Wait sur une dataqueue (1 seconde), l'arrivée d'un declencheur dans la dataqueue reveille le job B.

Le job A traite une zone de 1024 caractères et renseigne une DS tableau qualified de bonne taille, a 2 dimensions dont la 2eme dimension contient plusieurs tableaux. Le job B doit recuperer cette structure ASAP, lui appliquer un traitement...

Ma premiere idée est l'ecriture de cette DS dans la DataQueue du job B, qui servirait ainsi a passer les parametres et a declencher job B mais je ne suis pas convaincu par la performance qui y serait lié, or mon critère principal est la rapidité de passage des données du job A vers job B...

Quelle solution envisageriez-vous ? merci. (V5R2M0)

Hermelin

[Mercure]

La gestion par pointeurs et user space étant très rapide, pour éviter d'avoir à passer la DS dans la data queue, je procéderais comme suit :

Job A

• Définir la DS occursée ou dimensionnée, qualifiée et basée sur un pointeur (/COPY).
• Calcul estimé de la taille de la DS alimentée
• Allocation taille au pointeur de la DS
• Création du user space avec API QUSCRTUS
• Adressage du user space avec le MEME pointeur que la DS avec l'API QUSPTRUS. La DS va donc etre "plaquée" sur le usrspc et occuper du coup le même espace mémoire que le usrspc
• Alimentation de la DS et augmentation taille si besoin
• Passage de la taille réelle de la DS au job B via la data queue ou une data area.

Job B

• Redéfinir la DS comme dans job A par /COPY
• "Plaquer" la DS sur le usrspc
• La DS est alors à disposition dans ce job.

Un exemple extrait de l'un de mes programmes qui gère de cette façon :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

Job A

      *- - - - - - - - - - - - - - - - - - - - - - - - - - - *
      * MODS pour simplifier chargement du tableau MaDS    *
      *- - - - - - - - - - - - - - - - - - - - - - - - - - - *
     d MaDS          ds                    qualified
     d                                     occurs(10000)
     d                                     based(p_MaDS)

         // Estimation taille memoire maximale pour MODS et userspace
         dtaLen = %size(MaDS) * 100;

         // On ajuste la taille occupee par la MODS pour optimiser.
         p_MaDS = %alloc(dtaLen);

         // Delete le user space
         qusdltus(  us_name_lib   :
                     api_error );

         // Recree le user space
         quscrtus(  us_name_lib  :
                    us_attrib    :
                    dtaLen       :
                    us_init_val  :
                    us_authority :
                    us_text      :
                    us_replace   :
                    api_error );

         // Adressage du user space avec le MEME pointeur que le tableau
         // MaDS  ==> le tableau va donc etre "plaqué" sur le usrspc
         qusptrus( us_name_lib   :
                   p_MaDS      :
                   api_error );

        // Alimentation de MaDS
           ...

Code :

1
2
3
4
5
6
7
8
9
10
Job B

    d/COPY MaDS

       qusptrus( us_name_lib  :
                 p_MaDS:
                 api_error );

       // MaDS est désormais à disposition
       ...

[hermellin]

meci bcp Mercure pour avoir pris le temps de repondre et surtout documenter ta reponse. N'ayant jamais mis en oeuvre les Userspaces, j'aurais galeré sans l'exemple, je tacherais de le mettre en oeuvre dans les jours qui viennent et ferai un retour...

effectivement une zone memoire partagée me parait idéale en terme de rapidité, et l'utilisation du pointeur va m'eviter d'y copier ma DS par programmation. Tres ingénieux !

Hermelin

[Mercure]

Je te passerai le code complet si ça t'intéresse.

[hermellin]

j'ai un petit probleme pour associer un pointeur a ma DS existante, tout le prog JobA l'utilise ainsi : Eval mot(i1).fct(i2).zona ='...' sans avoir a faire ( i1 OCCUR mot) et j'aimerais garder ce fonctionnement.

Code :

1
2
3
4
5
6
7
8
9
10
11
Dmot_exp          ds
D     zona                       5
D     zonb                       2  0 inz(*zero)
 *
D mot             ds                  dim(100) Qualified based(p1)
D     vala                      30
D     valb                       3  0 inz(*zero)
D     fct                             likeds(mot_exp) dim(5)
 *
D p1                              *

Le rajout de based(p1) ne passe plus a la compil, ca donne :

RNF3724 20 1 Mot clé non admis pour une sous-zone de structure de données BASED ; mot clé non pris en compte.

j'ai remplacé dim(100) par occurs(100) c'est pareil. A vrai dire je vois pas trop le probleme ni la solution

En attendant je vais tester les API usrspc avec une DS plus simple

Hermelin

[vazymimil]

Bonjour,

Dans l'exemple tel que tu le donnes, p1 est dans la DS qui se base sur p1 !

Pour info, based(p1) declare lui-même p1 comme pointeur, on est pas obligé de le déclarer, après c'est une question de préférence.

[Mercure]

En effet, déclarer le pointeur "p1" est superflu. Supprimes la déclaration.
Alternativement, tu peux utiliser DIM() au lieu de OCCURS(). J'utilise OCCURS() car je fais un plus loin un FETCH groupé dans le programme, ce qui impose que la DS soit "occursée".

En attendant je vais tester les API usrspc avec une DS plus simple

Plus simple ou moins simple, cela n'a rien a voir. La DS va être "plaquée" sur le user space puisqu'elle va partager la même adresse qui est contenue dans le pointeur.

Voici les prototypes et les définitions des zones de travail dont tu auras besoin. Cela devrait t'aider.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
      * - - - - - - - - - - - - - - - - - *
      * Creation espace utilisateur (API) *
      * - - - - - - - - - - - - - - - - - *
     D quscrtus        pr                  extpgm( 'QUSCRTUS' )
     D  us_name_lib                  20a
     D  us_attrib                    10a   const
     D  us_size                      10i 0 const
     D  us_init_val                   1a   const
     D  us_authority                 10a   const
     D  us_text                      50a   const
     D  us_replace                   10a   const
     Db                                    like(api_error)

      * - - - - -  - - - - - - - - - - - - - - - - - - - -*
      * Affectation pointeur sur espace utilisateur (API) *
      * - - - - -  - - - - - - - - - - - - - - - - - - - -*
     D qusptrus        pr                  extpgm( 'QUSPTRUS' )
     D  us_name_lib                  20a   const
     D  us_ptr                         *
     Db                                    like(api_error)

      * - - - - - - - - - - - - - - - - - -  *
      * Prototype pour suppresion user space *
      * - - - - - - - - - - - - - - - - - -  *
     d qusdltus        pr                  extpgm('QUSDLTUS')
     d                               20a   const
     db                                    like(api_error)

      * - - - - - - - - - - - - - - - - - - - - - - - - - - *
      * Paramètres création espace utilisateur (user space) *
      * - - - - - - - - - - - - - - - - - - - - - - - - - - *
     d user_space      ds
     d  us_name_lib                  20a   inz('MONUSRSPC  MABIB')
     d  us_attrib                    10a   inz(*blanks)
     d  us_size                      10i 0
     d  us_init_val                   1a   inz( x'00' )
     d  us_authority                 10a   inz( '*CHANGE' )
     d  us_text                      50a   inz('bla bla bla ...')
     d  us_replace                   10a   inz( '*YES' )

      * - - - - - - - - - - - - - - - *
      * Zone message erreur pour APIs *
      * - - - - - - - - - - - - - - - *
     d api_error       ds
     d  err_size                     10i 0 inz( %size( api_error ))
     d  err_length                   10i 0 inz(0)
     d  err_id                        7a
     db                               1a
     d  err_data                    256a

      *- - - - - - - -*
      * Zones isolées *
      *- - - - - - - -*
     d dtaLen          s             10i 0

Pour voir le détail des APIs chez Big Blue, c'est ici.

Pour voir le contenu du user space (ça se présente comme une data area), il faut employer le format QSYS.LIB :

Code :

1
2
DSPF '/QSYS.LIB/MABIB.LIB/MONUSRSPC.SPC'

[jump400]

Envoyé par hermellin

j'ai un petit probleme pour associer un pointeur a ma DS existante, tout le prog JobA l'utilise ainsi : Eval mot(i1).fct(i2).zona ='...' sans avoir a faire ( i1 OCCUR mot) et j'aimerais garder ce fonctionnement.

Code :

Le rajout de based(p1) ne passe plus a la compil, ca donne :


j'ai remplacé dim(100) par occurs(100) c'est pareil. A vrai dire je vois pas trop le probleme ni la solution

En attendant je vais tester les API usrspc avec une DS plus simple

Hermelin

En plus du P1 qui, comme précédemment indiqué, devrait être soit en type S (Standalone) soit omis, l'initialisation de valb ne peut être faite avec inz(*zero) si la DS est Based. Ces 2 mots clés sont incompatibles.

[hermellin]

Merci pour toute ces infos Ce matin je me suis reveillé avec en tête "j'aurais pas oublié le S pour p1", véridique

Toute facon je supprime cette declaration autodéclarée, je ne savais pas.

ok je supprime le INZ(*zero), surtout que le usrspace est lui meme initialisé a X'00' lors de l'utilisation d'une de ses API (create je crois)

A ce propos, que doit on renseigner dans us_attrib ? la doc dit :

The extended attribute of the user space. For example, an object type of *FILE has an extended attribute of PF (physical file), LF (logical file), DSPF (display file), SAVF (save file), and so on.

The extended attribute must be a valid *NAME. You can enter this parameter in uppercase, lowercase, or mixed case. The API converts it to uppercase.

a priori je veux juste une zone memoire dont l'adresse est partagée, pas quelque chose d'ecrit sur disk (ralentissement)

Merci pour les prototypes

Hermelin

[Mercure]

Dans "extended attribute", tu mets des blancs comme je l'ai fait dans mon précédent post.

Envoyé par hermelin

a priori je veux juste une zone memoire dont l'adresse est partagée, pas quelque chose d'ecrit sur disk (ralentissement)

Comment veux-tu passer les données d'un job à un autre sans écrire sur le disque ? Le user space, c'est un objet sur le disque comme l'est une data area, mais tu ne le créeras qu'une seule fois. C'est en effet l'alimentation de la DS en mémoire qui va alimenter automatiquement le user space puisque DS et user space partagent la même adresse. Capice ?

Le gros avantage de cette méthode, c'est que dans le job B, tu n'as plus qu'à pointer le même pointeur sur la DS (/COPY) et le user space alors que data queue ou fichier imposeraient des "moves" pour alimenter la DS pour que le job puisse l'exploiter.

[hermellin]

J'ai fini de developper mes 2 jobs de test A et B et y'a rien dire, ca fonctionne parfaitement, B retrouve tout le tableau

Comment veux-tu passer les données d'un job à un autre sans écrire sur le disque ?

J'etais parti sur l'idée que le userspace etait prioritairement stocké en memoire primaire (RAM) et que le pointeur permettait aux differents jobs d'y acceder tres rapidement, mais a y reflechir c'est incompatible avec la nature meme de l'os/400 et son espace d'adressage unique.

Derniere question : cette méthode d'echange de données inter-process est-elle compatible avec des echanges au fil de l'eau (flux) ? La doc de l'API dit que :

you should use your own synchronization data methods. You can use one of the following methods to avoid updates at the same time to the same location within a user space:

* CMPSW MI instruction
* CMPSWP MI instruction
* LOCK MI instruction
* LOCKSL MI instruction
* Allocate Object (ALCOBJ) command

Synchroniser JobA qui ecrit le userspace, et JobB qui le lit est donc possible mais ca peut aussi apporter de grosses lenteurs dans ce flux (mauvais souvenir avec le ALCOBJ !)

Hermelin

[Mercure]

cette méthode d'echange de données inter-process est-elle compatible avec des echanges au fil de l'eau (flux) ?

Tout à fait et c'est d'ailleurs une gestion de flux que je fais dans une de mes applications. Cependant, je n'ai pas de job A, ni de job B. En effet, j'ai placé leur équivalent dans des procédures de programme de service, ce qui m'autorise une grande souplesse à l'utilisation. En outre, bien que ma DS puisse dépasser les 10 Mo, je n'ai pas rencontré de lenteurs particulières. Attention à ce que ta DS ne dépasse pas les 16 Mo, qui est la taille limite d'un user space. Il y a moyen toutefois de dépasser cette limite mais c'est un tantinet compliqué à mettre en oeuvre.

QQ points à soulever :
N'oublie pas de désallouer le ou les pointeur(s) en fin de traitement dans les deux jobs/procédures. Egalement, toute mon application tourne dans le même groupe d'activation nommé, ça ne peut qu'aider.

Conception et programmation ne deviennent-ils pas bien plus intéressants lorsqu'on découvre de nouvelles méthodes telles que les user spaces, les APIs et la gestion par pointeur, qui nous font sortir des sentiers battus ?

Le job B doit recuperer cette structure ASAP, lui appliquer un traitement...

C'est quoi ce traitement dont tu parles ?

[hermellin]

En outre, bien que ma DS puisse dépasser les 10 Mo, je n'ai pas rencontré de lenteurs particulières.

A la louche le tablo sera bien plus petit, moins de 100 ko je pense.
- Dans mon cas, le user space est alimenté par A et exploité par B, et A ne doit pas re-alimenté le userspace tant que B ne l'a pas exploité.
- dans ton cas tu aurais donc la garantie de l'execution de B après A (execution successive des procedures) ; donc pas de "bouchons" possible...
- dans mon cas je peux imaginer une zone "flag" dans le userspace mise a jour par B et indiquant a A qu'il peut a nouveau alimenter le userspace ; mais A bouclant sur ce flag ne serait sans doute pas bon en matiere de consommation CPU.
- les data queues resolvent le pb car ce sont des queues et ont cette possibilité de TIMEWAIT tres interessante bien que 1 seconde (minimum) soit un peu trop. (mais l'absence de possibilité de pointeur que tu as mis en evidence est nettement en leur defaveur)

Conception et programmation ne deviennent-ils pas bien plus intéressants lorsqu'on découvre de nouvelles méthodes telles que les user spaces, les APIs et la gestion par pointeur, qui nous font sortir des sentiers battus ?

Tout a fait quand cela va dans le sens de la performance Mais j'avoue avoir un peu de mal a digerer les nouveaux concepts. Les APIs ca va encore, les pointeurs c'est plus dur déja Mais le probleme est dans ma difficulté d'adaptation et d'acquisistion, pas dans les concepts

C'est quoi ce traitement dont tu parles ?

Le job A recoit des requetes en langage naturel, et idéalement une centaine a la seconde, il identifie, classe, et prepare le terrain pour JOB B en formattant un tableau que Job B va traiter.

Etant donné que chaque requete va necessiter un certain travail d'analyse, il doit etre dispatché entre plusieurs JOBs a des moments clefs de l'analyse, afin de garantir une certaine fluidité dans le traitement de la queue initiale des requetes. du Taylorisme quoi

En tout cas grand merci pour ton aide, ainsi que celle des autres intervenants.
Hermelin

[Mercure]

- les data queues resolvent le pb car ce sont des queues et ont cette possibilité de TIMEWAIT tres interessante...

Je ne vois pas en quoi les data queues peuvent empêcher l'alimentation de la DS si le job B n'a pas fini de l'exploiter. Ce n'est certainement pas le délai d'attente qui peut le garantir.

En revanche, si tu crains que la DS soit recouverte trop tôt, tu pourrais temporiser avec en effet un flag et la fonction (API) setitimer() qui permet de suspendre ou d'arrêter l'exécution d'un programme pendant ou au bout d'un nombre spécifié de microsecondes.

[hermellin]

Bonjour Mercure,

Envoyé par Mercure

Je ne vois pas en quoi les data queues peuvent empêcher l'alimentation de la DS si le job B n'a pas fini de l'exploiter. Ce n'est certainement pas le délai d'attente qui peut le garantir.

Je ne dis pas cela et ne comprend pas le sens de ta remarque, je dis juste que les dataqueues resolvent tout probleme de synchro entre le job qui ecrit et celui qui lit de par leur nature meme de queue, et que leur timewait est tres pratique pour mettre les jobs en attente

En revanche, si tu crains que la DS soit recouverte trop tôt,

oui c'est cela ma crainte, je vais faire des tests de performance entre 2 solutions : Userspace + api settimer VS Dataqueue

Hermelin

[Mercure]

...Je ne dis pas cela et ne comprend pas le sens de ta remarque...

En suivant ton raisonnement, je veux dire par là que d'utiliser une data queue ne garantit pas à 100 % le risque d'écrasement de la DS avec de nouvelles données.

...je vais faire des tests de performance entre 2 solutions : Userspace + api settimer VS Dataqueue

Je suis intéressé par tes résultats. Pourras-tu les publier ici ?

[hermellin]

je vais tenter un "schéma" pour expliquer mon cas

Cas 2 :
1 requete ==> JobA DS dim(100) ==> DS ......... ==> DATAQUEUE ==> JOB B
langage............ qualified................ mise............... FIFO
naturel......................................... a plat (proc)

Cas 1 :
1 requete ==> JobA DS dim(100) ==> USERSPACE ==> JOB B utilisant Ma DS
langage............ qualified................................................................based(p1)
naturel............. based(p1)

Dans le cas 2, il me semble avoir la garantie que chaque fois que ma DS est mise a plat dans la DataQueue, JOB B pourra la relire aussitot ou demain (sauf gros crash disk)

Dans le cas 1, je découvre donc peut me tromper mais si JOB A traite 100 requetes en l'absence de JOB B. Quand je lance JOB B il ne recupere alors que ma DS correspondant au 100ème traitement (?)
D'ou la necessité d'une synchro dans le cas 1

Bien sur, pas de souci pour poster les resultats de mes 2 tests, dans quelques jours

Hermelin

[Mercure]

Dans le cas 1, je découvre donc peut me tromper mais si JOB A traite 100 requetes en l'absence de JOB B. Quand je lance JOB B il ne recupere alors que ma DS correspondant au 100ème traitement (?)

Non, job B doit récupérer toute la DS (les 100 postes de ton exemple). Dans job B, souviens-toi, tu recopies la DS dimensionnée par /COPY.

D'ou la necessité d'une synchro dans le cas 1

Dans l'option "user space", job A peut passer l'occurrence à traiter au job B via une data area ou dans le user space lui-même. Job B pourrait ainsi y accéder aujourd'hui ou demain.

Maintenant, avec l'option "data queue", tu peux journaliser la data queue pour accroître la sécurité, ce que tu ne peux pas faire avec un user space, même avec la V6R1 me semble-t-il. Cependant, le user space est un objet comme un autre qui est sauvegardable. En revanche, je pense qu'en matière de perfs, la "data queue" devrait être supplantée par l'option "user space". On verra bien le résultat lors des tests de perf.

[hermellin]

Envoyé par Mercure

Non, job B doit récupérer toute la DS (les 100 postes de ton exemple). Dans job B, souviens-toi, tu recopies la DS dimensionnée par /COPY.


Dans l'option "user space", job A peut passer l'occurrence à traiter au job B via une data area ou dans le user space lui-même. Job B pourrait ainsi y accéder aujourd'hui ou demain.

Mercure, je pense savoir ou est notre incomprehension et cela est surement du a un vocabulaire imprecis de ma part je m'en excuse.
1 requete langage naturel ==> JobA formatte la totalité des 100 postes de ma DS ==> UserSpace ==> Job B

C'est 100% des occurences qui sont traitées par JobB a chaque requete Langage naturel.
Hermelin,

[Mercure]

Dans la mesure où tu es appelé à conserver plusieurs occurrences de la DS de base, effectivement il vaut mieux utiliser l'option data queue puisque tu as besoin de quelque chose qui fasse office de job queue.

On pourrait sans doute faire aussi qqchose de propre avec les user spaces mais cela risque de demander plus de travail aussi plus complexe pour aboutir à ce que tu cherches à faire.

Les data queues sont aussi plus fréquemment employées et feront moins peur que les user spaces à la future maintenance.