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
midrange.com
