× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



With a (Windows) server reboot and an update to the JDBC drivers, the issue we were seeing has been fixed, at least for now.

Thanks to everyone for the input.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Kurt Anderson
Sent: Tuesday, October 06, 2009 2:29 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Error SQL0302 *N

Thanks Tom for checking that out. I've passed the information along.

We're going to be applying a JDBC update on the night of 10/7 and I'll find out hopefully today or tomorrow about whether or not we'll be applying PTF SI35287.

As far as it being a data issue as the error suggests, it's entirely possible that one person screwed something up, but this has been happening for multiple clients all at once, without any apparent changes being made. So we're still a bit baffled by the fact that we can't discover the root cause of this yet.

Oh, and someone asked about the field HVR0004. Yeah, we don't actually have any field with that as a field. It appears that the SQL the job is processing must be creating a temporary file or something. When I look at the files used by the QZDASOINIT job they all have a format of FORMAT0001 (which is not actually the files' format names).

I appreciate all of the input. And thanks again, Tom, for following the trail of that APAR I mentioned.

-Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tom Liotta
Sent: Monday, October 05, 2009 12:12 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Error SQL0302 *N

Kurt Anderson wrote:

I did find an APAR issue that sounds like possible cause, however it was found in v5r3 in 2007, and since we went to v5r4 in 2008, that should mean we already have that fix, right?
The APAR: http://tinyurl.com/y9f56df

Kurt:

The other replies covered the core issue, but the bit above deserves
a little discussion by itself.

In short, yes and maybe not. I'd say "Yes" from a philosophical
viewpoint that stuff that was fixed in one release 'should' be
covered by the subsequent release. But from a practical and
realistic viewpoint, the actual answer has to be "Not necessarily."

A PTF for V5R3 might come a couple years or more after the release
of V5R4. There'd be no chance for it to be an automatic part of
V5R4. Further, many PTFs won't be created for a release until
someone asks for them. And, of course, a PTF doesn't mean much if
it's not applied; nor are they guaranteed to work in all cases.

The APAR URL you supplied references V5R3 PTF SI24723. I didn't see
that listed in the V5R3-to-V5R4 PTF cross-reference. I did, however,
see that SI24723 was superseded by SI30707, and that that is xref'd
to SI35287 in V5R4 for 5722XE1.

If you have SI35287, then you should have /a/ related fix.

Now, is it working?

Tom Liotta


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.