, , Zones numériques étendues

Voici une petite expérience à faire sur les zones étendues

Commençons par créer un fichier PF comme ceci

A R TESTAF
A NUMERO 5
A NOM 30
A PRENOM 30

Compiler le

on lui mettre des données

par exemple par SQL

INSERT INTO GDATA/TESTA VALUES(‘AAAAA’, ‘Carlsen’, ‘Magnus’)
INSERT INTO GDATA/TESTA VALUES(‘BBBBB’, ‘Vachier-Lagrave’, ‘Maxime’)
INSERT INTO GDATA/TESTA VALUES(‘CCCCC’, ‘Firouzja’, ‘Alireza’)

Si on fait un dsppfm on voit ceci

On décide de changer le nom et de le passer en numérique

On a donc le fichier décrit comme suit

A R TESTNF
A NUMERO 5S 0
A NOM 30
A PRENOM 30

Vous le compilez

vous decider de récupérer les données

par un CPYF

CPYF FROMFILE(TESTA)
TOFILE(TESTN)
MBROPT(REPLACE) FMTOPT(NOCHK)

vous faites dsppfm du fichier testN voici le résultat

Vous faites un select * from TESTN voici le résultat

C’est étonnant non ?

Si vous faites un controle de données vous n’avez pas d’erreur

SELECT * FROM TABLE(SYSTOOLS.VALIDATE_DATA_FILE(‘GDATA’, ‘TESTN’));

Vous allez me dire pourquoi ne pas faire le nouveau fichier comme une table, allons y ?

CREATE TABLE GDATA.TESTS (
NUMERO NUMERIC(5, 0) NOT NULL DEFAULT 0 ,
NOM CHAR(30) CCSID 1147 NOT NULL DEFAULT  » ,
PRENOM CHAR(30) CCSID 1147 NOT NULL DEFAULT  » )
RCDFMT TESTS

on récupère a nouveau des données

CPYF FROMFILE(TESTA)
TOFILE(TESTN)
MBROPT(REPLACE) FMTOPT(NOCHK)

si on fait un DSPPFM voici le résultat

si on fait un select * from TESTS

conclusion

Si vous copiez des données alpha dans du numérique étendue

en DDS

Les données sont fausses dans le fichier et interpretées à l’execution SQL
attention si vous lisez en RPG les données ne sont pas chargées et il n’y a pas d’erreur !

exemple :

fTESTN if e disk
read(e) TESTN ;
if %error ;
dsply ‘ici’ ;
else ;
dsply ‘la’ ;
dsply NOM ; ;
endif ;
*inlr = *on ;

En SQL

Le données sont converties au CPYF, mais elles ne sont bonnes, on passe de ici AAAAA à 11111

faites attention si vous récupérez des données numériques étendues vous pourriez avoir des surprises

Dernière remarque

Il n’y pas de probléme avec des données packées
en DDS, RPG ou SQL erreur à la lecture
en SQL, impossible de copier les données

/par
, , , Debuguer du SQL

Vous voulez avoir des informations sur des exécutions SQL.

la meilleur méthode est de prendre la requête que vous voulez analyser et de l’exécuter dans visual explain.

Mais ce n’est pas toujours possible , dans le cas d’une chaine avec du SQL embarqué .

Si vous avez fait du SQL statique vous pouvez avoir des informations au niveau des programmes par PRTSQLINF.

Dans certain cas on n’a pas ces possibilités, le plus simple est alors de ce mettre en degug et d’exécuter votre chaine, attention ce n’est pas un mode à mettre en place en production, ca augmente considérablement les informations de log.

Vous devez démarrer le debug , le plus souvent en indiquant que vous autorisez les mises à jour sur les fichiers de production.
==>strdbg updprod(*yes)

Vous lancer ensuite votre traitement qui va générer un log avec des messages de votre optimiseur SQL, c’est des messages id CPI43xx

il vous suffit ensuite d’analyser votre log et regarder si certain vous donne des informations intéressantes.
exemple :
CPI432F index à ajouter

