Close Open files in Library

How can I list and close all open files in a particular library?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dave FordSoftware Developer / Database AdministratorCommented:
You can run WrkObjLck on a specific object, but I'm not aware of how to do it for an entire library.

I suppose you could dump all the file-names to an out-file (a table) and write a little CL program to loop through that table and do a WrkObjLck with output(*outfile). That might work.

Gary PattersonVP Technology / Senior Consultant Commented:
Might help if you explained why.  This sounds like it might be backup-related or reorg-related.  In those cases, you'd usually end the subsystems where user jobs, batch jobs, and services run to eliminate locks and errors.  That will end all the jobs holding locks, and release all your locks.

Here is an article that has code attached for a similar program.  It is designed to fins all the jobs locking a given file, alert the users, and then after a time, end the jobs.  You'd just need a little modification to dump a list of files, using DSPFD, for example, and then read the file, ending the jobs that are found to lock any of the files in the library.

The problem is, that by the time you do that, some processes, especially client-server processes, may attempt to reconnect on their own and start locking files all over again - maybe before you even make it all the way through the list.

That's why it is a better approach to have your work management configuration set up so that all non-system work happens in dedicated subsystems: QINTER, QBATCH, QUSRWRK, etc.  Then when you need to quiesce the system, you can just end the end user subsystems, and be confident that no new work can enter the system until you want it to.  That's one of the main ideas behind subsystems: to allow different types of work to be segregated for performance and management.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I'm not aware of any such facility, though one could be created. Gary's comments give a good reason why it's commonly not a very useful idea. I have to second the thought that work management is a much better approach.

Rowby Goren Makes an Impact on Screen and Online

Learn about longtime user Rowby Goren and his great contributions to the site. We explore his method for posing questions that are likely to yield a solution, and take a look at how his career transformed from a Hollywood writer to a website entrepreneur.

Gary PattersonVP Technology / Senior Consultant Commented:
I recently completed a long-term consulting assignment in a very large IBM i environment as part of a dedicated performance testing team.  Our performance test system was shared between quite a number of people, and connected to a significant number of applications running on other systems.  We repeatedly faced challenges when trying to do isolated performance testing on large batch applications, especially when trying to clear files and reload them with specific test data due to locks from never-ending jobs.

Ending the subsystems was not always a viable alternative due to other testing that may have been going on at the time.  We scheduled tests so that we didn't overlap on critical tables and processes, but it was difficult at times to get dedicated access to the system to perform isolated testing.

So I wrote a quick and dirty tool that did what you want to do:  you gave it a list of files, and it found jobs locking those files, and ended them.  Sure enough, some of the client/server jobs would reconnect pretty quickly.  As a result, I modified the process to submit a second job to end all the lock holders for a given file, and then attempt to allocate each file exclusively.  When the file was allocated, the necessary operations were performed, the lock released, and the program proceeded to the next file in the list.

That approach generally worked.  I wouldn't use the same approach in a production environment, through, due to the risk of creating data inconsistencies in the database.  Better to end user jobs gracefully, end the user subsystems, perform the necessary operations, and resume necessary work.

One final note:

If this is related to backups, you may want to take a look at the Backup and Recovery guide for your OS version, and read up on Save-While-Active.  SWA allows you to perform backup operations on files that have locks, and allows you to do the saves with files in a consistent state relative to each other.  SWA is a widely-used and very stable, reliable technology.
Ending subsystems before taking care of jobs that are running in the subsystem is indeed asking for trouble.

Using facilities like ENDHOSTSVR *DATABASE ENDACTCNN(*NONE) can be a good start. The server ends while allowing currently active connections to continue. New connections won't be allowed until the host server (*DATABASE in this case) is restarted. Most connections will finish soon after, commonly leaving very few 'persistent' connections. Those should be recognizable and have defined methods of handling.

Using such features helps allow clean ending of subsystems, if those subsystems need to be ended after server jobs are gone.

Gary PattersonVP Technology / Senior Consultant Commented:
Don't get me started on frequently-omitted "orderly shutdown" handling in long-running processes.  You SHOULD be able to do a controlled shutdown of a job or a subsystem - but how many applications have shutdown detection built-in?  

Couldn't be much easier:  RPG, for example supplies the %SHTDN BIF to detect when a job is in the process of being ended, CL has RTVJOBA ENDSTS, Java has Job.GetStatus().

And of course applications with properly implemented commitment control usually tolerate job/subsystem shutdown pretty well.
Ditto. Lots can be said, but lots has been said in many forums for many years.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IBM System i

From novice to tech pro — start learning today.