Sometimes you want to do something simple and you can't because SQL has your file; this tip provides the fix.

SQL is a powerful tool that provides fast access to your data. In order to stay fast, though, it does a few things under the covers that don't always coexist nicely with the rest of the operating system. Today's tip focuses on a specific case, the pseudo-closed cursor.

The operating system pseudo-closes a cursor (or more specifically, an open data path or ODP) when it determines that such action would benefit performance. It does this in a rather clever way: if the same program opens the same ODP twice, then the second close is a pseudo-close. I think this is a pretty reasonable compromise. The first open doesn't leave the ODP open; it's the second one that triggers that behavior. So why do this at all? Because extra ODPs have a couple of negative effects. First is the overhead of the ODP itself, and second is the fact that this tends to lock the file in such a way that you can't do certain operating system functions. It's this second problem that we're going to address here.

Many commands require exclusive access to a file. Examples include CLRPFM and CRTDUPOBJ. If you've ever tried to execute one of these commands only to find a lock on the file and then use WRKOBJLCK to find that a QZDASOINIT job has your file locked, then you've run into the pseudo-close. You won't be able to clear or duplicate your file without using an alternate technique. Alternates do exist; you can use DELETE FROM MYFILE in SQL with no WHERE clause to clear a file or you can execute a CPYF with CRTFILE(*YES) to duplicate a file and then clear it with CLRPFM. But these other solutions can be a bit clumsy, and even if they weren't, they still don't help when you've got to run a program that executes one of those commands.

The good news is that it's relatively easy to get rid of those locks. All you need to do is force those cursors to be closed by using the ALCOBJ command. The CONFLICT keyword is a relatively recent addition to the command, and its sole purpose is to resolve those holds. The syntax is simple. Here's an example:

ALCOBJ OBJ((MYLIB/MYFILE *FILE *EXCL)) CONFLICT(*RQSRLS)

This will attempt to place an exclusive lock on the file MYFILE in MYLIB. If any pseudo-closed cursors exist, the operating system will hard-close them, making the file available for lock. You can then proceed on to whatever command it was that you needed to perform. Remember that this will only remove locks from pseudo-closes. It won't magically break locks from other jobs; that would be a potentially disastrous action. But if the only problem is that you have some locks because SQL is caching some cursors, then you can fix that. WARNING: remember to remove the lock using the DLCOBJ command; otherwise, other people won't be able to use the file!

I hope this provides an easy resolution to an annoying problem for some of you.