Detecting language please wait for.......
You all probably have seen the following error message when trying to open up a division:
But the system is not very helpful in telling you who or why your division is "in use".Maybe there is a co-worker that has the division open for the moment. Or somebody is running a citi or compose process on the entire job. Or maybe somebody is printing the job or division.Or maybe there is a hung process.If you are running XPP on a unix (linux) system, you are in luck.You (or your sys admin) simply runs the "divuse -p" command on that division and the system will give you the USER name and the PID of the process that holds the lock on the division.
But on Windows the -p or -P switches are not supported (see https://community.sdl.com/ideas/contenta-ideas/i/ideas-xpp/extend-the-divuse-tool-on-windows-to-include-the-user-and-pid-info)
There is a Windows tool that can tell you that called Handle (https://docs.microsoft.com/en-us/sysinternals/downloads/handle), but then your sys admin will have to install this and you probably will not get the privilege of using or running this tool. You can always ask nicely your IT departement but the answer will probably be 'NO'.
But if you are in luck, it is another xyview process that has the lock and you are running XPP V9.3 or higher.(older versions are using X-windows and have no MainWindowTitle property)
In that case you can open a powershell window and do the following:
This will give you a nice list with all xyview's running on your system combined with their PID and the division they are working on.
Now if you want to find the user that is running the xyview that is locking the DIV_1-blkmerge, the easiest thing is to start the task manager, goto the Details tab and order things according to their PID and you will find the user that is running PID 2920.
Do you know an easier way preferably without having to install extra tools or utilities?Please comment below if you do!
I've done a little reading and the Windows API does not give you access to the user information. There are references to the fact that "sysinternals" does it by using undocumented API calls in "nt.dll…
A more Windows-y approach would be to use an MMC with an account that has been granted elevated privileges on the application server:
Once you have a blank MMC open, Add/Remove the Shared Folders…
Once you have a blank MMC open, Add/Remove the Shared Folders Snap-in.
Specify your server name along with the radio button next to Open Files.
Click OK and then on the Open Files to display the files open on Your-Friendly-XPP-Server. Sort by the path to ID the user and either:
Since the MMC is already a part of Windows - there's nothing to install and I.T. might only need to grant the necessary permissions for a "special" user to run this MMC on the application server(s) and close files.
Hope this helps- Thomas