@Jean-Charles Cano,

une autre approche existe cependant : celle qui consisterait à construire une image Docker contenant ton flux FTP, et à lancer une fois par jour un conteneur de cette image pour exécuter le flux.
La commande "docker run" pouvant elle-même être exécutée via $zf(-100) depuis une tâche planifiée exécutée par IRIS à la fréquence souhaitée.

Bonjour @Jean-Charles Cano 
si ton service FTP ne doit s'exécuter qu'une seule fois par jour, à une heure bien précise, la planification est effectivement le bon moyen, en veillant à ce que l'intervalle entre appel soit supérieur à la durée séparant l'heure du START et celle du STOP.

L'autre moyen, sans planification, est de simplement mettre un intervalle entre appels de 86400 pour obtenir un appel une seule fois par jour. L'inconvénient ici étant que le service restera démarré 24h/24h sans utilité.

Bonjour @Cyril Grosjean 
le pb vient peut-être des librairies python requises qui n'ont pas été correctement installées sur l'environnement WIndows.
Tu peux essayer de le résoudre en installant les librairies python sur Windows via la commande irispip 

C:\InterSystems\IRIS\bin>irispip install --target C:\InterSystems\IRIS\mgr\python iris-pex-embedded-python

Bonjour @Pierre LaFay

pour rediriger la sortie standard du Terminal IRIS, tu peux ouvrir un fichier et l'indiquer via la commande USE 

Exemple ci-dessous et en ligne :

Class utils.file
{

Parameter DIRECTORY = "/data/";
Parameter FILENAME = "results";
Parameter EXTENSION = ".txt";
/// Redirect standard output to a file
ClassMethod results() As %Status
{
        set sc = $$$OK
        SET file=..#DIRECTORY _ ..#FILENAME _ "_" _ $tr($zdt($h,8)," :")_..#EXTENSION
        OPEN file:("NRW"):5
            USE file
            WRITE !,"BEGIN RESULTS ",$zdt($h,3),!
            do ##class(UnitTest.utils).run("Test3")
            WRITE !,"END RESULTS ",$zdt($h,3)
        CLOSE file
        WRITE !,"Results are in ",file,!
        return sc
}

}

Avec le fichier contenant toutes les écritures vers la sortie :

Merci @Pierre LaFay et @Seisuke Nakahashi pour cet article intéressant, qui apporte une autre méthode d'exploitation des rapports de performances.
Je vous invite à essayer également YASPE (Yet Another System Performance Extractor), qui génére des rapports html par une exploitation des rapports en Python.
 

Bonjour @Jean-Charles Cano,

les messages commençant par  "ConfigItem" font simplement partie des messages d'information dans le journal des événements indiquant le démarrage d'un service/process/operation dans la production (en précisant l'ID du processus de la tâche associée).
D'après tes captures d'écran, cela signifie que la connexion a échoué le 27/12 à 04:25 et que le service a correctement redémarré (message ConfigItem), le 28/12 à 14:45, ainsi que le même jour à 14:50, 16:27, etc.
Peut-être que le pb vient du paramètre  Rester connecté (StayConnected) = -1 

Le passer à une valeur positive ou à 0 règlera peut-être le pb.

@Eduard Lebedyuk précise :

L'idée d'un ensemble de résultats défilants est d'appeler Save/OpenId - et l'ensemble de résultats continuera automatiquement sur une ligne suivante. Vous n'avez donc pas besoin de gérer les indices avant/arrière :

 
Un exemple ici

C'est également environ 3 fois plus rapide puisque la requête n'est exécutée qu'une seule fois : 

do ##class(User.Pagination).Time("Save")
Save took 0,0048 sec
do ##class(User.Pagination).Time("NoSave")
NoSave took 0,0143 sec