If you specified credentials during installation and don't remember them, you can use this process to get to the terminal prompt:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

After starting in emergency access mode, you can run the command:

Do ^SECURITY

And navigate through the prompts to see what users there are and change the password of one so you can log in.

That's odd - something may have gone wrong with your build. (This is an internal issue.)

You can remove/change the "Source Control" class for the namespace in Management Portal:

Go to System Administration > Configuration > Additional Settings > Source Control, select the proper namespace, select "None," and click "Save."

The class you listed fails for me too, but it's because there's no package name, not because of the bracket mismatch. In Atelier, the class name gets an error marker:

If I change it to:

class somepackage.myclass {
//if someVar {
}

Then the file will happily sync and compile.

If adding the package doesn't fix things, it would be helpful to know what Atelier and Caché versions you're using.

Export with File > Export > General > Preferences; check "Keys Preferences" (which only appears if you've customized any preferences)

Import with File > Import > General > Preferences; select file then check "Keys Preferences"

See: http://stackoverflow.com/questions/481073/eclipse-keybindings-settings

It seems that the CSV export from Window > Preferences, General > Keys, Export CSV ... doesn't have a corresponding import feature.

Ah - yes, a number of things log to ^%ISCLOG. It's very important to set ^%ISCLOG = 0 at the end to keep it from continuing to record. The command I mentioned previously is an easy way to make sure that you're only logging for a brief period of time - paste the command into Terminal and hit enter to start logging, then load the page, then hit enter in Terminal to stop logging. Still, there could be lots of other stuff in there even from having it enabled briefly depending on how busy the server is.

It might make sense for you to contact InterSystems' outstanding Support department - someone could work through this with you directly and help you find a solution more quickly.

Here's a sample, using %ToDynamicObject (2016.2+):

Class DC.CustomJSONSample extends %RegisteredObject
{
Property myProperty As %String [ InitialExpression = "hello" ];

Property other As %String [ InitialExpression = "world" ];

/// Rename myProperty to custom_property_name
Method %ToDynamicObject(target As %Object = "", ignoreUnknown = 0) [ ServerOnly = 1 ]
{
	Do ##super(.target,.ignoreUnknown)
	Do target.$set("custom_property_name",target.myProperty,target.$getTypeOf("myProperty"))
	Do target.$remove("myProperty")
}

ClassMethod Run()
{
	Set tObj = ..%New()
	Write tObj.$toJSON()
}

}

Output:

SAMPLES>d ##class(DC.CustomJSONSample).Run()
{"other":"world","custom_property_name":"hello"}

For other discussions with solutions/examples involving %ToDynamicObject, see:
https://community.intersystems.com/post/json-cache-and-datetime
https://community.intersystems.com/post/create-dynamic-object-object-id

Also see the class documentation for Security.Applications:

[quote]

Bit 2 = AutheK5API
Bit 5 - AutheCache
Bit 6 = AutheUnauthenticated
Bit 11 = AutheLDAP
Bit 12 = AutheLDAPCache
Bit 13 = AutheDelegated
Bit 14 = LoginToken
Bit 20 = TwoFactorSMS
Bit 21 = TwoFactorPW

[/quote]

The problem is that REST uses IO redirection itself, and OutputToStr changes the mnemonic routine but doesn't change it back at the end.

For a great example of the general safe approach to cleaning up after IO redirection (restoring to the previous state of everything), see %WriteJSONStreamFromObject in %ZEN.Auxiliary.jsonProvider.

Here's a simple approach that works for me, in this case:

set tOldIORedirected = ##class(%Device).ReDirectIO()
set tOldMnemonic = ##class(%Device).GetMnemonicRoutine()
set tOldIO = $io
try {
	set str=""

	//Redirect IO to the current routine - makes use of the labels defined below
	use $io::("^"_$ZNAME)

	//Enable redirection
	do ##class(%Device).ReDirectIO(1)

	if $isobject(pObj) {
		do $Method(pObj,pMethod,pArgs...)
	} elseif $$$comClassDefined(pObj) {
		do $ClassMethod(pObj,pMethod,pArgs...)
	}
} catch ex {
	set str = ""
}

//Return to original redirection/mnemonic routine settings
if (tOldMnemonic '= "") {
	use tOldIO::("^"_tOldMnemonic)
} else {
	use tOldIO
}
do ##class(%Device).ReDirectIO(tOldIORedirected)

quit str

It would be cool if something like this could work instead:

new $io
try {
	set str=""

	//Redirect IO to the current routine - makes use of the labels defined below
	use $io::("^"_$ZNAME)

	//Enable redirection
	do ##class(%Device).ReDirectIO(1)

	if $isobject(pObj) {
		do $Method(pObj,pMethod,pArgs...)
	} elseif $$$comClassDefined(pObj) {
		do $ClassMethod(pObj,pMethod,pArgs...)
	}
} catch ex {
	set str = ""
}

quit str

But $io can't be new'd.

You could map the package containing the class related to that table using a package mapping, and the globals containing the table's data using global mappings.

You can see which globals the class uses in its storage definition - since the entire package is mapped, it might make sense to add a global mapping with the package name and a wildcard (*).

After taking those steps, you can insert to the table the way you usually would, without any special syntax or using zn/set $namespace.