Hi,

I've asked the Cody people about this, and they replied:

Cody can only recognize files that are directly in the repository. So files outside the repository won’t be fetched as context. The InterSystem ObjectScript extension does not seem to put the documents in the repository, but in its own local storage.  

However, I'm surprised that Cody can’t at least see the contents of the current edit window or retrieve currently selected text. Surely it doesn’t pull data from a file system for those? Cody must call a VS Code API, which you would assume would know how to return the current text regardless of where the original is stored.

Maybe InterSystems have not configured FileSystemProvider correctly to allow for other extensions to request document info? I'm well out of my skill set here. Just guessing.

Whatever, I can see that the Cody supplier is going to assume it's InterSystems fault, and InterSystems will point back at them.  So I'm back to copy and paste in and out of Claude.  :-)

Mike

Just to tidy this one up, we eventually were told that the other end was supplying HL7 v2 messages, so the input became a single string with a v2 message in it.

And it's still not finished. We eventually found out the source could actually do soap calls direct, before converting to HL7, so it might even end up as we define a simple class with some properties and they pull in the WSDL to use it. That's development for you.  :-)

Hi,

After many years of development and support I've become wary of one-line requests. 🤔 I wonder why you need this (Five whys - Wikipedia). For example, if you are trying to debug a mysterious state in a background job then maybe you just need "D LOG^%ETN" to store the variables in the error log. Or, at least you could look in there for ways to use $ORDER and $QUERY  to scan local variables without involving ^SPOOL (or, as we once did, opening a file to ZW to, closing, and then reading it back).