Pour vous aider nous avons fait cet outil DBGSQLJOB que vous retrouverez ici et qui vous facilite la démarche
https://github.com/Plberthoin/PLB/tree/master/GTOOLS

Vous soumettez votre programme comme ceci
sbmjob cmd(DBGSQLJOB cmd(call monpgm) ) job(dbgsql)

et vous obtenez un fichier dbgsql dans la bibliothèque indiquée (par défaut *curlib) qui contiendra les messages de votre optimiseur.

Vous n’avez plus qu’a les analyser ensuite par select * from DBGSQL .

limitation :
dans cet outil, nous traitons en commit(*none) les requêtes SQL, si ce n’est pas le cas chez, vous adaptez le mode.

Rappel :
80 % de votre performance SQL c’est les index , suivez les recommandations de INDEX ADVISOR.

/par
, , Utilisation d’une remote DTAQ

Une DTAQ est une solution qui permet de gérer des entrées empilées de manières asynchrone (un peu comme MQ series qui lui est en plus multi systèmes)

Pour définir une remte outq

Cette technologie se base sur DRDA, c’est la solution qui est utilisée par SQL quand vous faites un CONNECT sur une base de données distantes.

Sur le système source

Vous devez définir votre base de données par la commande WRKDBDIRE

ADDRDBDIRE RDB(‘Nom_base_de donnees’)
RMTLOCNAME(‘nom ou adresse IP’ IP) RMTAUTMTH(USRID *NOALWLOWER)

Vous devez indiquer,
l’adresse IP ou le nom IP résolu
le mode de connexion qui sera négocié à l’établissement de celle ci

Vous devez créer une datq remote

CRTDTAQ DTAQ(Nom_bib_loc/Nom Dtaq)
TYPE(DDM) RMTDTAQ(nom_bib_dis/Nom_Dtaq) RMTLOCNAME(RDB)
RDB(‘Nom_base_de donnees’)

Sur le système cible

Vous devez créer une datq locale

CRTDTAQ DTAQ(Nom_bib_dis/Nom Dtaq)
TYPE(*DDM)
MAXLEN(longueur_de_vos_données)

si vous avez choisi une solution de connexion à base de profil

Vous devez devrer l’enregistrer en créant poste authentification

ADDSVRAUTE USRPRF(*CURRENT) SERVER(NEPTUNE) USRID(PLB) PASSWORD()

Vous devez indiquer l’utilisateur local qui servira à faire la requête d’écriture.

Pour voir les postes existants, vous avez une vue SQL

SELECT *
FROM QSYS2.DRDA_AUTHENTICATION_ENTRY_INFO

le service DDM doit être démarrer

STRTCPSVR *DDM

Pour écrire dans votre DTAQ

Sur la source,

vous devez écrire des postes à la demande

Par L’API

Call QSNDDTAQ

Par la procédure SQL service, depuis le niveau 4 de la TR en 7.4

QSYS2.SEND_DATA_QUEUE()

sur la cible,

Pour écrire lire votre DTAQ

Vous devez avoir un traitement qui boucle pour traiter vos entrées

par l’API

Call QRCVDTAQ

Par la function SQL service, depuis le niveau 4 de la TR en 7.4

QSYS2.RECEIVE_DATA_QUEUE()

Conclusions


Vous pouvez mettre en place une solution de remote outq, pour repliquer des changement de mots passe par exemple !

Si vous utilisez Des DTAQ, vous aurez besoin d’une commande pour visualiser le contenu de celle ci, vous pouvez en trouver un ici c’est la commande DSPDTAQ

https://github.com/Plberthoin/PLB/tree/master/GTOOLS

/par
, , Nombre d’accès DB d’un travail

Vous voulez avoir une idée du nombre d’entrée sortie que génère un travail sur votre base de données.

pour ceci, vous pouvez par exemple utiliser la comptabilité des travaux

