When using the command docker exec -it iris iris terminal IRIS, it automatically logs you in as the irisowner user. To log in as a different user, you need to run the command interactively and specify the desired username and password. The process is as follows:

1. Open a terminal session in the container using:
   docker exec -it iris iris terminal IRIS

2. This will prompt you for a username. Instead of proceeding automatically, enter the username you want (e.g., admin) and follow with the corresponding password for that user.

3. If authentication details are required to be automated, consider passing environment variables during container setup to define the user and password. For example:

   docker run --rm --name iris -d -p 9091:1972 -p 9092:52773 -e IRIS_PASSWORD=yourpassword -e IRIS_USERNAME=yourusername intersystemsdc/iris-community
   

This approach ensures you can initiate sessions under a different user account [1][2].

Sources:

Yes, it is possible to change namespaces within a single connection object. This can be done in ObjectScript using the $NAMESPACE or $ZNSPACE special variables, or by using commands such as ZNSPACE or SET $NAMESPACE. These methods allow temporarily switching the current namespace, either for the duration of the routine or programmatically as needed.

When changing namespaces programmatically, the recommended approach is to use NEW $NAMESPACE followed by SET $NAMESPACE, which ensures that the namespace automatically reverts when the routine concludes or an unexpected error occurs. This prevents issues that may arise from leaving the namespace context inappropriately changed [1][2][3].

For additional control or safety when switching back to the previous namespace, you can store the original namespace, perform your operations in the desired namespace, and explicitly return to the original one using SET $NAMESPACE=<PreviousNamespace> [3][2].

Changing namespaces programmatically in application code should usually be avoided unless strictly necessary, as it may have performance implications and could introduce errors in handling objects or SQL cursors if they span across namespaces. For application-specific functionality, other practices such as global mappings or methods in separate productions might be more suitable [1][3][2].

Sources:

To remove fractions of seconds from a %Library.PosixTime value without employing string manipulation, consider converting directly while using predefined precision options, which avoid the inefficient handling of strings.

Using the $ZTIME ObjectScript function for manipulation, you can truncate fractional seconds by specifying a precision of 0. For example:

SET timestamp = ##class(%Library.PosixTime).LogicalToTimeStamp(posix)
SET strippedTimestamp = $ZTIME($PIECE(timestamp, ",", 2), 1, 0)
SET newposix = ##class(%Library.PosixTime).TimeStampToLogical(strippedTimestamp)
WRITE ##class(%Library.PosixTime).LogicalToTimeStamp(newposix)

This approach uses $ZTIME to specify "time precision as `0 fe", ensuring no trailing fractions [1][2].

Make sure that your targeted precision maintains the format requirements [3][4].

Sources:

The issue you are facing with license limits appears to be due to the fact that each browser connection reserves a license for a period of time. Here's how you can diagnose and address the problem:

1. Understanding License Usage and Release:

   • When a browser session accesses a web-enabled Cache application, it consumes a license. Even after closing the browser, the license is not released immediately because the system's grace period retains license slots for a duration after connection closure to prevent unauthorized license sharing [1][2].

2. Viewing Current License Use:

   • You can access the Management Portal's "System Operation > License Usage" page to check details such as which users or connections are consuming the licenses, and whether they are being released properly [1][3][2]. Alternatively, use the terminal command Do $system.License.ShowSummary() for a summary of license usage [1].

3. Forcing License Release:

   • Sometimes, the system doesn't release licenses immediately due to lingering connections or processes. If licenses are stuck, you can attempt to manually end sessions or wait for the grace period to expire. You can also analyze specific lingering sessions with $SYSTEM.License.DumpLocalInUse() to identify which connections are consuming licenses [1].

4. Optimizing Connections and Users:

   • Ensure that only one session per user is open at any time from a specified IP to minimize the use of multiple licenses [2][1]. Closing unused browsers or tabs or configuring the application to reuse sessions can also help reduce consumption.

5. Checking and Configuring Licensing:

   • Verify that your Cache license meets your use case. If not, you might need to discuss more advanced license configurations with InterSystems to avoid unnecessary reoccurring restarts [1][3].

These steps should help you better manage license use and mitigate the issue. Let me know if you need further clarification.

Sources:

