go to post Alexander Pettitt · Jan 17 The role is subject to a company's idea of what the role is and their definition is the only one that matters.Will you support the underlying OS for example?The person who can give you the best ideas is the person who had the role before or their manager if they are not available.The application vendor can give you ideas if there is one.Understanding the what, how and why of the existing install is critical. Sign up for product alerts from Intersystems hereConsider getting your own instance hereHere is link for IRIS administration documentation
go to post Alexander Pettitt · Dec 5, 2022 Yes there is a way since I have seen it. The ZLOAD and ZREMOVE commands are combined. Here is a sample I was sent. zr zl showAdmins() n rs1,rs2,rc1,rc2,$NAMESPACE,user,adminrole,roles s $NAMESPACE="%SYS" s rs1=##class(%ResultSet).%New("Security.Roles:List") d rs1.Execute("*","%Admin_Manage:U,%Admin_Operate:U,%Admin_Secure:U") f s rc1=rs1.Next() q:rc1=0 d . s adminrole=rs1.Data("Name") . s rs2=##class(%ResultSet).%New("Security.Users:List") . d rs2.Execute("*",adminrole) . f s rc2=rs2.Next() q:rc2=0 w rs2.Data("Name"),"|",rs2.Data("Roles"),! q d showAdmins
go to post Alexander Pettitt · Oct 26, 2022 Been a long time since I did this but when I did the performance impact was huge with a massive increase (+20%) in CPU. There is still a warning on the app developer site to never do that.
go to post Alexander Pettitt · Oct 7, 2022 This is a pretty severe issue with storage. I would examine why the journals are not getting written.Are you seeing OS errors?
go to post Alexander Pettitt · Sep 21, 2022 something like this works for me echo "h" | iris session [instance] -U [namespace] [routine]
go to post Alexander Pettitt · Sep 1, 2022 Are you looking in ^JOBEXAM or the SMP? As a out of the box idea I am going to suggest screen so you can just keep your session running. I know with VPN connections keeping a session going can be difficult.
go to post Alexander Pettitt · Jul 27, 2022 If you use PURGE^JOURNAL it will keep you from doing anything that will break your system. I would catch up your DR async before deleting journals. You should look at this Purging Mirror Journal Files
go to post Alexander Pettitt · Jul 20, 2022 Yes you could edit the database properties ^DATABASE so a particular database did not journal but I would be worried that the journals will also change the other datasets so I would unmount them before applying journals. It might be better to create a parallel instance and mount the restored database and then replay the journals. For a production issue I would reach out to the WRC.
go to post Alexander Pettitt · Jun 30, 2022 The host, storage and DB engine don't influence the gref count at all. Only what the code does.If you do a set,kill or write that is a gref.The host, storage and DB engine determine the limit of grefs per second.Faster storage is always better.More memory (larger global/routine buffer) is always better.Faster cores are always better. More cores are better if there is work for them to do.Newer versions of IRIS (DB engine) are always better. GLOSTAT will give you some numbershttps://docs.intersystems.com/iris20221/csp/docbook/Doc.View.cls?KEY=GCM_glostat Vertical Scaling IRIShttps://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSCALE_vertical
go to post Alexander Pettitt · Jun 21, 2022 Two possible issues: Are you running a backup? Do you have a network mounted filesystem like NFS or SMB? We need to see messages.log or cconsole.log for the time it was happening.
