New post
AllAccepted answers
Eduard Lebedyuk · Dec 16, 2022

Something like this:

#dim results As EnsLib.LDAP.Message.Results
for i=1:1:results.Results.Count() {
	#dim result As EnsLib.LDAP.Message.Result
	set result = results.Results.GetAt(i)
	write "DN: ", result.DN, !
	write "Attributes: ", !
	for j=1:1:result.Attributes.Count() {
		#dim atribute As EnsLib.LDAP.Message.Attribute
		set atribute = result.Attributes.GetAt(j)
		write $$$FormatText("  - Name: %1, Result: %2, Value: %3", atribute.Name, atribute.Result, atribute.Value), !
	}
}
Eduard Lebedyuk · Dec 14, 2022

I'll start from the simplier one:

and also the use or  DISPLAYLIST &  VALUELIST does this brings any advantage vs defining a standard property (eg.fast access!), so instead of have to do Valuetist "H" and Dispay "Hot" why just a standard property as string containing "Hot"?

More effective storage. If you can replace Cold with 1, Medium with 2 and Hot with 3 you can save some space. Another reason is that VALUELIST turns a string into a enum, which changes the logic considerably.

Eduard Lebedyuk · Dec 13, 2022

Issue looks specific to dynamic objects:

USER>w $zv
IRIS for Windows (x86-64) 2022.1 (Build 209U) Tue May 31 2022 12:16:40 EDT
USER>set obj={"Id":"myId"} 
USER>write $property(obj,"Id")
myId
USER>write $method(obj,"IdGet")
 
WRITE $METHOD(obj,"IdGet")
^
<METHOD DOES NOT EXIST> *IdGet,%Library.DynamicObject

USER>set obj = ##class(User.A).%New()
USER>write $property(obj,"Id")
myId
USER>write $method(obj,"IdGet")
myId
Eduard Lebedyuk · Dec 8, 2022

Great find, Tani!

You can also use the same trick to remove roles temporarily (for example if you need to execute untrusted code):

Class User.Role
{

/// do ##class(User.Role).Test()
ClassMethod Test()
{
    do ..SecurityContext("Test before")
    do
    . new $roles
    . do ##class(%SYSTEM.Security).Login("UnknownUser") // has no roles
    . do ..Untrusted()

    do ..SecurityContext("Test after")
}

ClassMethod Untrusted()
{
    do ..SecurityContext("Untrusted")
}

ClassMethod SecurityContext(context)
{
    w "Context: ", context, !
    w "Roles: ", $roles, !
    w "User: ", $username, !, !
}

}

Produces this output:

Context: Test before
Roles: %All
User: _SYSTEM
 
Context: Untrusted
Roles:
User: UnknownUser
 
Context: Test after
Roles: %All
User: _SYSTEM
Eduard Lebedyuk · Dec 6, 2022

This database stores audit information (actions users took during the instance lifetime).

Depending on your specific situation you might have to keep it for a while due to a contract or compliance reasons.

When DB grows unexpectedly these are the general steps:

1. Check that DB is actually full and not over-expanded. To do that go to SMP-> System Operation -> Databases -> HSAudit. Check % Free Space - that is a space allocated to IRIS.DTA but not used. You can reclaim it by truncating the database.

2. Run ^%GSIZE to get global report and see which globals are the largest. In your particular case, however, you can just go into Globals (from the Databases page) and check IRIS.AuditD which presumably consumes all the space (in details you can calculate space consumption).

3. Based on (2) results do something about the largest globals. In your case, if it's indeed IRIS.AuditD check which system events are logged most often and either fix that (if it's a PROTECT error for example), disable auditing for that particular event. Note that usually old audit entries are purged by a task, maybe something is wrong with that.

Eduard Lebedyuk · Nov 23, 2022
Great!

How does:

As of 2022.2 releases, ARM and Intel platform containers are published under the same name.

So on an Intel machine "docker pull containers.intersystems.com/intersystems/iris:1111.2.3.456.0" will return the intel image, on an ARM machine that same pull will return the ARM image automatically, without needing to have a special .../iris-arm image.

relate to

  • docker pull containers.intersystems.com/intersystems/iris-community-arm64:2022.3.0.545.0
  • docker pull containers.intersystems.com/intersystems/irishealth-community-arm64:2022.3.0.545.0

?

Eduard Lebedyuk · Nov 18, 2022

This question has been discussed with an AWS SWE and their answer is that as long as we're using a main route table for a VPC, it should survive an AZ failure and so we could update it even in the case of an AZ failure.

Additionally, this scenario has been tested (as far as we're able to simulate a failure) and it does work as expected.

While there is an endless variety of how things can fail, I'm reasonably sure that the approach outlined in the article is resilient to an AZ failure.