It appears you are facing a challenge with invoking JavaScript code to close a pop-up window and calling a function in the parent window from your CSP page. Below are some suggested approaches to resolve these issues:

1. Using JavaScript window.close and opener: To ensure the parent window interacts with the child pop-up window, you can utilize window.close along with opener.<functionName>. Make sure the parent window's function is callable via the opener. For example:

   function exitPopup() {
      opener.processImport();
      window.close();
   }
   

   This ensures the parent window's processImport function is invoked before the window is closed [1].

2. Handling the onunload Issue: If the onunloadHandler is not firing or behaving inconsistently, ensure the modal behavior is explicitly managed. The approach might depend on the settings of useSoftModal, as the behavior of launchPopupWindow can vary when this setting changes. Testing to confirm the modal window behavior under different browsers, including Edge, is critical [2][1].

3. Calling ZenMethods on Page Unload: Ensure ZenMethods are configured properly for synchronous calls during the onunloadHandler execution:

   var old = zenSynchronousMode;
   zenSynchronousMode = true;
   this.SomeZenMethod();
   zenSynchronousMode = old;
   

   This ensures the method is executed synchronously during page unload [1].

If further clarification or assistance is required, especially considering unique configurations and browser compatibility issues, please consult the Developer Community for detailed guidance.

Sources:

To record function calls dynamically without modifying all functions in code, you can use tools like %SYS.MONLBL, the TRACE utility, or external profiling tools. Here are some options:

1. %SYS.MONLBL: This built-in utility is designed primarily for performance tracing. It can monitor all routines called in a process, including transitions between functions and routines. To use it:

   • Start your application in one terminal session.
   • Use another session to run %SYS.MONLBL, specifying the process ID of your application session.
   • Perform the operations you want to trace, then review the generated report in %SYS.MONLBL. Note that this might not fully work with deployed code and focuses on performance rather than debugging details [1].

2. TRACE Utility: This tool can monitor the execution of scripts, including function calls. Refer to the InterSystems documentation or communities for more detailed setups of TRACE for function monitoring [1].

3. Stack Inspection:

   • Use routines to save or display stack information dynamically, such as $Stack, which can reveal the execution path.
   • Stack information can be saved via a method like:
     objectscript
ClassMethod StackToDisplay()
{
For loop = 0:1:$Stack(-1) {
Write !, "Context level:", loop, ?25, "Context type: ", $Stack(loop)
Write !, ?5, "Current place: ", $Stack(loop, "PLACE")
Write !, ?5, "Current source: ", $Stack(loop, "MCODE")
Write !
}
}
     This approach provides lightweight function call tracking without constantly modifying every function [2].

These methods allow dynamic call recording without hardcoding manual markers in each function.

Sources:

The error and issues encountered while processing large CCDA files with the EnsLib.EDI.XML.Document:GetValueAt method can be attributed to string and object limitations. Here's a detailed response with potential solutions:

1. MAXSTRING Error when using GetValueAt Method
a. Reasons:
- If the data at the location specified in GetValueAt exceeds the maximum string length for %String, this error happens.
- The default maximum string length in InterSystems IRIS or Caché environments is 3.64 MB unless adjusted by enabling long strings.

b. Solution:
- Instead of extracting large strings directly, use stream objects. Create a stream from the raw data and operate on this stream to bypass the string size limitation:
objectscript
Set stream = ##class(%GlobalCharacterStream).%New()
Do object.GetFieldStream("YourLocationPath", .stream)
- Ensure long strings are enabled in your IRIS configuration under System Administration to increase internal string size limits [1][2].

2. INVALID OREF Error during Conversion
a. Reasons:
- This error often arises when attempting to perform operations on an invalid object reference (OREF). Specifically, this could happen if the GetSubDocumentAt method isn't returning a valid object.

b. Solution:
- Always verify the object reference before attempting any further actions using the $isobject function:
objectscript
If '$isobject(subDocument) {
Throw ##class(%Exception.InvalidOrefException).%New("Invalid object reference.")
}

• Alternatively, use the ImportFromStream method of EnsLib.EDI.XML.Document if you'd prefer better memory-handling mechanisms:
  objectscript
Set newDoc = ##class(EnsLib.EDI.XML.Document).ImportFromStream(rawStream, .status)
If $$$ISERR(status) { Write "Error importing document!" }

