John Murray · Nov 21, 2016 go to post

An interesting article, but I'm puzzled by your use of the term "I11n". I'm familiar with "I18n" as an abbreviation for Internationalization (because there are 18 letters between the "I" and the "n". Likewise, I understand "L10n" as standing for Localization. Some Googling suggests that "I11n" is short for Introspection. Or have I missed something?

John Murray · Nov 22, 2016 go to post

I think you stand a better chance of getting responses to this if you move it to the HealthShare group and tag it with a HealthShare-related tag. The "Developer Community" tag and the "Developer Community Feedback" group are intended for posts/questions about the DC forum itself, not the InterSystems products. Posts tagged/classified like that don't appear on people's general new feed, AFAIK.

John Murray · Dec 1, 2016 go to post

Excellent! Congratulations to the team.

Incidentally, there are already some Eclipse updates available for the standalone version. Here's what "Check for Updates" offered me when I ran it right after install (having first uninstalled the beta and deleted its directory):

And when I went ahead with these updates I got the following security warning about a couple of InterSystems components:

John Murray · Dec 6, 2016 go to post

Manoj, I respectfully suggest that your response isn't an answer to Sansa's question, but instead it is a comment on the question. I encourage you to use the "comment" link below a question in future in this kind of situation.

Also, our question here seems to be the same as Sansa's. Are you and Sansa perhaps working on the same project? If yes, coordinating your efforts to post a single question could be useful. In some cases you may even discover your own answer as you discuss the problem, saving you the trouble of posting a question here. In that case you might still choose to post an article sharing a tip with the community.

John Murray · Dec 7, 2016 go to post

Is it just me, or does the screenshot in Tim's post seem unconnected with his text? The one I'm seeing is of the Available Updates dialog of Atelier.

John Murray · Dec 13, 2016 go to post

It looks to me like DC is integrated with ISC's SSO mechanism. SO maybe that's what's timing you out. Or perhaps if you log out from something else that uses SSO it affects your DC session? Just speculating...

John Murray · Dec 16, 2016 go to post

Also, the $ZF calls made by Studio via your source control class will operate with the server credentials that the InterSystems superserver (port 1972, typically) uses. On Windows that's the logon account of the Caché/Ensemble/HealthShare service. Whereas when you launch a Caché terminal onto you local instance from your Windows desktop, your $ZF calls will use the credentials you logged in to the Windows desktop with. Similarly on non-Windows platforms.

John Murray · Dec 19, 2016 go to post

Sorry to hear about your experience with Deltanji. I've not been able to find any sign that you contacted us at George James Software for assistance. Given the chance, we're generally helpful folk.

John Murray · Dec 19, 2016 go to post

Is the E: drive a real local drive, or is it a mapped driveletter intended to give you access to a folder shared by another machine?

John Murray · Jan 5, 2017 go to post

Thanks for the information Jamie. At the time I posted the question I don't think this level of back-compatible implementation of Studio's existing mechanism was available. I'm pleased to confirm that in the Atelier 1.0 release our existing add-ins "just work". Well done team!

John Murray · Jan 5, 2017 go to post

Thanks for doing that. The DC forum software didn't allow me to answer my own question.

John Murray · Jan 6, 2017 go to post

My page looks different:

As well as not having the extra checkboxes your screenshot shows, mine are all unchecked but I still get the notifications.

John Murray · Jan 9, 2017 go to post

I think this limitation is unfortunate. Encountering the "Service unavailable" when you're trying to evaluate Caché for the first time might discourage you from continuing.

John Murray · Jan 9, 2017 go to post

I got a couple more of these over the weekend, despite having checked and altered my settings per your other post:

John Murray · Jan 9, 2017 go to post

Aha! I have changed those two settings and I now see the extra columns of checkboxes.

John Murray · Jan 26, 2017 go to post

I think you need to focus on the input stream. What type of stream is pInput ? You can get its classname using pInput.%ClassName(1)

If it is a file stream, what wrote it? Does its file contain a BOM at the start?

You might need to open a support case with WRC. I don't work for InterSystems.

John Murray · Jan 30, 2017 go to post

Please clarify what you mean by "browse the file contents".

Are you opening c:\TEMP\SoapTree.xml in a text editor?

Maybe that editor is assuming that the file is UTF8-encoded.

Can you view it in a tool that shows you the byte values it contains?

Did you have a particular reason for choosing to write the file using an instance of %Stream.FileBinary instead of %Stream.FileCharacter?

Also, be aware that the WebMethod classmethod of %SOAP.WebBase is tagged as "Internal" and commented thus:

/// This method is used internally by Caché. You should not make direct
/// use of it within your applications. There is no guarantee made about either
/// the behavior or future operation of this property.
 

John Murray · Jan 30, 2017 go to post

I'll repeat what I wrote on the previous DC thread you opened about this issue:

I think you need to focus on the input stream. What type of stream is pInput ? You can get its classname using pInput.%ClassName(1)

If it is a file stream, what wrote it? Does its file contain a BOM at the start?

John Murray · Jan 31, 2017 go to post

What does the start of the pInput stream contain? One quick but ugly way of checking this would be to write it to a scratch global before the call to OpenStream which errors, e.g.

Set ^tMurillo=pInput.Read(255) Do pInput.Rewind()

Then afterwards run the following in Terminal:

w ^tMurillo

w $a(^tMurillo,1),!,$a(^tMurillo,2),!,$a(^tMurillo,3)

This should show us whether the creator of the stream started it with a BOM character or sequence, and also whether there is an XML header specifying an encoding.

That information is apparently important to the %XML.SAX.StreamAdapter used by %XML.SAX.Parser, which in turn is what the OpenStream method of %XML.Reader uses.

John Murray · Jan 31, 2017 go to post

There's no BOM, and the XML header claims that the content is UTF-8 encoded. But on your other post you reported that your content contains a left-single-quote character and that the SAX parser choked on a character, which I suspect was this character in Unicode form rather than UTF-8 encoded.

So, what originally wrote the pInput stream's content? Did it actually UTF-8 encode the data it wrote to the stream?

John Murray · Jan 31, 2017 go to post

Thanks for looking John. Since raising the question here I have opened a WRC ticket. The WRC agent's initial test on an Alpha platform didn't recreate the problem, so they're now going to try on an Integrity instance using the exact build I'm seeing it on.

John Murray · Feb 1, 2017 go to post

I think you could simplify your first approach a little by reverting to calling OpenStream on your reader object rather than using OpenFile:

  // 1st approach - it succeeds, so the file errorOpenFile.xml is NOT generated
  //    
  d msg.Value.Rewind()
  set fs=##class(%Stream.FileCharacter).%New()
  set fs.Filename="D:\DATABASES\OVPATH\temp\test.xml"
  set fs.TranslateTable = "UTF8"
  set tSC=fs.CopyFrom(msg.Value)
  set tSC=fs.%Save()
    
  s reader=##class(%XML.Reader).%New()

  d fs.Rewind() // might not be necessary, but won't hurt
  Set sc = reader.OpenStream(fs)

Anyhow, the fact that you don't get an error confirms my hypothesis that the original stream (msg.Value) contains Unicode data but the reader treats it as though it is UTF8-encoded.

In your code above I think you can also omit the line where you set fs.Filename and instead allow the stream to generate its own temporary file. Explicitly naming the file may be handy when debugging, but it will cause problems if more than one process runs this code concurrently.
 

John Murray · Feb 1, 2017 go to post

Good point Jon. It does appear that the site I saw this happen on could be using a custom CZF.EXE, in which case perhaps GETFILE was omitted from its source CZF.C

John Murray · Feb 1, 2017 go to post

It's now been confirmed that the relevant parsers will not be ported to OpenVMS. So it'll never be possible to roundtrip all classes in UDL from that platform.

Also worth noting that GetTextAsFile appears to pre-delete the class it's about to import before it encounters the parse error and aborts the import. So you're left without a copy of the class in your namespace. Oops!

John Murray · Feb 7, 2017 go to post

Based on my reading of 2014.1 code the Exists method in Ens.Util.FunctionSet doesn't check locks when testing for the existence of the entry.

I think the Save button from Portal leads to the SaveLookupTable method of EnsPortal.LookupSettings. That method obtains an exclusive lock on the subtree of ^Ens.LookupTable where the LUT gets stored. It then kills the entire LUT and re-files each entry one by one. Once finished it releases the lock.

All of that is protected by a TSTART / TCOMMIT but this is not sufficient to prevent another process momentarily detecting the absence of an entry that would normally exist.