"Cannot ACCESS job" error message on Windows

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" so that is not available to us.

    The command "openfile" is built into modern windows, and will give you a nice list of open (locked) files, but you have to enable it, and the documentation warns that there will be a "speed" impact; i.e. Windows keeping track at this level slows things down. I dont think this would be good.

    Building on what you have shown, you can actually use "resmon" to get the list of open "job.dpd" files which is the file that xyview/compose uses to lock the Division. "resmon" is the Resource monitor that is accessible from the Task Manager or from just running it from "run" and does not require admin privileges or a command prompt to see the information.

    You select "CPU" and "Associated Handles", and search for "job.log". It will show the "pid" of the process that has it opened. Unfortunately it does not show the user name. From there, the trick to get the user name will work.

    Here is a sample on my XPP with one xyview open.

  • Thanks Steve for tuning in. 
    Resmon does seem to do the job and eliminates the guessing on what exactly is holding the lock on your division.
    So very good suggestion. 
    Thanks

  • So the answer to your original question is: "no, there is nothing we can do to 'divuse' because we can't get the information we need". While not optimum at least there is a way on Windows to figure it out.

  • Hello, 

    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 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:

    • inform the user they've locked something they need to exit, or
    • select one (or all) of the files associated with the job you're trying to free up > right click > close open file. 

    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