3. General Recommendations for Extracting Narrative Text:
- If repetitive reads of large node content are required, consider writing a custom class/method to handle specific object-based operations. Streamline operations by processing larger XML structures into manageable chunks or storing specific values in temp files.
- For schema-based documents, verify that proper namespace handling or schema validation paths are followed [2][3].

For improvements in handling errors based on memory and OREF limitations, focus on preventive and refactored use of streams for large content, validated object references, and clear fallback strategies. [1][4][5][6]

Sources:

The issue arises because Python's print statements and IRIS's ObjectScript write statements operate on different devices, causing your custom Buffer class in ObjectScript to not capture these outputs. To address this, you can redirect Python's output to a stream more integrated with ObjectScript. Here are some possible solutions and approaches:

1. Using TCP Device for Output Redirection:
   Set up a TCP listener to capture the output from Python and use the write command for ObjectScript to send data. This approach ensures Python's output is redirected to a specific listener that can be handled by your Buffer.

   Example:

   • On the ObjectScript side, configure the TCP device:
     objectscript
open "|TCP|4":("127.0.0.1":4200::$CHAR(3,4)):10
use "|TCP|4"

• From Python, write to the same device:
  python
import socket
TCP_IP = '127.0.0.1'
TCP_PORT = 4200
BUFFER_SIZE = 1024
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((TCP_IP, TCP_PORT))
s.send(b"Python print statement redirected!")
s.close()

  This setup will unify Python and ObjectScript outputs for capturing [1].

2. Custom Python Output Stream:
   Implement a custom output stream in Python to intercept the sys.stdout and redirect everything to an ObjectScript-compatible format:

   import sys
   class CustomStdout:
      def write(self, text):
          # Implement logic to capture and redirect text to ObjectScript
          print("Redirected:", text)
   
      def flush(self):
          pass
   
   sys.stdout = CustomStdout()
   

   You can use CustomStdout to marshal Python's print output to your Buffer [1].

3. Combining Both Approaches with the iris object:
   Utilize the IRIS Python SDK to directly invoke ObjectScript's methods that align well with your Buffer functionality:

   import iris
   iris.pyrun('write("Captured directly into Buffer")')
   

   This ensures a direct capture of Python's outputs into ObjectScript-compatible streams [1].

These configurations will help you unify Python and ObjectScript outputs, enabling your Buffer class to successfully capture statements irrespective of their source.

Sources:

Creating a %Installer.Manifest file from the current state of an InterSystems IRIS instance and managing its changes is theoretically possible using InterSystems tools, but no specific documentation references a generator or exporter tool for this purpose. Here are insights and possible steps:

1. Using an Installation Manifest:
   A manifest class in InterSystems IRIS allows you to define and configure specific configurations declaratively. You can create a custom class with an <XData> block specifying the attributes and methods necessary to set up namespaces, CSP applications, roles, and databases. For example, <Namespace> and <Database> tags may be used to set up namespaces and databases corresponding to your current environment. The setup class method typically uses %Installer.Manifest for execution [1][1].

2. Tags and Variables in Manifest:
   You can dynamically generate configuration setups using variables embedded in tags like <Manifest>, <Namespace>, and <Database>. These tags provide flexibility to replicate environment setups declaratively. ObjectScript expressions can also expand values during execution [1].

3. Manual Definition of Components:
   Specific details of your IRIS instance, such as namespace settings, security roles, and CSP applications, must be extracted manually or programmatically. Consider using commands such as MERGE or leveraging other APIs documented for IRIS to extract and replicate elements [3][4][5].

4. Management of Logs and Messages During Deployment:
   The setup method of %Installer allows directing messages and logs for deployment tracking. These can be stored externally for audit trails or debugging during environment replication [1].

5. Export and Automation Possibilities:
   Although building a fully automated generator is not described in the current documentation, the modular nature of manifest definitions, provided examples, and utilities for setting up elements can guide constructing your “auto-export tool” using ObjectScript or related automation.

For partial tools or scripts:
- Referencing %Installer.Manifest and using its methods for defining databases, namespaces, and roles programmatically can be an initial approach.
- Engaging with the Developer Community could provide tailored solutions or open-source implementations shared by other developers [1][5].