Pour utiliser cette fonctionnalité, vous devez la mettre en oeuvre voici comment

1 ) Créer un récepteur de journal par exemple dans qusrsys ou une de vos bibliothèques
CRTJRNRCV JRNRCV(QUSRSYS/QACGJRN)
2) Créer le journal QACGJRN
CRTJRN JRN(QSYS/QACGJRN)
JRNRCV(QUSRSYS/QACGJRN)
3) Changer la valeur système QACGLVL
CHGSYSVAL SYSVAL(QACGLVL) VALUE(‘*JOB’)

Tous les jobs démarrés à partir de ce moment seront logués

Pour analyser vous avez des postes de type JB
Le plus simple est d’utiliser un fichier model
Le fichier model qui correspond est QSYS/QAJBACG4

dupliquez le

CRTDUPOBJ OBJ(QAJBACG4)
FROMLIB(QSYS)
OBJTYPE(*FILE)
TOLIB(PLB)
NEWOBJ(WAJBACG4)

Maintenant vous pouvez le remplir en faisant un DSPJRN

DSPJRN JRN(QACGJRN)
JRNCDE((A))
ENTTYP(JB)
OUTPUT(OUTFILE) OUTFILFMT(TYPE4)
OUTFILE(PLB/WAJBACG4)

Vous alors interroger votre fichier par sql

exemple ici en ce limitant au jobs interactifs

SELECT
JAJOBH as travail,
JAUSRH as utilisateur,
JANBRH as numero,
JADBPT as acces,
JADBGT as creation,
JADBUP as mise_à_jour
FROM PLB.WAJBACG4
WHERE JATYPE = ‘I’

Remarque :
N’oubliez pas supprimer les récepteurs quand vous les avez traité
Si vous voulez arrêter la collecte
CHGSYSVAL SYSVAL(QACGLVL) VALUE(‘*NONE’)

Vous pouvez également utiliser la comptabilité des travaux pour de nombreuses autres informations, pour par exemple estimer vos volumes d’impression

/par
, , Base64 en SQL avec les nouvelles fonctions de QSYS2 !

