Re: QZDASOINIT file lock prevents CLRPFM after v5r2 --> v5r4 upgrade -- MIDRANGE-L

Dan,

We have try newer versions of the JT open tool kit, but I'm not sure
which ones exactly.

Do you know of any IBM documentation that details the "Prior to V5R4 a
lot more QZDASOINIT jobs were ended
and restarted." statement you made?

As I mentioned originally, we know have to fix it, but we want to
understand what changed so we can consider it in future applications.

Thanks,
Charles Wilt

On Tue, Feb 10, 2009 at 11:56 AM, Dan Kimmel <dkimmel@xxxxxxxxxxxxxxx> wrote:

Connection pooling was improved immensely in V5R4. This alone solved
some performance problems for us at one of our customers.

In connection pooling, each connection in the pool is "attached" to a
QZDASOINIT job. The attachment remains after the client code "closes"
the connection and thus returns the connection to the pool. The
QZDASOINIT job keeps running (in wait status, of course). V5R4 made this
rule more stable. Prior to V5R4 a lot more QZDASOINIT jobs were ended
and restarted.

One place I'd look is to make sure you have current versions of the
JDBC/ODBC code in your webapp. Get the latest JT400 or JTOPEN toolkit if
this is java. If you are running the webapp and JDBC on your IBM i
machine, make sure you have the latest java cume and make sure it
applied. There are PTF's that fix the JVM that are MCH fixes that
require two IPL's to apply. Those PTF's fix something that is used by
the JT400 native code.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Tuesday, February 10, 2009 7:49 AM
To: Midrange Systems Technical Discussion
Subject: Re: QZDASOINIT file lock prevents CLRPFM after v5r2 --> v5r4
upgrade

Chuck,

Testing CLRPFM on an open file does confirm that DFTWAIT for the job
doing the CLRPFM and not WAITFILE on the file determines how long till
the CLRPFM fails.

However, I'm not sure that proves anything. I think it's possible that
things are difference with a pseduo-closed file. Otherwise, the
document in question hasn't just confused DFTWAIT and WAITFILE, but the
whole section makes no sense.

The point of the section is that you have to allow the system some time
to hard close the pseudo-closed file; thus make sure WAITFILE is not
*IMMED but is at least 1. On the other hand, DFTWAIT doesn't have
*IMMED or 0 available as a valid, it is always at least 1. So if
DFTWAIT is the controlling factor, then the whole section is pointless.

So, based on your experience, do you think pseduo-closed files are a
special case, or is that whole section of the document is a pipe dream?

I tried to test CLRPFM and pseudo-closed cursors myself, however even
with the file set to WAITFILE(*IMMED) and the job set to DFTWAIT(1), the
CLRPFM didn't fail.

Charles

On Mon, Feb 9, 2009 at 5:46 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

Out of date? Not likely. Wrong? Not necessarily, but probably
either unclear or somewhat deceptive. Special case? Maybe. But easy

enough to validate the relevance of WAITFILE on CLRPFM processing in
normal open cases; i.e. open a member in one job which has
WAITFILE(60), and then CLRPFM in another job with DFTWAIT(2). If
WAITFILE plays any role, trust that any override is ignored; i.e. data

management bypasses that phase for a clear, primarily because the
clear member operation has no redirect support to another member
[name] except for the special case of open-with-clear. There may be a

special case opt-out for sending the close-event if the member
attribute [inherited from the *FILE, or as retrieved from the *FILE]
suggests that the WAITFILE time is *IMMED, but I do not recall.
However I would be willing to bet instead, that the reference to
WAITFILE should be DFTWAIT; i.e. indeed that portion of the text is
simply wrong. It is as noted, for "IBM Internal Use [only]"; i.e. not

intended to be referenced as /documentation/ by a customer, as its

review process was not intended to ensure that level of /correctness/.

Regards, Chuck

Charles Wilt wrote:

So the IBM document referenced is wrong/out-of-date?

"What Are the Impacts of Pseudo Closed Cursors? <snip> Shared file
locks even when all cursors are closed: As stated above, a pseudo
closed cursor does not hold any record locks; however, it will
continue to hold a shared lock on the file. In theory, the shared
lock left on the file should have a minimal effect on other
applications. Some operating system commands and all SQL statements
that require an exclusive lock (DLTF, DROP TABLE, CLRPFM, and so on)
will cause a pseudo closed cursor to be hard closed so that the lock
is released. Each command that wants to force closing of pseudo
closed cursors causes an event to be signaled if a lock conflict
occurs. This event causes a program to run that hard-closes any
pseudo closed cursors that hold the object. For this to function
correctly, the maximum file wait time (WAITFILE) must be set to a
value other than *IMMED. In general, a value of 1 second or greater
is sufficient (actual time depends on system performance)."

The way I read the above, WAITFILE effects CLRPFM.

On Mon, Feb 9, 2009 at 4:42 PM, CRPence wrote:

Charles Wilt wrote:

On Mon, Feb 9, 2009 at 3:40 PM, Elvis Budimlic wrote:

Nice find. That post supports what you said about CLRPFM hard
closing the pseudo closed cursors, provided file's WAITFILE
attribute is set to 1 or greater. Based on that, check the
WAITFILE keyword. If that checks out, then perhaps this isn't a
pseudo closed cursor but an open cursor?

>>>

Yes, I've forwarded the info to the other team; recommended
checking WAITFILE and to try the ALCOBJ CONFLICT(*RQSRLS) to see if

the lock goes away.

If the lock doesn't go away that would seem to indicate the problem

is not the result of a pseudo close.

WAITFILE is for open, not for clear. The DFTWAIT of the requesting

job controls the wait time for the clear opeartion [excepting any
defects or special cases]. Since both the held lock and the close
activity take place in another job, the wait-time must suffice for
those other holders to effect their close activity, plus requires
that no new opens of the file [in that same job or another] since
the close-event was initiated [and received by the holding jobs].
Note also there is an exit program for this event driven close
processing which can choose to prevent\ignore the close request,
which can make a pseudo-closed open act like a normal open.

Thus only "seem to" because... The file may not be allocated using

the request to release the conflict _even if_ it were pseudo-closed,

due to one of: a programmed response to disallow close, insufficient

time allowed in waiting for the close to be effected, the
possibility that another open\close [or another type of allocation]
may have been initiated since the request to close was initiated.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.