If you need guidance on creating specific components within %Installer.Manifest, feel free to ask!

Sources:

To calculate the difference in hours (with decimals) between two %TimeStamp values in ObjectScript, you can use the $ZDATETIMEH function to convert the timestamps into $HOROLOG format, and then calculate the difference using appropriate arithmetic. Here is an example approach:

Code Implementation

ClassMethod CalculateHourDifference(startTime As %TimeStamp, endTime As %TimeStamp) As %Float
{
    // Convert start and end times to $HOROLOG format
    Set startTimeH = $ZDATETIMEH(startTime, 3)
    Set endTimeH = $ZDATETIMEH(endTime, 3)

    // Calculate the difference in days and seconds
    Set dayDiff = $PIECE(endTimeH, ",", 1) - $PIECE(startTimeH, ",", 1)
    Set timeDiff = $PIECE(endTimeH, ",", 2) - $PIECE(startTimeH, ",", 2)

    // Combine the difference into hours
    Set totalHours = dayDiff * 24 + (timeDiff / 3600)

    Return totalHours
}

Explanation

1. $ZDATETIMEH(timestamp, precision) converts a %TimeStamp into $HOROLOG format with the precision value 3 for best compatibility [1][2].
2. $HOROLOG format consists of two parts: the number of days since 31 Dec 1840 and the number of seconds since midnight of the current day.
3. By calculating day and second differences separately, you can then convert the total time difference into hours.

Example

Using your provided timestamps:

Set startTime = "2024-07-12 08:30:00"
Set endTime = "2024-07-12 15:15:00"
Write ##class(YourClass).CalculateHourDifference(startTime, endTime)
// Output: 6.75

This approach ensures precision and clarity while working with timestamps in ObjectScript. [1][2]

Sources:

a) The <EXTERNAL INTERRUPT> error might occur due to an operation that has been interrupted by the system, typically caused by a timeout, or a forced user action or process interruption. This happens when the code execution is halted by an external signal like a system-level command. For more complex handling, implement proper timeout handling or consider logging additional details to diagnose such occurrences further [1][2][3].

b) To view the .INT or .MAC code associated with .OBJ, you can utilize debugging commands or tools within the Cache platform. Using the ObjectScript terminal, invoking debugging frameworks like %SYS.Debug could help. However, ensure that debugging permissions are appropriately assigned. Consider methods or tools that provide insights into such .OBJ routines or consult specific debugging best practices documentation applicable to your Cache release version. Without exact tools defined, specific steps can sometimes be ecosystem-managed system [3][4][5].

