Page 1 sur 1

Controle de validation avec QZDASOINIT

Posté : ven. 04 nov. 2011, 09:53:15
par gb1963
Bonjour,
Nous rencontrons des problèmes avec des job QZDASONIT généré par des connexions ODBC au travers d'un web service.
Le web service lance une procédure stockée qui elle même fait appel à un CL qui exécute un programme RPG.
A la fin du traitement le job reste actif, les fichiers en mise à jour restent tenus bien que le commit ou le rollback soit effectué dans le programme RPG.
Auparavent ce même programme RPG était appelé directement depuis la procédure stockée et ne posait pas de soucis de validation.
Pour résoudre cette situation, nous avons ajouté les commandes ENDCMTCTL et STRCMTCTL dans le CL avant l'appel du pgm RPG.
Est ce la bonne solution ?
D'avance merci.

(sans texte)

Posté : ven. 04 nov. 2011, 10:35:55
par EL MANSSOURI
QZDASOINIT sont des travaux à démarrage anticipé du sous-système QUSRWRK, ils répendent au requettes SQL (JDBC, ODBC), leur nombre vari selon le paramétrage.
Un programme RPG qui déclare des fichiers en contrôle de validation doit forcément être lancé dans un environnement de contrôle de validation
STRCMTCTL et les fichiers en question doivent être journalisés.
Si vous avez un plantage de votre RPG, la solution que vous proposez est la bonne (vérifiez la JOBLOG du travail pour des messages d'erreur)

(sans texte)

Posté : ven. 04 nov. 2011, 11:44:36
par gb1963
Merci de votre aide
Je suis d'accord avec votre réponse.
Je n'ai peut être pas été assez clair, il n'y a pas de plantage dans le RPG mais c'est comme-ci le COMMIT ou ROLLBACK était inexistant.
Le Job reste actif avec les fichiers ouverts et enregistrements mis à jour ou créés tenus ce qui bloque d'autres traitements (enregistrement en cours d'utilisation)
Le pgm RPG se termine bien par LR et la commande RCLRSC est en fin de CL
Comment se fait'il que les fichiers restent ouverts et que le job QZDASOINIT reste visible dans le sous-sytème ?
Nous rencontrons le même problème lorsque nous n'utilisons pas de COMMIT.
J'ai l'impression que ce problème se produit lorque les procédures stockées font appel à des CL.

QZDASOINIT

Posté : lun. 07 nov. 2011, 08:43:52
par cmasse
Bonjour,

lors de la connexion du web service à la procédure cataloguée il y a des paramètres indiquant le niveau d'isolation (*NONE, *CHG, *CS, etc...) qui définissent le niveau de commitment control actif. quels sont-ils ?


d'autre part, le RPG met à jour des fichiers, en mode natif ou en SQL ?
(si c'est en mode SQL, c'est lors de la compilation qu'il faut renseigner le paramètre COMMIT)


enfin, il est "normal" qu'un JOB QZDASOINIT reste actif, il est recyclé et réutilisé 200 fois, voir
http://www.volubis.fr/news/liens/coursh ... OINIT.HTML

(sans texte)

Posté : mar. 08 nov. 2011, 11:36:26
par brahim1966
Bonjour
Nous avions ce probleme, pour ma part je l'ai résolu en utilisant l'option de ménage de l'as/400.
qui est : Go cleanup (menu ménage)
avec l'option 1 on planifié un ménage quoditien à une heure donnée

il faut bien sûr démarrer le sous systeme : QSYSSCD

voilà en ésperant avoir répondu à tes attentes
@+
Brahim