Hello Matthieu,

I suspect this is an issue with the framing. You are using MLLP framing meaning each message is expected to be surrounded by ASCII 11 prefix and 28,13 suffix. In hex that's 0B prefix and 1C, 0D suffix. The error you're getting implies that the ASCII 13 is never being received. I would check to make sure the acks have the proper framing, and that the framing you are using for your operation matches what the downstream system expects, and vice versa.

I wouldn't recommend using ZU commands as they are deprecated so they are not guaranteed to always work.

Errors returned can occasionally be COS error codes, or they might boil down to OS error codes. It depends on the function; I don't know if there's a universal method that differentiates. I think you need to look at what you're calling. Often the class reference gives details on what error codes to expect.

In your particular case, referring to the %Library.File.CopyFile class reference:

"This method returns true if it succeeds and false otherwise. Pass return by reference to obtain the low level return value in case of errors which is the negative value of the operating system return code."

Hey Jonathan,

Perhaps you've already seen them, but I'd check out these posts regarding VS Code and Atelier/Studio.

https://community.intersystems.com/post/atelier-and-studio

https://community.intersystems.com/post/intersystems-joins-open-source-o...

VS Code is being worked on/developed but has not yet reached an official InterSystems 1.0 release; my bet is when it has reached a threshold of completeness it will find its way into the documentation. If you want to try out VS Code to get familiar with it and contribute to its development, that seems like a totally viable option.

Re: Atelier/Studio in the meantime, per Andreas' comment you can keep using either as they will be maintained indefinitely, they just won't see enhancements.

Yes, I am familiar with this type of <PROTECT> and I'm sure I need read access for a system database. More narrowly, I think there might be 1 or a few queries that are run by the production configuration page that require that access, so perhaps full read access might not even be necessary. I was really only setting up this user to test for Carl, as I personally rely on the standard roles that don't have these problems.

Yes, probably WRC would be the next step.

I tested on HealthShare Health Connect so I did not have the MPRL resources, but I tried making a user with R/W database permissions and just the resources you listed and was able to navigate from the SMP home page to the production page. I did get a <PROTECT> error so there's probably something still missing, but I got further than you seem to be able to.

Hey Jeff,

I wrote up a quick sample that doesn't get quite what you wanted, but I think it's close enough that you'll be able to take it from there. If not, feel free to ask further.

My sample reverses the first FT1grps and leaves the last one in the final slot.

First I used * to get the count: Counting Fields

If you wanted to implement some more complex logic you could potentially do it here. Alternatively, you might want to write a custom utility function to perform the chunking and reversal. This keeps your code more compartmentalized and keeps too much from sitting in the DTL itself.

Defining Custom Utility Functions

Hi Yone,

I just wanted to mention that zf(-1) is deprecated in modern versions in lieu of zf(-100).

Also, you might find the %Library.File methods/queries useful.

This other developer community post about purging backups contains some sample code for working with files, as well as a link to the relevant class reference:

https://community.intersystems.com/post/looking-good-routineclass-purging-cach%C3%A9-backups

Hi Oliver,

Is your intent to have multiple productions in containers trying to pull the same types of files from the same directory to split the load? It sounds like you're not able to pull from different file paths, but would setting different FileSpecs be an option?

Perhaps setting different WorkPaths would be helpful, so that the file service(s) will move the file to another directory while processing.

Another possibility would be to have one production with a file service with a pool size >1 that routes to the various other productions.