What risk?

There are two distinct cases - where we have users/passwords in place or we don't.

In the first case container should use these passwords (via Durable %SYS) and they shouldn't be be superseded by anything happening with a container change.

In the second case we have some empty application - no users, no data and so specifying random password only adds unnecessary steps down the line.

There is one case where we need to force our container user to create new password - when we are:

  • supplying a complete application
  • don't have control over how it is deployed
  • passwords are stored inside the container

in this case yes (when all conditions are met), password should be scrambled, but this situation is wrong on itself (mainly in storing passwords inside the container), and should be resolved by other means.

1. Import task has these two qualifiers:

displayerror
displaylog

They do not affect import.

2. No. If you check exported xml, you can see that exported tasks do not contain IDs, so, on import they could not overwrite existing tasks. Not sure about how correlate/next work on ID fields btw.

Exporting and importing what is currently present is the best way. 

It's the easiest way. The best way would be to write and document  a script (ObjectScript code) that transforms base instance into what they need. This way changes are documented and adding another server is easy.

Sure.

  1. Open Chrome
  2. Go to Settings | Manage search engines...
  3. Scroll to the bottom of the window
  4. In Add a new search engine, enter InterSystems
  5. For Keyword, enter i
  6. For URL, enter one of:
  7. Click Done

After that you'll be able to search InterSystems documentation in Chrome address  bar by typing:

i keyword

and pressing Enter.

Compilation is usually multi-process, I'd try single-process compilation and see how it works:

$SYSTEM.OBJ.Compile(.classes, "/multicompile=0")

Multicompile qualifier:

           Name: /multicompile
    Description: Enable use of work queue manager (optionally specify the number of workers if value >1)
           Type: string

UPD. Who throws a RESJOB? Do you want to kill compile process from external process (that was my idea)? Or do you want to terminate abnormally?  If it's the second you need to check errolog from Compile method and terminate the process explicitly:

do $system.Process.Terminate(, 1)

Also I wrote a series of articles on managing Continuous Delivery process. Check it out.