So does the following URL (or similar) give you access to Portal on the remote server?
- Log in to post comments
So does the following URL (or similar) give you access to Portal on the remote server?
Try port 57772.
In other words, use the same port number as you use when accessing InterSystems Management Portal.
Yes, that's what I mean.
Well, the %Z* names were safe from overwrite by InterSystems, until they came out with the %ZEN package ![]()
Thanks Nicole. I'll watch out for it.
A CACHE.DAT database file can be mounted, read and modified by any instance of Caché, including one running "locally", by which I assume you mean "on your workstation".
Congratulations to the Atelier team for releasing 1.1. However I'm still disappointed that suggestions #2 and #3 which I made more than 18 months ago haven't (yet) been taken up. IMO they'd significantly improve the usability of part of the Atelier Explorer (AE).
In which case, please mark one of the Answers as "accepted". This helps the Developer Community spot questions that haven't yet been answered to the satisfaction of the OP.
I don't know of any publicly-accessible InterSystems servers you could point your Atelier at. You probably need to set up your own. It must be version 2016.2 or later.
I also have a hunch that if your webserver is prepared to serve HTTP then it may be sufficient to make some server-side settings in Portal on your Caché / Ensemble server, as follows.
The settings are WebServerName, WebServerPort, and WebServerURLPrefix. These can be found in the Startup Settings ([System Administration] > [Configuration] > [Additional Settings] > [Startup Settings])
Doing this may mean you don't need to get each Studio user to change their settings. But it seems possible the server-side settings won't be able to make Studios use HTTPS for templates and add-ins rather than HTTP.
For the record, I checked back through the old Studio versions I have access to. This setting first appeared in 2009.1.
Each Cache instance on your PC can run its Telnet service on a different port. Set it here:

It shouldn't matter to you. I suggest you just ignore results that begin with "^"
As noted by Keith Avery in his comment, the ListAll classmethod of %SYS.Namespace may also include implicit namespaces. This is mentioned in the class doc. I haven't verified, but I guess that you may get different results from ListAll() if you run it once immediately after Cache startup and again after Portal has been used to change namespace definitions (e.g. mappings).
ListAll() is implemented using calls to the undocumented $ZUTIL(90) function. I dug up some WRC information we received in 2010 about a change in behaviour in that function starting with Caché 2010.2. The summary was:
SML1081 - Support single namespace activation and reduce usage of mapping memory.
What is your Caché version?
w $zv
I strongly recommend you contact InterSystems Support (a.k.a. WRC) for assistance. See https://www.intersystems.com/support-learning/support/ for details.
Maybe this post will help you:
https://community.intersystems.com/post/configuring-cach%C3%A9-client-a…
Per Michelle's answer, moving up to the 1.1 beta may be worthwhile for you. See http://docs.intersystems.com/documentation/atelier/UpdateNotes-1.1.html for what it currently includes, plus instructions on how to get it.
There are two versions of Atelier currently available. Are you using 1.0 or the 1.1 Beta?
Is anything being logged in cconsole.log ? Perhaps your audit database has run out of space?
Here's a quick way to get to the log from Portal:
Kumaresan, I have removed the "Developer Community FAQ" tag which is intended for use on posts about the DC software itself. I have added the "SQL" and "Performance" tags.
Is this a Caché Online Backup? If so, and if the system is active while the backup runs, multiple passes have to be done in order to capture a single-point-in-time record of the database. This means that some of the blocks of the database appear multiple times in the backup file.
Looking at the logfile produced by the backup should give you more information.
Using the extra info from Dinesh, here's what I did to investigate. Admittedly I was on a 2015.1.0 Ensemble on Windows, but the classes are unlikely to have many differences between this and his 2015.1.2 on Solaris.
First I cleared the read-only flag on the CACHELIB database that stores %Net.HttpRequest:

Then I loaded the class into Studio (for safety I set the read-only checkbox during opening), compiled it, used the View\View Other Code option (Ctrl+Shift+V) and jumped to the line of the error Dinesh reported.
I reset the "Always Mount Read-Only" checkbox on CACHELIB, to prevent accidental changes.
In the code several things caught my eye:
Maybe disable the GZIP feature on your SOAP adapters and see if the problem persists. Searching the InterSystems doc for the term GZIPOUTPUT may give you clues (I'm no expert in this area).
I also recommend you ask InterSystems Support (WRC) for help on this, particularly as you're running on a less common platform (Solaris).
What Ensemble version(s)? And what NLS Locales? On more recent Ensembles you can get both these pieces of information via the About link at the top left of Portal:

Thanks Dave. For the benefit of DC readers, here's what the "big red warning" looks like:

Thanks Mark. I'm going to accept Dave's answer, but I appreciate your prompt response too.
You might have been able to monitor progress by running the JOBEXAM utility from another session connected to the %SYS namespace.
That's interesting Jeff. I wonder if you were on the "Developer Community FAQ" page of DC when you clicked the "Create New Post" button? If so, it looks like that'd pre-populate the tag field in the way you reported. @Evgeny Shvarov, maybe this case could be treated as an special case by the DC software, stopping it from proposing the "Developer Community FAQ" tag.