qsys2.Display_Journal

RPG (3 et 4, free), CL, SQL, etc...
Répondre
yd44
Messages : 8
Enregistré le : ven. 03 juil. 2020, 14:17:41

qsys2.Display_Journal

Message par yd44 »

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

nbonnet
Messages : 219
Enregistré le : mar. 11 sept. 2018, 08:20:13
Localisation : Lyon

Re: qsys2.Display_Journal

Message par nbonnet »

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 :

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;
Encore mieux :

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;
L'utilisation des noms de paramètres rend inutile les commentaires
Nathanaël

Répondre