You can use $version(1) to see if it is Windows (returns '2') or UNIX (returns '3').  If you want to get really fancy you can include %occOptions.inc and then use the $$$isUNIX and $$$isWINDOWS calls (which just check to see if $version(1) is 2 or 3).

Personally, I like using ##class(%Studio.SourceControl.ISC).RunCmd() as it wraps the capture of the output for parsing.

You can tie $version together the other answers into something that is platform independent (warning, I haven't tested this, but I believe the pieces work):

If ($version(1)=2) {

   //Is Windows

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("Ver",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

} elseif ($version(1)=3) {

   //Is UNIX

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("uname -a",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

}

Daniel,

You are absolutely correct that using Client-Side source control hooks (ie the Eclipse Git hooks with Atelier) in a Shared development instance is a recipe for disaster and frustration.  You options are moving to Private development environments (each developer gets their own Namespace, or instance, or VM or container), or move to Server-side source control hooks.

I did an in depth session on this at Global Summit 2017 which should be of interest to you.  You can watch the recording and get the slides here:

https://learning.intersystems.com/course/view.php?id=713

HTH,

Ben

Please contact InterSystems Support for assistance on this:

https://www.intersystems.com/support-learning/support/immediate-help/

Thank you,

Ben

Eduard - I think Arcady was asking from a purely data-processing perspective.  I.e. if you are already have a bunch of in-memory data and need to process/iterate on it, is it better to stick it in traditional structures and use $Order, or is it equivalent to stick it into the new structures for iterating and processing?  I think it's a good question and I would also like to hear what people think :)

If you call LOG^%ETN it will dump all of the stack into the Application Error Log which you can access via the management portal or the terminal.

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ATRYCATCHFAQ has some discussion on LOG^%ETN which may be helpful.

Ben

In the Management Portal go to:

 System > Configuration > Memory and Startup

Change the System Mode and it will put a custom banner in the header indicating Dev / Test / Live

Kumar,

It sounds like you are trying to use Atelier with client-side source control hooks against a shared development instance - is this correct?  If so, you are bound to experience frustration with this due to consistency issues.

Please review https://learning.intersystems.com/course/view.php?id=713 which discussed the 4 modes of development, which are to be avoided, and options available to you in a summary graphic from the training:

If you are going to be using Atelier with client-side hooks, I *strongly* recommend you move to giving each developer their own private instance to test against.

Kumar,

If you are using CCR then there are very specific  requirements in terms of development workflow which will provide assurances of no source loss, etc.  Please open a ticket with Support to discuss these specific concerns and considerations.

In summary, there can only be a single Disconnected BASE environments for each System, because the CCR Client Tools manage source concurrency within the Namespace, and if you have multiple BASE namespaces you have lost concurrency and therefore can lose source.  Atelier will work the same as Studio - you need a single Shared Dev Namespace using the CCR Client Tools (aka server-side source hooks) and at that point you can use either Atelier or Studio to edit the source in BASE.

IMPORTANT NOTE:  Server-side hooks will only work properly with Atelier if you are running a database version that includes CDS2924.  This is included in 2016.2.3+, 2017.1.2+ and 2017.2.0+ only.  If you are not sure if you have CDS2924 or not, please contact Support (if you use Atelier against a Shared Dev instance that doesn't have CDS2924 you don't have concurrency and therefore can lose source).

Hope that helps to get you started in the right direction :)

Geoffroy,

Welcome to Caché!  

Moving a database is really straightforward:

1. Find the database definition in your 2007.1 instance in the System Management Portal
2. Note the physical Directory where the cache.dat is located
3. Shut down Caché and make a copy of the cache.dat file located in that Directory
4. On your 2017.1 instance create a new database definition in the System Management Portal an point the Directory to the location of the copy of the cache.dat that you copied from your 2007.1 instance

Hope that helps!

Ben

See this thread which discusses several options for server-side Studio hooks for Git:

https://community.intersystems.com/post/are-there-server-side-git-studio...

NOTE - in my use-case I was looking for server-side hooks in order to allow concurrent server-based development, and I discovered that Git is very poorly suited for that purpose.  I ended up abandoning Git and using Perforce instead for my demo (Perforce is very well suited for server-side hooks with concurrent server-based development).  If you are you already operating in a single-developer / single instance setup and if you can move to one of the very latest versions of the product (2017.2.0+ or 2017.1.2+) then you should take a look at Atelier with client-side source control hooks.

For a thorough review of the different development models (private instance vs shared instance) and the different source control hook approaches (client-side vs server-side), I highly recommend that you watch the following session from last year' Global Summit:

https://learning.intersystems.com/course/view.php?id=713

Stephen,

An advantage to this is that the WRC will have a history of snapshots of your config and some basic operating data so that if you need to contact them about a performance issue, behavior change, etc, they could look back and see changes which have taken place in your system that might impact current behavior.  

Several large customers take advantage of this to make it easier to see trends in their instances.

HTH,

Ben

Check out the full tutorial which includes REST API set-up:

https://community.intersystems.com/post/lets-write-angular-1x-app-cach%C...

I completely agree - this would make the results much more helpful!

You can do this via the following (it is a little hidden):

Studio > File > Change Namespace > Connect > (select instance) > Enter credentials and uncheck "Remember Password"

Could you please give this a try and let us know if it works for you?

I have received a stream before as follows in my WebService client:

Method MyWebMethod(pAction As %String = "",  ByRef pFile As %FileCharacterStream = "", ByRef pDataSet As %XML.DataSet = "") As %xsd.base64Binary [ Final, ProcedureBlock = 1, SoapBindingStyle = document, SoapBodyUse = literal, WebMethod ]
{
...

}

I am able to use this method signature to both receive files from the web service as well as send files to the web service.

Hope that helps!

Ben

Studio Source Control (aka Server-side Source Control hooks) are supported if you are using against DBs with version 2016.2 or greater.  If you are one one of these versions and are having issues, I suggest you contact the WRC.

For more details on using Server-side hooks with Atelier, check out this presentation from the Global Summit:

https://learning.intersystems.com/course/view.php?id=713

NOTE - you need to make sure that your DB version has CDS2924 in it in order to protect against a serious bug which would allow Atelier to overwrite things which a user has not checked out of source control.  This will be included in 2017.2.0, 2017.1.2 and 2016.2.3, or you can request it in an Adhoc from the WRC if required.  

Armin,

I took a quick look and the good news is that the Ensemble Management Portal is just wrapping a DS Dashboard.  This means that you can stick this in an iFrame in SharePoint (I think this is called the "Page Viewer Webpart") and point the source to the DeepSee Dashboard Viewer page with the Embed flag turned on.  E.g.  the following link works for me:

http://localhost:57772/csp/ensdemo/_DeepSee.UserPortal.DashboardViewer.zen?EMBED=1&NOBORDER=1&DASHBOARD=Ens%2FDeepSee%2FActivityVolumeAndDuration.dashboard 

Based on your URL above, give this a try:

http://ntvensemble03/csp/activity/_DeepSee.UserPortal.DashboardViewer.zen?EMBED=1&NOBORDER=1&DASHBOARD=Ens%2FDeepSee%2FActivityVolumeAndDuration.dashboard

Report back and let us know if this works, and don't forget to "Accept" the answer if it does :)

Ian - I completely understand why moving to Private Dev is challenging.  It is very much the nature of applications built on top of InterSystems technology, and it is certainly a challenge.  

You are absolutely correct in your thinking that you will see a lot of issues in trying to use Client-Side source hooks (especially for a distributed source control system like Git) against a Shared Dev instance.  I actually presented at Global Summit last week about the interplay between Client vs Serverside hooks and Private vs Shared Dev instances, and I recommended that people avoid the Client-Side / Shared Dev combination.  I would recommend that you download the slides and watch the recording of my session - you will probably find it to be very helpful:

Global Summit 2017: Shared Development for the 21st Century

As you are tied to Shared Dev workflow, I would strongly suggest that you consider using Server-side hooks to enable your dev workflow, and that you use a centralized Version Control System (VCS) like Perforce, Deltanji or Subversion rather than a distributed VCS like Git.  Serverside hooks will enforce the behavior of both Studio and Atelier, so you can still move to Atelier and still use this (just make sure that you are on 2017.2.0, 2017.1.2 or 2016.2.3 as those are the first versions that contain a fix to a hole that was recently found in serverside protections with Atelier).  

In terms of your code promotion question, please keep in mind that Atelier is a development tool and not a deployment tool.  As others have said, TEST and PROD should never have code pushed to it from Atelier but rather the code needs to come directly from your VCS.  I run internal app dev at InterSystems and our process looks like this:

• Shared BASE, TEST and LIVE environments
• Private BASEs for some apps
• BASE, TEST and LIVE branches
• VCS is Perforce
• Serverside hooks on Shared BASE control concurrency and locking of items as they are being edited on Shared BASE
• All check-ins include a logic identifier for the project (a Job in Perforce) 
• When project is ready to move from BASE to TEST, we have a script that integrates all changelists with that Job from the BASE branch to the TEST branch
• Changed items are pulled from TEST branch into TEST environment and compiled
• Same process for moving things from TEST to LIVE

This process works very well for us and scales well on a variety of sized development teams (larger teams use more private BASE environments to prevent check-out collisions on Shared-BASE).  We've been working in this mode for about 7 years and it's really stabilized our environments and branches (compared to how things were before) and we're well positioned to move forward with Atelier in use side by side with Studio.

Hope this helps.  Please watch my Global Summit session and let me know if you have any questions (I plan to write a new article based on my session so feel free to jump in to the discussion there).

Ian - the appropriateness of your architecture relies very much on whether or not there will be more than one developer working on this application and having access to these environments.  Can you please clarify that point?