La 7.4 TR5 (et 7.3 TR11) ont apportées de nouvelles fonctions http dans QSYS2 en remplacement de celles fournies dans SYSTOOLS (cf https://www.volubis.fr/Pausecaf/PAUSECAF88.html).

Dans le même temps, nous avons droit à un refresh des fonctions utilitaires.

Parlons donc de l’encodage/décodage base64 !

Différences entre les fonctions fournies :

Les fonctions n’ont pas le même nom pour éviter toute ambiguïté :

Dans SYSTOOLS : BASE64ENCODE et BASE64DECODE

Dans QSYS2 : BASE64_ENCODE et BASE64_DECODE

L’implémentation des nouvelles fonctions (QSYS2) est basée sur Axis (en C natif), contrairement aux fonctions historiques de SYSTOLLS en Java. L’empreinte mémoire est donc bien meilleure avec les fonctions de QSYS2.

Surtout, les paramètres diffèrent : dans la version SYSTOOLS, la taille des paramètres est très limitée, et nous sommes donc sur du VARCHAR jusqu’à 4Ko maximum encodé. Les nouvelles versions utilisent des CLOB et BLOB jusqu’à 2Go !

Usages

Données caractères

On utilise régulièrement l’encodage base64 pour transmettre une authentification par profil/mot de passe, par exemple une authentification http basic.

Les deux fonctions renvoient bien sur le même résultat :

Si vous utilisez un convertisseur en ligne, vous n’obtenez pas le même résultat :

Par exemple sur https://simplycalc.com/base64-encode.php :

La raison est simple : l’encodage base64 a pour objectif d’exprimer sous forme de caractères une donnée binaire. Le paramètre en entrée de fonctions QSYS2.BASE64_ENCODE et SYSTOOLS.BASE64ENCODE Sont donc un BLOB (Binary Large Object) ou un VARCHAR avec CCSID 65535 (signifie pas de conversion).

La chaine de caractères ‘toto’ est donc transmise ici en EBCDIC et c’est la valeur binaire correspondante qui est encodée en base64.

Pour être conforme au standard : convertissez les chaines de caractères en UTF-8 :

Pour décoder des données, on utilise SYSTOOLS.BASE64DECODE et QSYS2.BASE64_DECODE :

Le résultat affiché diffère.

La aussi c’est un effet de bord du changement de type de paramètre, ET de la configuration de ACS :

La fonction de SYSTOOLS étant en VARCHAR, elle est interprétée dans le CCSID du travail. La fonction de QSYS2 renvoyant un BLOB, il n’y a pas de conversion directe possible en caractères.

La valeur binaire renvoyée est bien la même. Si l’on teste en passant par un fichier :

Données binaires

L’objectif premier est tout de même de pouvoir travailler sur des valeurs binaires.

On utilise une image sur l’IFS en tant que donnée binaire à encoder. L’image fait 158Ko, une valeur très raisonnable.

Pour faciliter la démonstration, on travaille étape par étape avec des variables SQL.

Pour lire le fichier image en binaire :

Script de test :

Les résultats semblent concordants :

Mais :

C’est le problème de la longueur des paramètres des fonctions de SYSTOOLS !

Dans l’historique :

On a un SqlCode à 0 mais un SqlState en classe ‘01’ !

On décode notre image :

Les fichiers d’origine et le fichier encodé/décodé sont bien identiques !

Les nouvelles fonctions, au-delà de l’implémentation en C, nous apportent la possibilité d’encoder et décoder des « documents » (image, pdf …à) en base64. Très utile pour faire transiter des informations binaires dans nos web services par exemple !

Et la limite à 2Go semble raisonnable.

/par
, , 5 requêtes pour contrôler vos PTFS

On ne dira jamais assez comment à quel point SQL nous simplifie la vie .
C’est d’autant plus vrai pour la gestion des correctifs

Voici 5 requêtes à garder pour vos controles de PTFs

1) Contrôle de La TR et de la version avec QSYS2.GROUP_PTF_INF


SELECT CURRENT SERVER CONCAT ‘ est en version ‘ CONCAT PTF_GROUP_TARGET_RELEASE
CONCAT ‘ et le niveau de TR est : ‘ CONCAT PTF_GROUP_LEVEL AS NIVEAU_DE_TECHNOLOGY_REFRESH
FROM QSYS2.GROUP_PTF_INFO WHERE PTF_GROUP_DESCRIPTION = ‘TECHNOLOGY REFRESH’
AND PTF_GROUP_STATUS = ‘INSTALLED’ ORDER BY PTF_GROUP_TARGET_RELEASE DESC
FETCH FIRST 1 ROWS ONLY

2) Contrôle des cumulatives sur le microcode et L’OS avec QSYS2.PTF_INFO

with result_ptf
as(
SELECT PTF_PRODUCT_ID , Max(PTF_IDENTIFIER) as last_ptf
FROM QSYS2.PTF_INFO
WHERE (PTF_PRODUCT_ID = ‘5770999’ and substr(PTF_IDENTIFIER , 1 , 2) = ‘TL’ ) or
(PTF_PRODUCT_ID = ‘5770SS1’ and substr(PTF_IDENTIFIER , 1 , 2) = ‘TC’ ) GROUP BY PTF_PRODUCT_ID
)
select PTF_PRODUCT_ID, date(’20’ concat substr(LAST_ptf, 3, 2) concat ‘-01-01’) +
(dec(substr(Last_PTF , 4, 3)) – 1 ) days as last_date_ptf
from result_ptf
where date(’20’ concat substr(LAST_ptf, 3, 2) concat ‘-01-01’) +
(dec(substr(Last_PTF , 4, 3)) – 1 ) days < (current_date – 6 months)

3) Contrôle si groupes à télécharger, nécessite une connexion avec SYSTOOLS.GROUP_PTF_CURRENCY


select
cast(substr(PTF_GROUP_TITLE, 1, 50) as char(50)) as Nom_groupe,
PTF_GROUP_LEVEL_AVAILABLE as niveau
from systools.group_ptf_currency
where ptf_group_level_installed <> ptf_group_level_available

4) Contrôle si groupes à appliquer , nécessite un IPL avec QSYS2.GROUP_PTF_INFO

SELECT * FROM GROUP_PTF_INFO WHERE PTF_GROUP_STATUS not in
(‘INSTALLED’, ‘RELATED GROUP’, ‘NOT APPLICABLE’))

5) Contrôle du firmware , nécessite une connexion avec SYSTOOLS.FIRMWARE_CURRENCY

SELECT * FROM SYSTOOLS.FIRMWARE_CURRENCY
WHERE FW_CURRENTFIXPACK <> FW_RECOMMENDED_UPGRADE and +
FW_RECOMMENDED_UPGRADE is not null ) with data

Remarque

il en existe sans doute d’autres, la limite c’est votre imagination …

/par
, , , Consommation requête SQL

Une des problématiques quand on fait du SQL c’est d’identifier rapidement une requête qui serait trop gourmande .

Dans un poste précédent j’indiquais comment avoir ces éléments en utilisant le cache SQL, mais ca peut être long pour une première analyse !

La TR5 version 7/4, TR11 version 7/3 apporte une nouvelle fonction table (QSYS2.ACTIVE_QUERY_INFO( )) qui va nous permettre de répondre à cette problématique !

page de référence IBM

https://www.ibm.com/docs/en/i/7.4?topic=services-active-query-info-table-function

Pour l’utiliser, vous devez avoir *JOBCTL dans votre profil ou être ajouté dans la fonction USAGE QIBM_DB_SQLADM .

Exemple :


Une demande qui donne à un instant donné, les 10 requêtes les plus consommatrices de votre IBMi

SELECT QUALIFIED_JOB_NAME as travail , query_type as type_requete, File_Name as fichier , Library_name as bibliotheque,
current_runtime as temps_execution , CURRENT_TEMPORARY_STORAGE as memoire_utilisee
FROM
TABLE(QSYS2.ACTIVE_QUERY_INFO())
where current_runtime is not null
ORDER BY current_runtime desc
fetch first 10 row only

Vous pourrez alors agir en ayant le nom du travail , et utiliser la vue ACS prévue à cet effet par exemple !

On indique le premier fichier spécifié dans la requête (vue ou table), attention QSQPTABL indique que c’est une fonction table .

/par
, , Liste de jobqs utilisées sur votre ibmi

Vous avez sans doute un grand nombre de jobqs sur votre système, mais savez vous réellement celles qui servent ?

Pour connaitre les liste des jobq utilisées, on va consulter les messages CPF11224 qui indiquent le début d’un travail et qui contiennent dans les données la jobq par lequel ils sont arrivés

j’ai utilisé dans mon exemple de table dans qtemp, vous pouvez un un with si vous préférez

Liste des jobqs utilisées

create table qtemp/lstjobqus as(
select distinct
cast(substr(message_tokens, 59, 10) as char(10)) as jobq,
cast(substr(message_tokens, 69, 10) as char(10)) as jobq_lib
FROM TABLE(qsys2.history_log_info(START_TIME => CURRENT TIMESTAMP –
30 days , END_TIME => CURRENT TIMESTAMP)) x
where message_id = ‘CPF1124’ ) with data

Liste des jobqs présentes sur le système

create table qtemp/lstjobq as (
SELECT OBJNAME as jobq, OBJLIB as jobq_lib
FROM TABLE(QSYS2.OBJECT_STATISTICS(‘ALL’, ‘JOBQ’)) ) with data

Liste des jobqs non utilisées

select a.jobq, a.jobq_lib from lstjobq as a exception join
lstjobqus as b on
a.jobq= b.jobq and a.jobq_lib = b.jobq_lib

