Thanks @Guillaume Rongier !  That works great.  FYI ... we can see the request attempt on the IRIS side with a Description = "%Service_SuperServer login failure", noting the IP Address of your Linux web server, and Event Data which mentions "Error message: ERROR #949: Unable to get full header of message within timeout" 

@Abhishek Raj - start with reviewing the documentation for new features, and Upgrade Compatibility checklists:
This will be the most comprehensive collection of suggestions, things to know, and 'gotcha's' to be aware of.  

Beyond reading the docs and seeing what is applicable to your environment, do a practice upgrade of your application and TEST, TEST, TEST :)  

Lastly, make sure you review the supported platform list for 2018.1 and 2015.2:



Hope that helps!

@William Vorhees  - thank you for mentioning this ... we are looking into it.

It is just an issue with your account and is not a broad issue with the service.  We'll get it taken care of as quickly as possible.

@Ephraim Malane - without having the actual CCR IDs, most likely the case is that your CCR deployed through TEST added a file, and CCR will automatically detect if the CCR that added a file is not yet in the target environment and therefore will prevent other CCRs from 'leap-frogging' past it.  This is because if you leap past a CCR which originally adds a file, if you later need to back out the CCR it will result in a 'delete' of the file from all environments (because you're undoing an 'add').  

Probably the best bet for you is to reach out to Support so they can help you manually move the 'add' into the CCR that you want to move forward.  You will probably also need help cleaning up the CCR that you cancelled, as I am guessing that the backout failed due to edits already being promoted to TEST on top of the 'add' that you are trying to back out from there.

As we looked into things further on our side, it appears as though the UNIX 'hostname'.  We were able to resolve the issue in UNIX by doing the following to change the hostname to 'mynewhost':

log in as root
hostname mynewhost
echo mynewhost > /etc/hostname

The 2nd line will change the hostname in the current processes, and the 3rd will make sure that the change will persist during a reboot.  

Hope this is helpful to someone else.

@Colin Brough - all great questions!  I'll provide some thoughts and I am sure others will chime in as well.  One question that I have which may impact the answers is what your current source control approach is?  Are you using serverside source control hooks with Studio or some other approach?

  • Take Atelier off the list and drop it from consideration... it is deprecated new work shouldn't be started with it
  • VSCode is the path forward for InterSystems technologies; it used the Atelier REST APIs and therefore you can use it on Caché 2018.x (originally added in 2016.2 IIRC)
  • You can typically use VSCode alongside Studio, depending on your answer to the above question about your source control approach.  If you are using no source control, or if you are using serverside source control, then Studio and VSCode can both be used against the instance in mixed mode (my team has been doing this for years)
  • I can't speak to what you lose with VSCode but I believe that at this point the answer is either 'very little' or 'nothing' for all intents and purposes
  • I can't speak to Studio Templates (hopefully someone else can weigh in)

This video may also be helpful to you: 

Hope this is a good starting point.

It is the actual code as it will be executed, so "Do ##class...."