Further challenges in processing may arise from mismatches of commands - swizzle directions, context pointer handling errors-hands values. Advised debugging tools , e.g invoke"""

Sources:

There is no direct documentation or feature in InterSystems Package Manager (IPM) that specifically addresses handling System Default Settings for CI/CD pipelines. However, here are potential approaches based on available information:

1. System Default Settings: These settings simplify management of environment-specific configurations, such as file paths, port numbers, etc., and can be exported/imported using methods like %Export and %Import. It is advisable to integrate these methods into your pipeline processes to automate these tasks [1][2].

2. Custom Automation: While not directly tied to IPM, you can use tools or scripts, such as the GetSettingsFromProduction method, to gather and setup System Default Settings efficiently during the deployment process. This method allows filtering specific settings and automating their migration to the system defaults table [3][4].

3. Source Control: System Default Settings can be exported and tracked in version control. Each branch or CI/CD environment can include specific setting files, which can then be applied programmatically during deployment [2].

If Invoke scripts are acceptable for your case or specific automation needs, they could wrap around these export/import or automation methods to ensure smooth integration without extending IPM itself. For completely eliminating custom solutions, consider submitting a feature enhancement request on InterSystems Developer Community.

Sources:

1. To list a user and their properties, including roles, you can use ObjectScript commands with the Security.Users class in the %SYS namespace. An example of listing the properties of a user is:

NEW $NAMESPACE
SET $NAMESPACE="%SYS"
SET status = ##class(Security.Users).Get("Username", .properties)
IF $$$ISOK(status) {
    ZWRITE properties
}

This retrieves the user's properties into a reference variable and displays them [1][2].

2. To add a user and set their properties, including roles, you can use the Create method of the Security.Users class. For example:

NEW $NAMESPACE
SET $NAMESPACE="%SYS"
SET properties("FullName") = "New User"
SET properties("Password") = "securepassword"
SET properties("UserRoles") = "%Developer,%Operator"
SET status = ##class(Security.Users).Create("NewUser", .properties)
IF $$$ISOK(status) {
    WRITE "User created successfully."
}

This creates a user with specified roles and other details [1][2].

3. To set a user's password, you can use the Modify method to update the relevant property, as in:

NEW $NAMESPACE
SET $NAMESPACE="%SYS"
SET status = ##class(Security.Users).Get("Username", .properties)
IF $$$ISOK(status) {
    SET properties("Password") = "newpassword"
    SET status = ##class(Security.Users).Modify("Username", .properties)
    IF $$$ISOK(status) {
        WRITE "Password updated successfully."
    }
}

This updates the user's password [1][2].

Sources:

The use of a separate license server in an HA mirroring environment, such as hosting it on the arbiter machine, might alleviate licensing issues during failovers. Below are key considerations regarding licensing and communication between mirrored servers and users:

1. Role of ISCAgent and Arbiter: The ISCAgent on arbiter machines assists the failover process by ensuring communication reliability between mirror members, even during failovers [1][2]. It does not directly manage user sessions but enables seamless failover between mirrored servers.

2. Licensing Impact on User Sessions: The documentation does not explicitly mention whether adding a license server to the arbiter would prevent users from logging back in after failovers. However, setting up proper failover mechanisms and ensuring that the ISCAgent process is correctly configured on all mirror members can help maintain application continuity during failover [1][2][3].

3. Configuring ISCAgent for Communication: The agent can be configured using /etc/iscagent/iscagent.conf to define the server port and interface. Proper configuration of this communication layer can strengthen connections between mirrored members [3].

Without further specific documentation on the license server itself, you might need to test or consult with support to understand potential benefits or issues before adopting such a setup.

Sources:

CSP pages in InterSystems IRIS do include mechanisms to interact with JavaScript asynchronously using features like "HyperEventHead()" and "HyperEventCall()". These functionalities allow the execution of server methods triggered by client-side JavaScript, making it possible to update the UI without refreshing the page. However, it appears that the dynamic invocation of server-side code is managed through mechanisms such as cspHttpServerMethod, which relies on specific server support rather than JavaScript's native Promise or async/await functionalities [1].

If you need fully asynchronous JavaScript futures support, it might require an alternative to CSP, such as modern JavaScript frameworks (e.g., Vue.js, React) communicating via REST APIs, as suggested in discussions about the evolving practices for frontend-backend integrations with IRIS [2][3].

Sources:

The "ErrST+6^%ETN" error message you encountered within %ETN suggests that the application encountered an error during the execution of the error trap utility %ETN. The utility is designed to save information about an error, including the execution stack, job state, and variable values, to the application error log. However, since the error occurred within %ETN itself, detailed error logging was not possible in this instance [1][2][3].

To address errors encountered during the use of %ETN:
1. You can view the application error logs using either the Management Portal or the ^%ERN utility to examine other related logs. This may provide additional clues about the failure [1][4].
2. Consider setting up the $ZTRAP variable to handle or analyze the error before invoking %ETN. For instance:
ObjectScript
SET $ZTRAP="^%ETN"
This ensures that any errors occurring are captured and logged by %ETN [1][5].

Lastly, while dealing with unusual date entries (e.g., "01/06/1841"):
- Review and filter error logs using the Management Portal or ^%ERN, specifically searching by date or error substrings [4][6].
- Check if any system or user inputs inadvertently set such dates during logging or processing activities, as they may be erroneous.

Sources:

To log an exception to the Application Error Log in InterSystems IRIS, you should use the %Exception.AbstractException.Log() method. Typically, this is done within the CATCH block of a TRY-CATCH construct. Here is an example in ObjectScript demonstrating this approach:

TRY {
    // Code that might throw an exception
} 
CATCH ex {
    // Log the caught exception to the Application Error Log
    DO ex.Log()
}

This method ensures that the details of the exception, including its type and properties, are recorded in the namespace-specific Application Error Log [1].

Sources: