QZDASOINIT, travail à démarrage anticipé
QZDASOINIT est un job de type serveur, démarré par STRHOSTSVR *DATABASE et répondant aux requêtes SQL entrantes (ODBC/JDBC))
Voyez la liste des travaux de type serveur ici http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzaku/rzakuservertable.htm
Pour gagner du temps lors de la connexion, des travaux sont démarrés à l'avance, sur le principe du travail à démarrage anticipé.
» Fonctionnement d'un travail à démarrage anticipé :
| 
Sous-Systèmes TRAVAUX A DEMARRAGE ANTICIPE. (ADDPJE)
-------------
-Fonctionnent avec les entrées Télécom. (ADDCMNE ou services IP)
Permettent d'initialiser un travail sur le système cible (IBM i) avant l'activation
du programme demandé par le système source (le client ou le serveur d'applications).
Ce travail doit se trouver DANS LE MEME SOUS-SYSTEME que l'entrée télécom
pour l'unité APPC concernée, quand ADDCMNE sous SNA.
-Quand le système reçoit une demande de connexion réseau, il regarde
s'il existe une entrée anticipée pour un pgm de MEME NOM que celui demandé
1/ si oui il utilise ce job
2/ si non un nouveau job est initialisé de manière traditionnelle.
-L'intérêt est que ce travail peut préparer un maximum de choses avant la
demande d'activation (ouverture de fichiers B de D, initialisations, ...)
|
|
Ce travail va s'exécuter sous un profil donné jusqu'à la connexion.
A partir de cette demande, le profil de référence va devenir celui de la
liaison télécom (voir dans la JOBLOG, le profil en cours), par défaut
celui de l'entrée ADDCMNE si SNA.
Cas de QZDASOINIT (serveur Database)
Complément d'informations sur message
ID message . . . . . . : CPIAD02
Date d'envoi . . . . . : 23/05/08 Heure d'envoi . . . . : 06:20:00
Message . . . . : User FORMATION1 from client 10.3.1.1 connected to
server.
Cause . . . . . : User profile FORMATION1 from client 10.3.1.1 is
currently connected to this server job. The client name is either a TCP/IP
remote system name, a dotted decimal IP address, or the local host name
|
|
Ajouter poste trav anticipés (ADDPJE)
Indiquez vos choix, puis appuyez sur ENTREE.
Description de sous-système . . SBSD ##########
Bibliothèque . . . . . . . . . *LIBL
Programme . . . . . . . . . . . PGM ##########
Bibliothèque . . . . . . . . . *LIBL
Profil utilisateur . . . . . . . USER QUSER
Démarrer les travaux . . . . . . STRJOBS *YES (1)
Nombre initial de travaux . . . INLJOBS 3 (2)
Seuil . . . . . . . . . . . . . THRESHOLD 2 (3)
Nombre additionnel de travaux . ADLJOBS 2 (4)
Nombre maximal de travaux . . . MAXJOBS *NOMAX (5)
F10
Travail . . . . . . . . . . . . JOB *PGM
Description de travail . . . . . JOBD *USRPRF
Nombre maximal d'utilisations . MAXUSE 200 (6)
Attente de travail . . . . . . . WAIT *YES (7)
Identificateur du pool . . . . . POOLID 1
Classe: CLS |
|
1/ les travaux doivent-ils démarrer en même temps que le sous-système ?
Il est possible de démarrer un travail à tout moment avec la commande
STRPJ et de forcer l'arrêt par ENDPJ.
Arrêter travaux anticipés (ENDPJ)
Indiquez vos choix, puis appuyez sur ENTREE.
Sous-système . . . . . . . . . . SBS QUSRWRK
Programme . . . . . . . . . . . PGM QZDASOINIT
Biblio . . . . . . . . . . . . *LIBL
Type d'arrêt . . . . . . . . . . OPTION *CNTRLD
2/ si oui en (1), nombre de travaux à démarrer initialement
3/ seuil mini, qui va enclencher le démarrage de (4)
4/ nombre de travaux à démarrer à l'avance, quand le seuil est atteint.
|
|
5/ nombre maximum de travaux actifs en même temps.
6/ un travail anticipé en attente d'un besoin passe à l'état PSRW
(vous ne les verrez sur le WRKACTJOB que si vous faites F14)
lors d'une demande entrante il devient actif, la connexion est notée
dans la LOG (CPIAD02, comme vu plus haut)
lors de la demande de déconnexion :
-soit le job repasse à l'état PSRW
(il est complément ré-initialisé, la JOBLOG est mise à blanc)
-soit le nombre de fois où il a été "recyclé" est atteint et il s'arrête
(c'est ce paramètre qui fixe le nombre de ré-utilisation possibles)
7/ si le nombre de jobs pouvant être actifs est atteint (MAXJOBS en 5/)
que se passe-t-il pour les demandes entrantes
*YES elles attendent qu'un job se libère
*NO la demande est rejetée
|
|
Vous pouvez avoir des statistiques d'utilisation par DSPACTPJ
----------------------------------------------------------------------------
Travaux anticipés actifs AS400
Sous-système . . . . : QUSRWRK Date de réinit . . . : 17/11/10
Programme . . . . . : QZDASOINIT Heure de réinit . . : 16:29:24
Bibliothèque . . . : QSYS Intervalle . . . . . : 0001:19:57
Travaux anticipés :
Nombre en cours . . . . . . . . . . . . . . . : 3
Moyenne . . . . . . . . . . . . . . . . . . . : 21,7
Maximum . . . . . . . . . . . . . . . . . . . : 52
Travaux anticipés en cours d'utilisation :
Nombre en cours . . . . . . . . . . . . . . . : 1
Moyenne . . . . . . . . . . . . . . . . . . . : 1,6
Maximum . . . . . . . . . . . . . . . . . . . : 50
A suivre...
F3=Exit F5=Réafficher F12=Annuler F13=Réinitialiser
|
|
Vous pouvez réinitialiser les stats par F13 (un peu comme WRKACTJOB)
----------------------------------------------------------------------------
(écran suivant) Travaux anticipés actifs AS400
Sous-système . . . . : QUSRWRK Date de réinit . . . : 17/11/10
Programme . . . . . : QZDASOINIT Heure de réinit . . : 16:29:24
Bibliothèque . . . : QSYS Intervalle . . . . . : 0001:19:57
Demandes de démarrage de programmes :
Nombre en cours d'attente . . . . . . . . . . : 0
Moyenne en attente . . . . . . . . . . . . . . : 0,0
Maximum en attente . . . . . . . . . . . . . . : 0
Temps d'attente moyen . . . . . . . . . . . . : 00:00:00,0
Nombre accepté . . . . . . . . . . . . . . . . : 5
Nombre refusé . . . . . . . . . . . . . . . . : 0
ici, vous avez des infos sur les éventuelles attentes et refus en fonction
des paramètre MAXJOBS et WAIT.
|
Cycle de vie d'un job QZDASOINIT
- Lors d'un démarrage anticipé le job doit passer à l'état PSRW (on ne les voit qu'avec F14 sur le WRKACTJOB)
- à la connexion il passe à l'état RUN, puis exécute la première requête
- entre deux requêtes, il est à l'état DEQW, puis repasse RUN à la requête suivante, etc...
- Lors d'une demande de déconnexion :
- si le nombre d'utilisations (200 par défaut pour QZDASOINIT) est atteint il se termine
- sinon, il repasse à l'état PSRW (on ne le voit plus sur WRKACTJOB), en attente d'un prochain besoin.
- En cas d'inactivité longue du client (fin du pgm sans demande de déconnexion, par exemple)
le serveur envoi une demande réponse et démarre un "timer" ( TIMW )
Cette situation n'est pas normale,
sans doute une déconnexion oubliée par le développeur ou un bug du connecteur
(.NET de client access 5.3 avait un tel bug).
s'il ne reçoit pas de réponse au bout du temps prévu par le timer (dépend du paramètre TCP/IP TCPKEEPALV, + 3 minutes), il se termine.
» Pour travailler dans un Pool mémoire ou un sous-système dédié :
facultatif, allouez de la mémoire à un Pool partageable :
CHGSHRPOOL
*SHRPOOLn
SIZE(xxx)
créez un sous système utilisant ce pool ou *BASE:
CRTSBSD MONSBS POOLS((1 *SHRPOOLn)) TEXT('Sous système
dédié')
puis
ADDRTGE MONSBS SEQNBR(10) CMPVAL(*ANY) PGM(QCMD)
CLS(QBATCH)
- créez et ajoutez
un JOBQ (ADDJOBQE) , si vous
faites des tests en BATCH
- ajoutez une
entrée WorkStation (ADDWSE), si vous pensez travaillez
en 5250
- Pour ODBC/JDBC (dont Iseries
navigator), suivez la
procédure suivante :
- Ajoutez un travail
à démarrage anticipé
à votre sous système, par :
ADDPJE
SBSD(MONSBS) PGM(QSYS/QZDASOINIT) INLJOBS(?) JOBD(Qgpl/QDFTSVR) CLS(QSYS/QPWFSERVER)
- modifiez
les propriétés du serveur Database via Iseries
Navigator
- allez sur l'onglet sous
système
- Le bouton Ajout, permet
d'indiquer votre sous système
pour un ou plusieurs clients (adresse IP)
- Depuis SF99701 level 34 (7.1) ou SF99702 level 5 (7.2), vous pouvez aussi opérer par utilisateur
Il vous faut toujours un sous système configuré proprement et actif (comme vu ci-dessus)
Appellez ensuite la procédure stockée SET_SERVER_SBS_ROUTING
- Indiquez le profil
- le Job serveur
- QRWTSRVR (DRDA/DDM)
- QZDASOINIT (ODBC/JDBC))
- le sous système actif
- Select * from SERVER_SBS_ROUTING permet de voir les utilisateurs re-routés
- De fait, suite à une connexion avec le gestionnaire de scripts de System i Navigator
- S'il n'y a pas de sous système actif, l'utilisateur ira "normalement" dans QUSRWRK
- Pour enlever cette configuration, appelez la même procédure en passant la valeur nulle
» Pour tester les performances DB2 :
Enfin, pour tester tout cela (et faire des tests de montée en charge), voyez le projet Apache Jmeter
Dézippez et lancez jmeter.bat
Ajoutez un groupe d'unité (de thread)
Indiquez un nombre d'utilisateurs, un objectif de durée (peut ne pas être respecté suivant la puissance votre poste) et un nombre de boucles
Ensuite, ajoutez dans Configurations une Configuration de connexion JDBC
indiquez :
- un nom de liaison à utiliser lors des requêtes
- une requête SQL de la validation de la connexion (values 1, retourne 1 bêtement, et est très rapide d'exécution)
- L'url d'accès : jdbc:as400://VOTRE-AS400
- les coordonnées de la classe JDBC : com.ibm.as400.access.AS400JDBCDriver
- un identifiant et mot de passe de connexion
Il faut ensuite retourner sur le plan de test et ajouter le chemin de jt400.jar au CLASSPATH de Jmeter.
Téléchargez le, s'il faut depuis http://jt400.sourceforge.net/
Ajoutez ensuite une ou plusieurs requêtes SQL (Ajouter/Échantillons/requête JDBC)
Remarquez le nom de liaison, correspondant à l'ID donné lors de la configuration de la connexion JDBC
Ajoutez enfin un récepteur pour voir les résultats de type Graphique de résultat ou Tableau de résultats (c'est le cas ci-dessous) puis lancez (Ctrl + R)
Les requêtes s'exécutent, voyons le résultat du coté IBM i, par DSPACTPJ QUSRWRK QZDASOINIT :
Pour plus de détails sur le réglage, voyez : http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/experience_web/tuneprestart.pdf
Certaines requêtes utilisent un autre serveur : QSQSRVR
- Les applications utilisant CLI avec SQL_ATTR_SERVER_MODE
- Les accès JDBC natifs, dont :
WAS
IBM Directory Server
Gestion centralisée
- Les accès PHP utilisant le connecteur DB2_connect()
L'application se connecte alors à un travail de type serveur
- Ces travaux sont aussi des travaux à démarrage anticipés liés à QSYSWRK.
Par défaut, le système n'en démarre que 5.
Les PTF SI33949 (V6) et SI33298 (V5R40), ainsi que la version 7, proposent
une variable d'environnement QIBM_SRVRMODE_SBS qui fixé à '*SAME'
demande à ce que le travail QSQSRVR soit démarré dans le même sous-système
que le travail « client »
Ex : ADDENVVAR ENVVAR(QIBM_SRVRMODE_SBS) VALUE('*SAME') LEVEL(*SYS)
Si le sous-système ne possède pas de poste de travail à démarrage anticipé pour QSQSRVR, un travail QSQSRVR est démarré de type BCI et arrêté en fin de traitement
si le sous-système possède un travail à démarrage anticipé pour QSQSRVR
(défini par ADDPJE PGM(QSYS/QSQSRVR) c'est ce dernier qui est (ré) utilisé.
NB : QIBM_SRVMODE_SBS n'est pas utilisée par QHTTPSVR et ZENDSVR
Les travaux database :
- QDBSRVXR Gére les références du catalogue principalement QADBXREF sauf des zones qui sont dans QADBIFLD
- QDBSRVXR2 C'est lui qui gére les références de zones dans QADBIFLD
- QDBSRV01 C'est le répartiteur de taches de maintenance DB, ils aiguille vers les autres jobs de maintenance
- QDBSRV02, QDBSRV03 C'est la maintenance des chemins d'accès sur les fichiers systèmes
- QDBSRV04, QDBSRV05 Ces Jobs font la maintenance des chemins d'accès sur les fichiers base de données utilisateur
Par processeurs supplémentaires
- QDBSRV06-QDBSRV07
- QDBSRV08-QDBSRV09
Etc ... ils agissent comme QDBSRV04, QDBSRV05
Copyright © 2023 VOLUBIS