I 100% agree with Eduard.

Even back when I had two mirrored instances sat running in the same physical location, we were saved many times by mirroring when there had been issues with either IRIS or the server/OS itself.

It's also very helpful for managing upgrades, and even server migrations (by adding in the new servers as async members, and then demoting a failover member on an old server and promoting a new server from async to failover).

Jumping off of the answer I have given here only earlier today and being in a country currently observing(?) BST, you'll want to use the following approach:

1. Use $ZDATETIMEH with the dformat of  3 and tformat of 7 (Note for the tformat that it's expecting the input as UTC, which is what you have with your source timestamp)
2. Use $ZDATETIME with the dformat of 8 and tformat of 1
3. Realise quickly that the tformat includes separators between the date and time, and within the time itself, so wrap it all in $ZSTRIP to remove all punctuation and whitespace...

Basically this:

WRITE $ZSTRIP($ZDATETIME($ZDATETIMEH("2023-09-28T20:35:41Z",3,7),8,1),"*P")

Gives you this:

And demonstrating this for a date that isn't affected by BST you'll note that the time stays the same as the input because BST isn't in effect in the winter, taking the timezone I'm in back to GMT:

I hope this helps!

The link in my last reply actually contains the answer, which is always useful. I have tweaked it slightly so that it's a single line, but the output is the same.

To get the current date and time with milliseconds, you can do the following:

WRITE $ZDATETIME($ZDATETIMEH($ZTIMESTAMP,-3),3,1,3)

This is:

1. Starting with the output of $ZTIMESTAMP
2. Converting to a $HOROLOG format adjusted for your local timezone using $ZDATETIMEH
3. Converting to the desired format using $ZDATETIME

I hope this helps!

This will be that caveat I warned of which is detailed in the documentation.

You could do something like:

Write $ZDATETIME($h_"."_$P($NOW(),".",2),3,1,3)

Which takes the value of $H and appends the milliseconds from $NOW() to then form your datestamp:

However the documentation I linked to warns that there can be a discrepancy between $H and $NOW() so this approach could then lead to your timestamp being off by up to a second. As you are trying to work to the level of milliseconds, I suspect accuracy is very important and therefore I would not recommend this approach.

Take a look here and see if this example of comparing $h, $ZTIMESTAMP, and $NOW() helps, and the example of converting from UTC to the local timezone helps.

If you replace $h with $NOW(), this should do as you need

However there is a caveat with regards to Timezones mentioned in the online documentation that you may want to review to ensure it works as you'd expect and need.

Have you tried to open the pdf in a text editor like notepad++ to see what it looks like? It might be that the stream is incomplete, or you're writing the base64 to the file output without decoding?

Although I have seen environments where namespaces are used to separate Dev/Test/Prod etc. I have found that having the Prod environment on the same environment as the Non-Prod Namespaces is a risk to the Prod environment should an active piece of development take down the underlying machine (one example was a developer* making a mistake when working with Streams and had created an infinite loop in writing a stream and the server very quickly gained a 10GB pdf that filled the disk to capacity and the environment stopped working).

A common use case for multiple namespace for me would be for instances where the activity within the namespace is significantly distinct from the others. For example, we have a namespace that is dedicated to DICOM activity. While we could have put this in a single "LIVE" themed namespace, the volume of activity we'd see for DICOM would have filled our servers disk if kept to the same retention period as other standard retention period. So we have a DICOM namespace that has a retention period of around 14 days compared to others that are between 30 and 120 days.

*It was me. I was that developer.

The key difference between the two scenarios is that you're running the application for the instances where you are getting the correct time.

Have you checked the server timezone settings for the user running Ensemble in your environment?

This feels like a timezone/locale issue - is the difference between your time zone and UTC also 5 hours apart?

Hi Joshua.

Is it possible that there is a group policy in place that is being applied to you and not your colleagues? Have you tried forcing an update of your group policies applied to your profile - from the windows terminal/command line:

gpupdate /force

Alternatively, do you have any extensions installed in Edge that you don't have installed for Chrome? Maybe an adblocker?

Finally, have you tried opening devtools on this page, refreshing, and then seeing if there are any meaningful errors appearing under the Console or Network tab?

The only way I can think of doing this would be to split out the Helper() ClassMethod into its own class, and then ensure the order of compilation is in such a way that the class containing the Helper class method is compiled. Depending on how you're achieving this, could you use the CompileAfter class keyword?

So something like:

Class 1:

Class Foo.Bar.1
{

ClassMethod Helper()
{
// do something
}

}

Class 2:

Class Foo.Bar.2 [ CompileAfter = (Foo.Bar.1) ]
{

ClassMethod Generated() [ CodeMode = objectgenerator ]
{
do ##Class(Foo.Bar.1).Helper()
// do something else
}

}

There's a good thread from a few years ago that goes into various ways of converting date formats which you can find here.

My approach in that thread was to suggest the use of the class method ##class(Ens.Util.Time).ConvertDateTime()

In your case using this option, you could do this for your main question:

Set Output = ##class(Ens.Util.Time).ConvertDateTime(input,"%Y-%m-%d %H:%M:%S.%N","%Y%m%d")

And then for your followup to include seconds:

Set Output = ##class(Ens.Util.Time).ConvertDateTime(input,"%Y-%m-%d %H:%M:%S.%N","%Y%m%d%H%M%S")

Hi Pascal.

The additional blank lines is something that has come up before here Edit and Resend HL7 Adds Blank Lines | InterSystems Developer Community |

And the response the poster got suggested that this is being addressed in 2024.1.1 and 2024.2.

I can't speak to the IIS issue, but this might be worth raising with WRC?

If I were to write this in an operation using the EnsLib.HTTP.OutboundAdapter, my approach would be something similar to:

	Set tSC = ..Adapter.SendFormData(.webresponse,"GET",webrequest)

	//begin backoff algorithm
	
	//Get start time in seconds
	Set startInSeconds = $ZDTH($H,-2)
	
	//Set initial params for algorithm
	Set wait = 1, maximumBackoff=64, deadline=300
	
	//Only run while Status Code is 504
	While (webresponse.StatusCode = "504"){
		
		//HANG for x.xx seconds
		HANG wait_"."_$RANDOM(9)_$RANDOM(9)
		
		//Call endpoint
		Set tSC = ..Adapter.SendFormData(.webresponse,"GET",webrequest)
		
		//Increment potential wait periods
		If wait < maximumBackoff Set wait = wait*2

		//Adjust wait if previous action takes us above the maximum backoff
		If wait > maximumBackoff Set wait = maximumBackoff
		
		//Check if deadline has been hit, exiting the While loop if we have
		Set currentTimeInSeconds = $ZDTH($H,-2)
		If (currentTimeInSeconds-startInSeconds>=deadline){Quit}
	}

This is untested however, so massive pinch of salt is required 😅

I'm not sure if it's related, but my colleagues and I all notice random performance issues with the management portal when accessing our non-production environment that's using IIS.

It was deployed to our non-production environment for similar experimentation reasons, but I never took it further due to these issues (and it dropped from my radar due to still being on 2022.1.2 with no immediate pressures to upgrade)

I need to upgrade the version of web gateway following a recent email from Intersystems, so I'm going to run that now and then reboot the machine and see if I see any changes.

Beyond that, I'm going to be following this discussion closely to see if our issues are related and if there is a solution.

Such a simple, yet brilliant solution!

Hi Mary.

If you did want to create your own method to do this, you could do something like this:

Class Demo.StopThings
{

/// Stops all services in the specified production
ClassMethod StopAllServices(ProductionName As %String) As %Status
{
    Set sc = $$$OK, currService=""
    Set rs = ##class(Ens.Config.Production).EnumerateConfigItemsFunc(ProductionName, 1)
    While rs.%Next() {
        Set currService = rs.Get("ConfigName")
        Write "Stopping the following service: "_currService_"..."
        Set tSC = ##class(Ens.Director).EnableConfigItem(currService, 0)
        If tSC = $$$OK{Write "Complete!",!}
        Else{Write "Failed",!}
        }
    Return sc
}

}

And then you could call it from terminal from relevant namespace by running:

Set Status = ##class(Demo.StopThings).StopAllServices("Insert.ProductionName.Here")

To use the same code for Operations, change the 1 to a 3 in the call to "EnumerateConfigItemsFunc" (and swap out the bits that say service for operation).

The above is some quick and dirty code to demonstrate the approach you could go for, but you may want to add in some error handling etc to make things more robust given your usecase.