Actually, reviewing more closely, it looks like your version string is for Unified Care Record / Patient Index. That has a different set of requirements than the basic IRIS migration. I'd recommend closely reviewing the HealthShare documentation - I'm not personally very familiar with the HealthShare side of things, but I'm fairly certain there is a version plateau for HealthShare to allow for the move to IRIS.

edit:

this doc page at least is relevant:

Unified Care Record Installation and Migration Guide > Preparing for an Upgrade Installation

https://docs.intersystems.com/hs20211/csp/docbook/DocBook.UI.Page.cls?KEY=HEINS_prep#HEINS_prep_considerations

"If you are upgrading from a Caché-based Unified Care Record or Information Exchange system earlier than version 2019.1, you must first upgrade to the plateau version 2019.1 before upgrading to this release."

Now that you mention it, I think you have not followed a supported migration path. You can find details in the IRIS migration guides available in the WRC distributions page's documents section, but the minimum version to migrate in-place from is 2016.2.x, and it can be used to go to IRIS 2019.1.1+ or 2020.1. It does not support migration directly to 2021.1.

Can you identify what is being locked? Is it possible the lock is on something internal, and not the table itself?

Sai,

By folder, do you mean moving a class to a different package? It's okay if the class name overlaps, because the package will still differentiate the "full name" of the class.

ex, the following can coexist. 

package1.class

package2.class

You could also use subpackages such as package1.subpackage.class.

Some of the built in class divisions might be helpful for you to compare with - for example, on IRIS for Health, the following packages exist:

EnsLib.HL7.Operation

EnsLib.HL7.Service

etc., for each type of business component.

I certainly agree that having Git / source control set up is a good practice. You may also find the built-in production deployment functionality useful:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_deploying

Hello Alicia,

I would recommend you reach out to your Athena representative for guidance on what version of IRIS to migrate to. I anticipate you will also need them to distribute to you the appropriate kit.

It also sounds like you are planning to go live with this change in the very near future. I would suggest testing this upgrade before attempting in your live environment.

edit: I may have misinterpreted your org. If you are licensed directly with InterSystems, I'd recommend reaching out to your InterSystems account rep. If you are licensed through somebody else, they can help you with the migration to IRIS.

That makes sense to me. As the docs explain, there is not really a "%ALL" namespace, it's more of an abstraction to represent a system-wide mapping.

Once you have set up a %ALL mapping, I would just directly try to verify that the functionality works as you expect. For example, make a AllMapping package and put your test code in there, then make an AllMapping package mapping for %ALL, then confirm that you can access that code in any namespace.

Vivek,

Your version of IRIS for Health doesn't have the SMP UI to create a FHIR server. That was added in 2020.2.

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXIHRN_new#HXIHRN_new_serverui

I'd suggest you look at the 2019.1 docs for your version's instructions. That being said, IRIS' FHIR support is being actively developed so it is changing frequently. If you can upgrade to the latest version of IRIS for Health, you will get access to the most functionality (and quality of life improvements like the SMP option!)

Hello Apoorva,

I see you've already opened a WRC for this. I think it definitely makes more sense to look into this with InterSystems than on this forum.

In general, my questions would be along the lines of why you needed to force the instance, and what other messages were logged. The OS logs will probably also be helpful.

Hey Cedric,

Unattended installs don't have a parameter for journal directories, but you can configure the journal directory with an installation manifest and Config.Journal. This post might be helpful also:

https://community.intersystems.com/post/how-use-unattended-install-perform-following-tasks

Gotcha. Then perhaps the following documentation would be helpful:

Configuring and Using Push Notifications

Hello Muhammad,

Either documentation page explains the difference:

Embedded Language Development > ObjectScript > ObjectScript Reference > ObjectScript Functions > $INCREMENT

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fincrement#RCOS_fincrement_seq

"$SEQUENCE and $INCREMENT can be used as alternatives, or can be used in combination with each other. $SEQUENCE is intended specifically for integer increment operations involving multiple simultaneous processes. $INCREMENT is a more general increment/decrement function.

$SEQUENCE increments global variables. $INCREMENT increments local variables, global variables, or process-private globals.

$SEQUENCE increments an integer by 1. $INCREMENT increments or decrements any numeric value by any specified numeric value.

$SEQUENCE can allocate a range of increments to a process. $INCREMENT allocates only a single increment.

SET $SEQUENCE can be used to change or undefine (kill) a global. $INCREMENT cannot be used on the left side of the SET command."

Hope that helps!