I am no Ensemble expert, however I understood that logging what it does is part of what Ensemble does.  So I would expect it to log what it is transferring.

   You could write your own class outside of Ensemble using the %Net.FtpSession class.  Open up two connections and copy the stream you read with .Retrieve() to the stream you write with .Store().  Would this work?



   The only times I have ever seen this happen is when there was an error returned from the OS while MSM was trying to access the file.  I would recommend that you simply delete and recreate the file.  If it happens again check all the log files including the OS logs and 'msmlog' for any errors or other indications of an I/O problem.  Beyond that you should log a support call with us at '' if it is a chronic problem, and I can help you get to the bottom of it.

Thank you,


   You should get a hang if you try '$zf(-1) from Studio, or any other connection method (JOB command, Telnet, CSP, etc) where the process is not directly associated with your Windows session.  The hang occurs because, in fact, a 'cmd' session is started, but no on your desktop, you can see it in Task Manager although it is difficult to identify there.  You should be able to execute a command that does no interact with the Windows session user however, for example 'w $ZF(-1,"dir > C:\Temp\Dir.txt")' should return 0 and result in creating the listing in the specified file assuming you have  privileges to do so.

   The fact you get a -1 back from terminal (a $io="|TRM|"* process) is a bit odd, I just tested and it works for me.   Does your user have the Windows rights required to run 'cmd'?  What happens if you right-click '[Windows Start] > [Run]' and enter the command 'cmd', does that work?  You may need to contact Support to further investigate this.



   Is the file on a mapped device?  If so does the session that is issuing the '.RemoveFile()' see the mapping.  You can check this by having the session issue a command like 's X=$ZF(-1,"NET USE > C:\Temp\UseResult-"_$J_".txt")'.  Note that "Cache Terminal ($I="|TRM|*") get the logged in users mapping while JOBbed processes, those coming in via telnet, or other TCP/IP based connections get the mappings of the Cache service.  For example, from Cache Terminal ($I="|TRM|:|13248") I get:

New connections will be remembered.

Status       Local     Remote                    Network

Unavailable  H:        \\cambnfs1\nethome\clarkm Microsoft Windows Network
OK           L:        \\\Library   Microsoft Windows Network
OK           S:        \\\Scratch   Microsoft Windows Network
OK           W:        \\supnfs1\supscratch1\clarkm
                                                Microsoft Windows Network
OK           X:        \\refiles\scratch1\clarkm Microsoft Windows Network
Unavailable  Y:        \\refiles\scratch2\clarkm Microsoft Windows Network
Unavailable  Z:        \\refiles\scratch3\clarkm Microsoft Windows Network
Unavailable  LPT2:     \\\Canon MP530 Series Printer
                                                Microsoft Windows Network
The command completed successfully.

   However from a Telnet session ($I="|TNT||12936") I see:

New connections will be remembered.

There are no entries in the list.

   This is because the telnet session does not see the mappings that the logged in user has.  If you want the service to, you will need to add the mappings somewhere using a NET USE command.  In Cache you can put it in the %ZSTART routine, or you can put it in your application code.