bonjour et bonne année à tous le monde.
La fonction qsys2.Display_Journal marche dans le cas 1 mais pas dans le cas2:
CAS 1:
par exemple : STARTING_TIMESTAMP => char(curdate()- 7 days) concat '-00.00.00.000000', est OK
Sauf que si je veux mettre une variable genre :wdate àa plante
Donc j'ai essayé de mettre tous les paramètres :
CAS 2 :
select * from table( QSYS2.Display_Journal(
-- bib et journal
'$JRNLIB', 'OMSJRN',
-- bib et récepteur
'*CURCHAIN', ' ',
-- timestamp de début ou null
'2025-01-14-00.00.00.000000' ,--now() - 1 days ,
-- séquence de début ou null
CAST(null as DECIMAL(21 , 0)),
-- code journal
' ',
-- type d'entrée
' ', --'*RCD',
-- bib, objet, type, membre
'POUCOMFIC' , 'GAMDEPF', '*FILE' , 'GAMDEPF',
-- profil utilisateur
'',
-- job
' ',
-- pgm
' ' ,
-- TR4 bib et récepteur de fin
' ' , ' ',
-- TR4 timestamp de fin
' ',
-- TR4 sequence defin
' '
) ) AS X0;
Mais je me retrouve avec une erreur 802 de mappage.Donc je dois aviir une zone qui n'est pas correcte.
Je n'ai pas trouvé d'exemple sur le net MAIS uniquement avec STARTING_TIMESTAMP => char(curda..
Quelqu'un a t'il déja utilisé la cde dans un rpgle ?
Merci pour vos reponses
qsys2.Display_Journal
Re: qsys2.Display_Journal
Bonjour,
2 petites adaptations :
1/ Le paramètre STARTING_TIMESTAMP attend un timestamp SQL.
Le format : 2025-01-14 00:00:00.000000
On peut utiliser :
STARTING_TIMESTAMP => '2025-01-14 00:00:00.000000'
ou
STARTING_TIMESTAMP => timestamp'('2025-01-14 00:00:00.000000')
Dans le premier cas, la conversion est implicite par SQL
En SQL embarqué, utiliser une variable RPG timestamp de préférence. Ou CHAR formatée correctement
2/ Pour les paramètres JOB, PROGRAM etc ...
Ils sont transmis ici avec un espace : à supprimer
Conseil : ne mettre que les paramètres utiles, et les nommer. Cela évite ce genre de problème et nous facilite les mises à jour avec changement de paramètre des services SQL.
La syntaxe suivante fonctionne :
Encore mieux :
L'utilisation des noms de paramètres rend inutile les commentaires
2 petites adaptations :
1/ Le paramètre STARTING_TIMESTAMP attend un timestamp SQL.
Le format : 2025-01-14 00:00:00.000000
On peut utiliser :
STARTING_TIMESTAMP => '2025-01-14 00:00:00.000000'
ou
STARTING_TIMESTAMP => timestamp'('2025-01-14 00:00:00.000000')
Dans le premier cas, la conversion est implicite par SQL
En SQL embarqué, utiliser une variable RPG timestamp de préférence. Ou CHAR formatée correctement
2/ Pour les paramètres JOB, PROGRAM etc ...
Ils sont transmis ici avec un espace : à supprimer
Conseil : ne mettre que les paramètres utiles, et les nommer. Cela évite ce genre de problème et nous facilite les mises à jour avec changement de paramètre des services SQL.
La syntaxe suivante fonctionne :
Code : Tout sélectionner
select * from table( QSYS2.Display_Journal(
-- bib et journal
'SAMPLE', 'QSQJRN',
-- bib et récepteur
'*CURCHAIN', ' ',
-- timestamp de début ou null
'2025-01-14 00:00:00.000000' , --timestamp('2025-01-14 00.00.00.000000'),
-- séquence de début ou null
null,
-- code journal
'',
-- type d'entrée
'', --'*RCD',
-- bib, objet, type, membre
'POUCOMFIC' , 'GAMDEPF', '*FILE' , 'GAMDEPF'
) ) AS X0;
Code : Tout sélectionner
SELECT *
FROM TABLE (
QSYS2.Display_Journal(
JOURNAL_LIBRARY => 'SAMPLE',
JOURNAL_NAME => 'QSQJRN',
STARTING_RECEIVER_NAME => '*CURCHAIN',
STARTING_TIMESTAMP => '2025-01-14 00:00:00.000000', --timestamp('2025-01-14 00.00.00.000000'),
OBJECT_LIBRARY => 'POUCOMFIC',
OBJECT_NAME => 'GAMDEPF',
OBJECT_OBJTYPE => '*FILE',
OBJECT_MEMBER => 'GAMDEPF')
) AS X0;
Nathanaël