RE: V5R4 and ODBC

Couple of more things to check. First, is it possible the maximum number of users are using the PC application? To m the message point to such a situation but, I could be wrong.

Have you scanned the joblogs for the jobs listed? You might find more clues to what is going on in them.

If you can, end the jobs you listed then try accessing the table in question again from a PC client. If you are still having difficulties I suggest calling IBM and the client application vendor if not an in-house application.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Kern, Mary T
Sent: Friday, July 27, 2007 12:49 PM
To: Midrange Systems Technical Discussion
Subject: RE: V5R4 and ODBC


Interesting. I can't download THAT file with file transfer. But I can download others. It appears to be anything in the library ... BTW, Public has *USE on the library. I have *ALL.

Since it's file transfer I don't know what joblog to look at ...

Here's the message from file transfer:

CWBDB0040 - Catalog information server returned error SQL0913 - Row or object QZDAPKG in QGPL type *SQLPKG in use. Cause . . . . . : The requested object QZDAPKG in QGPL type *SQLPKG is either in use by another application process or a row in the object is in use by either another application process or another cursor in this application process.

Recovery . . . : Look at the previously listed messages in the job log (DSPJOBLOG command) or from interactive SQL press F10 (Display messages in job log) on this display to determine if this is an object or record lock wait time out.

Do one of the following: -- If the object is locked by another application process, try the SQL statement again when the object is not in use. Use the Work with Object Locks (WRKOBJLCK) command to determine who is currently using the object. -- If the object is a schema and an attempt was made to create a table, view, or index into this schema under commitment control, a save-while-active operation may be in progress on the same schema by another job in the system. Try the request again when the save-while-active processing is complete. -- If a record is locked by another application process, try the SQL statement again when the record is not in use. The Display Record Locks (DSPRCDLCK) command will determine who is currently using the record. -- If this is a record lock held by another cursor in the same application process, you must issue a COMMIT, ROLLBACK, or another FETCH statement on the cursor that is holding the lock before issuing this SQL statement. If this error occurs frequently, use the Change Physical File (CHGPF), Change Logical File (CHGLF), or Override Data Base File (OVRDBF) command to change the object or record wait time out.

Here are the locks on the SQLPKG:

Object . . . . : QZDAPKG Type . . . . . : *SQLPKG
Library . . : QGPL ASP device . . : *SYSBAS

Opt Job User Lock Status Scope Thread
QZDAINIT QUSER *SHRRD HELD *JOB
QZDASOINIT QUSER *SHRRD HELD *JOB
*SHRRD HELD *JOB
*SHRRD HELD *JOB
QZDASOINIT QUSER *SHRRD HELD *JOB
QZDASOINIT QUSER *SHRRD HELD *JOB
QZDASSINIT QUSER *SHRRD HELD *J
Thanks!
Mary

¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«
Mary Kern
Director of Information Services
University of Toledo Foundation
2801 W Bancroft St Mail Stop 319, Toledo, OH 43606
Voice: (419) 530-5611 (800) 640-0147 Fax: 419-530-2895
Email: Mary.kern4@xxxxxxxxxxx
"Three things in human life are important. The first is to be kind. The second is to be kind. The third is to be kind. -- Henry James ¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«