We found that if we execute EnableConfigItem from the shell on the OS level we can kick off multiple processes (multi-threading) up to 125 instances much faster than doing this from an Object Script in Terminal.

I did not get the same error, and it was successful.

Alex, 

I tried that but now I am receiveing... ERROR #5002: ObjectScript error: <UNDEFINED>zDecodeBase64HL7ToFile+22^osuwmc.Functions.1 *%C(10)

ClassMethod DecodeBase64HL7ToFile(base64 As %Stream.GlobalBinary, Ancillary As %String, FileName As %String) As %String

{

  set ArchDir = "/ensemble/data/transfer/AncillaryPDF/"

  set ArchAncDir = ArchDir_Ancillary_"/"

  set FaxDateDir = ArchAncDir_$PIECE($ZDATE($HOROLOG,7)," ",1)_"-"_$PIECE($ZDATE($HOROLOG,7)," ",2)_"-1/"

  if '##class(%Library.File).DirectoryExists(ArchDir)

  {

    do ##class(%Library.File).CreateDirectory(ArchDir)

  }

  if '##class(%Library.File).DirectoryExists(ArchAncDir)

  {

    do ##class(%Library.File).CreateDirectory(ArchAncDir)

  }

  if '##class(%Library.File).DirectoryExists(FaxDateDir)

  {

    do ##class(%Library.File).CreateDirectory(FaxDateDir)

  }

  set Oref = ##class(%FileBinaryStream).%New()

  ///$$$LOGINFO(FaxDateDir_FileName)

  set Oref.Filename = FaxDateDir_FileName

  Do base64.Rewind()

  While 'base64.AtEnd {

      set ln = base64.ReadLine()

      set:ln[%C(10) base64.LineTerminator=$C(10)

      set lnDecoded = $system.Encryption.Base64Decode(ln)

    do Oref.Write(lnDecoded)

  }

  Do Oref.%Save()

  set PDFFilePath = FaxDateDir_FileName

  return PDFFilePath

}

By Adding a timeout of 2, and setting the force flag I was able to get it down from 18 min to roughly 11 min. If I remove the timeout and force flag, and watched the output I could possibly find those problematic children. I wonder if using Ens.Job would be any easier as the objects have been disabled its a matter of getting the Jobs to stop and send the unbind. 

Has anyone used Ens.Jobs before to quickly bring down a Namespace in a controlled environment? We need to unsure the unbinds are sent so we can move to a new IP address on a different section of the network.

Using the suggestions below, looping through the Config Items doesn't appear to be the issue. I ran into an issue with the UpgradeProduction. In total it took 18 min to shutdown all the Services in just one namespace when I looped through all the Config Items, disabled them, and then Updated the Production with no timeout or force to shut them down. Is there a way to make UpgradeProduction run faster beside setting the timeout or force?

Thanks @Jeffrey Drumm, I had the same thoughts. I am working with other team members in discussing the options to see what is best.

I need to be able to loop through all the Services/Operations to shut them down to ensure that the TCP Disconnect is sent. 

We had a consultant create us a script that uses Regex to loop through and shutdown those Services/Operations, but running the script to bring everything down takes a good 10 min or so to disable all the Service Operation Objects.

In testing the cut over when we did our Test Environment in total it took us 20 min to bring down Ensemble (2018.1.3) and bring up IRIS (2022.1) with the network changes.

But we forgot this step and had to ask different systems to restart their Interfaces because they were still hung on the previous connections and don't have framework to realize the connection was no longer connected.

Is there a way to be able to cutdown the response time of EnableConfig item?

There wasn't any clear cut explanations on how I could use that. Do you have some examples?

I tried the open also. But I did find a work around by resetting the ##class(%File).SetAttributes which is basically doing a chmod but at the ObjectScript level when creating/appending to the file. 

So what is %Stream really doing, is it just creating a new file based on what is in memory? Is it just reading the entire file into Memory so the IO is cut down and creating a new file from what is in Memory?

the Function is already using %Stream.FileCharacter and MoveToEnd(). After MoveToEnd() is called the second time we see the permissions on the file get updated.

We have gone through all the permission settings at the directory and user level. We do not believe it is an unmask issue as the file is ok when it is first created, but the subsequent writes cause the permissions to change. If it was an unmask issue wouldn't the file have the wrong permissions in the first place? And I confirmed its not a user issue as its been duplicated with the owner of the directory and others within the same group.

Instead of MoveToOpen is there a way to use Open the file and go to the end of the file to insert the data? I tried looking at %File but could not figure out now to append data to the end of the file I just kept overwriting data.

Not really... 

I am not sure if this matters, but I deleted and re-created the TESTCLIN namespace while this was still on the scheduler and trying to run. I updated the Report settings to point to the new TESTCLIN namespace but still receiving this error. I have opened a ticket with WRC to see if the Doc DB IRISInteroperabilityPorts just needs deleted from TESTCLIN and we try again.

I tried parallel processing by splitting messages between the two business processes however I ran into deadlock issues, so thats out of the question. But thanks