remarque :

Avec cette liste vous pouvez faire du ménage et ne plus démarrer les sous systèmes inutiles par exemple.

/par
, , Comment suivre son plan de production quotidien ?

Supposons que vous utilisiez le job scheduler de l’IBMi, (WRKJOBSCDE), si vous utilisez AJS seul le fichier de départ change mais la démarche reste la même.

Notre méthode ne marche que pour le jour courrant
on va utiliser la date de prochaine soumission égale à la date du jour dans notre fichier CHEDULED_JOB qui contient les jobs planifiés .

Vous devez planifier un job tous les matins à 0h et 2 minutes dans la file d’attente QCTL pour être sur de le faire passer

ce job aura une requête de ce type qui créera une table plandujour

create table plandujour as (
Select SCHEDULED_JOB_NAME, SCHEDULED_TIME,
ifnull(DESCRIPTION,  »  ») as description
from QSYS2.SCHEDULED_JOB_INFO
where NEXT_SUBMISSION_DATE = current date and
substr(SCHEDULED_JOB_NAME, 1, 1) <>  »Q »
and status <>  »HELD »
order by SCHEDULED_TIME ) with data +

Vous avez ainsi tous les jobs prévus pour la journée par heure de planification

maintenant nous allons voir comment suivre le déroulement des ces travaux

Pour suivre vos travaux on va utiliser la fonction table suivante HISTORY_LOG_INFO

exemple pour avoir les jobs du jour

SELECT * FROM TABLE(QSYS2.HISTORY_LOG_INFO(CURRENT DATE)) X

Chaque job qui tourne sur le système va générer au moins 2 messages

un CPF1124 Travail …/…/… démarré le
un CPF1164 Travail …/…/… arrêté le

donc
si votre travail n’a pas tourné vous n’avez aucun message
si votre travail tourne vous avez un CPF1124
si votre travail est terminé vous avez un CPF1164

Vous pouvez déjà suivre l’avancement grace à la zone MESSAGE_TIMESTAMP et avoir une durée entre les 2 messages

Remarque :

pour savoir si votre travail c’est terminé normalement c’est un peu plus compliqué, vous devrez analyser le code fin par exemple dans la zone MESSAGE_TEXT.

code fin 0 indiquant une fin normale du traitement

Un exemple de requête (à améliorer)

pour les codes fin , pour les jobs qui débordent de la journée etc…

WITH logdujour (mgr_id, mgr_name, mgr_dept) AS(
SELECT * FROM TABLE(QSYS2.HISTORY_LOG_INFO(CURRENT DATE)) X)
select
a.SCHEDULED_JOB_NAME as nom_travail,
a.SCHEDULED_TIME as
HEURE_prev ,
ifnull(b.MESSAGE_TIMESTAMP,  »1911-11-11-00.00.00.00000 ») as Heure_debut ,
ifnull(c.MESSAGE_TIMESTAMP,  »1911-11-11-00.00.00.00000 ») as heure_fin,
ifnull(c.SEVERITY, »99 ») as code_sev ,
ifnull(b.FROM_JOB,  »  ») as name_JOB
from plandujour a
Left outer join logdujour b
on B.MESSAGE_ID = »CPF1124 » and B.FROM_JOB like( »% » concat
A.SCHEDULED_JOB_NAME concat  »% »)
Left outer join logdujour c
on C.MESSAGE_ID = »CPF1164 » and C.FROM_JOB like( »% » concat
A.SCHEDULED_JOB_NAME concat  »% »)

Vous pouvez planifier un job chaque soir qui vous envoie un récapitulatif de la journée ,

ou que les jobs en erreur par exemple

Vous pouvez historiser ces données si vous avez besoin de consolider un suivi, etc …

Exemple d’un outil packagé utilisé dans notre centre de service pour suivre le planning quotidien:

https://github.com/Plberthoin/PLB/tree/master/DSPPLNPRD

/par