Luis:
We always use *all when checking for locks
WRKOBJLCK OBJ(MYLIB/MYFILE) OBJTYPE(*FILE) MBR(*ALL)
Gary:
>From IBM's CHGPF command help...
" An exclusive-no-read lock is required, which means no one can be using the file for any purpose."
This I expected, but what I did not expect was the lock to remain in
place and WRKOBJLCK to not show me what was locking it.
Chuck:
You probably explained it. I may have orphaned the lock if I tried to
cancel the CHGPF job. I really don't remember if I let it time out or
not. Probably if I had signed off from the session that ran the CHGPF,
the lock would have been released.
Or if I would have changed the heading using SQL or the database part of
ops navigator, but green screen commands die hard.
We are running V7R1 and applied latest cum a few weeks ago.
I am still concerned that WRKOBJLCK did not show the problem, but I can
understand it now due to the odd nature of my problem.
Thanks.
Actually, it's good to have odd problems once in a while, to make you
review your methods. Due to the way the web page is displayed, the SQL
time out error was difficult to read, with the 913 code being partially
hidden. So we just concluded something was wrong with Zend, or Apache,
HTTP, and retstarted all of them, to no effect. When that did not work,
we slowed down and actually figured out the problem. Of course, having
everyone in the office telling you the web site is down does not make it
any easier, even though all of it worked except the home page that had an
ugly error message on it.
---Dale
midrange.com
