New post
AllAccepted answers
Eduard Lebedyuk · Dec 22, 2022

That depends on the precision you need.

1. If you need just close enough you can do this:

  • Check how much time, on avarage BS takes to run. Let's say X seconds
  • Set Call Interval on your BS to 86400-X
  • Start BS at 10:00 AM
  • Assuming average runtime stays constant it should work well enough

2. If you need to run your BS at exactly at 10:00 AM use this task to achieve that.

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.